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
googleplus.png
reddit.png

 

Latest posts:

VB2017 paper: Walking in your enemy's shadow: when fourth-party collection becomes attribution hell

We publish the VB2017 paper and video by Kaspersky Lab researchers Juan Andres Guerrero-Saade and Costin Raiu, in which they look at fourth-party collection (spies spying on other spies' campaigns) and its implications for attribution.

Didn't come to VB2017? Tell us why!

Virus Bulletin is a company - and a conference - with a mission: to further the research in and facilitate the fight against digital threats. To help us in this mission, we want to hear from those who didn't come to Madrid. What is your impression of…

Montreal will host VB2018

Last week, we announced the full details of VB2018, which will take place 3-5 October 2018 at the Fairmont The Queen Elizabeth hotel in Montreal, Quebec, Canada.

VB2017 preview: Beyond lexical and PDNS (guest blog)

In a special guest blog post, VB2017 Silver sponsor Cisco Umbrella writes about a paper that researchers Dhia Mahjoub and David Rodriguez will present at the conference this Friday.

Avast to present technical details of CCleaner hack at VB2017

The recently discovered malicious CCleaner version has become one of the biggest security stories of 2017. Two researchers from Avast, the company that had recently acquired CCleaner developer Piriform, will share the results of their investigations…