Three questions to ask about security product bypasses

Posted by   Martijn Grooten on   Sep 13, 2017

Techniques for bypassing security products feature prominently at security conferences and on security blogs these days. Indeed, with so many people relying implicitly or explicitly on products to protect themselves and their networks, these finding are to be taken seriously.

If you work for a vendor that sells such products, I would recommend not giving in to the natural reflex of trying to find fault in the research, but rather focusing on how you can improve your product to avoid such bypasses, even when the threat appears mostly theoretical.

But what if you're a security practitioner, or a journalist or analyst covering the industry? How seriously should you take such research?

Of course, it is impossible to make generalizations, but I would recommend asking the following three questions before switching to panic mode about yet another horrible attack.

panic-button.jpg

1. Does it involve a full attack?

Security is a layered approach and products tend to use many layers to protect the user. It is common for a proof-of-concept to bypass only one layer, failing to acknowledge the other protection layers.

The most common example of this is anti-malware, one component of which is a static detection engine that determines whether a file is malicious or not. Being able to bypass this engine is a nice achievement, but it doesn't mean the malware can actually run: other layers are supposed to prevent that.

2. Does it scale?

For many cyber attackers, it's the scalability of their efforts that makes their trade worthwhile: they attack thousands or even millions of people at once, and while only a very small percentage of the attacks will be successful, this still gives them enough victims to make their attack worthwhile.

Spam is the most obvious example of this: it is not uncommon for a spam campaign to have a conversion rate of less than one in a million and still be worth the spammers' efforts. Spam also shows why many bypasses scale badly: it is trivial to bypass a spam filter with a single email, but once you start sending thousands of messages, they will be picked up and blocked, all of which will happen fully automatically.

In other cases, it is the amount of work involved in bypassing a single instance that could make it scale badly.

Of course, not all attacks need to scale: targeted attacks have for a long time been an issue and product bypasses could help those more advanced attackers a lot. However, it does mean one should take headlines about the possible size of the issue with a pinch of salt. Moreover, advanced attackers tend to be rather powerful already; hence it is worth asking:

3. How much extra power does this give an attacker?

Every proof-of-concept makes certain assumptions. They can be very reasonable, such as enhanced product features not being enabled, or a user clicking on a link. Other assumptions are rather specific, for instance that an attacker already has write access to the target device. With such access, one should wonder, haven't they won already, or does the proof-of-concept really give them valuable extra powers?

Even when a proof-of-concept doesn't many any particular assumptions, it might be so complicated that it becomes less attractive than the age-old trick of simple social engineering. "Popping the calculator" during a conference talk is guaranteed to earn applause, but real attackers are more likely simply to phone their targets and, metaphorically, ask them to open the calculator app.

dont-panic-button.jpg

It is all too easy to dismiss security product bypasses as pure marketing (tempting as it may be if they are revealed by a vendor whose product happens not to be vulnerable). But it is equally easy to be overly concerned about such techniques and fear that the security sky is falling in; in all cases we should react with a measured and carefully considered response.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VB2019 paper: APT cases exploiting vulnerabilities in region-specific software

At VB2019, JPCERT/CC's Shusei Tomonaga and Tomoaki Tani presented a paper on attacks that exploit vulnerabilities in software used only in Japan, using malware that is unique to Japan. Today we publish both their paper and the recording of their…

New paper: Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

In a follow-up to a paper presented at VB2019, Prismo Systems researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting (XSS), and server‑side request…

VB2020 programme announced

VB is pleased to reveal the details of an interesting and diverse programme for VB2020, the 30th Virus Bulletin International Conference.

VB2019 paper: Cyber espionage in the Middle East: unravelling OSX.WindTail

At VB2019 in London, Jamf's Patrick Wardle analysed the WindTail macOS malware used by the WindShift APT group, active in the Middle East. Today we publish both Patrick's paper and the recording of his presentation.

VB2019 paper: 2,000 reactions to a malware attack – accidental study

At VB2019 cybercrime journalist and researcher Adam Haertlé presented an analysis of almost 2000 unsolicited responses sent by victims of a malicious email campaign. Today we publish both his paper and the recording of his presentation.

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.