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.


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.


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.



Latest posts:

Five reasons to submit a VB2018 paper this weekend

The call for papers for VB2018 closes on 18 March, and while we've already received many great submissions, we still want more! Here are five reasons why you should submit a paper this weekend.

First partners of VB2018 announced

We are excited to announce the first six companies to partner with VB2018.

VB2018: looking for technical and non-technical talks

We like to pick good, solid technical talks for the VB conference programme, but good talks don't have to be technical and we welcome less technical submissions just as much.

Partner with VB2018 for extra visibility among industry peers

Partnering with the VB conference links your company to a successful and well-established event, demonstrates your commitment to moving the industry forward, allows you to meet potential clients, be visible to industry peers and build lasting…

VB2017 paper: The router of all evil

At VB2017 in Madrid, security researcher Himanshu Anand presented a paper on malware that targets routers, looking both at the topic in general and at some individual case studies. Today we publish both the paper (co-written with Chastine Menrige)…