Bit9 hacked, used to inject malware into customers' networks

Filed Under: Featured, Malware, Security threats, Vulnerability

Security vendor Bit9 has been hit by a serious security breach of its own network.

Intruders broke into a core part of the company's service and used its own trusted digital certificates to create pre-authorised malware.

The result, apparently, was that a small number of customers got infected with malware that wasn't merely missed by Bit9's detection algorithms, but was actively endorsed by its protection system.

It's always tricky to write about compromises and problems with competitors' products, but please bear with me here. I'll try to be as balanced as I can.

As a colleague wryly and compactly pointed out the other day when Kaspersky hit the news by cutting customers off from the internet with a dodgy update, "John 8:7."

Bit9's case is a bit different because the company eschews traditional security and anti-malware techniques and instead favours whitelisting.

→ I'm not a fan of that name because at least some people find it offensive, and because there is a much clearer, self-descriptive alternative: allowlisting. Likewise, blacklisting is much more directly rendered as blocklisting. Simply put, blocklisting aims to recognise known bad stuff and to stop it. Allowlisting aims to recognise known good stuff and to stop everything else.

For what it's worth, Bit9 has done the right and honourable thing, and 'fessed up on its website.

The company is still keeping the precise details close to its chest, as it's entitled to, but has offered a general overview that's pretty clear. Call me old-fashioned, but that counts for a lot.

I'm not entirely convinced by the entire explanation, however.

Bit9's observation that "this incident was not the result of an issue with our product," for instance, is a trifle misleading.

I think I know what they mean, and why they said it, but the truth is simple: Bit9's service made the wrong call.

It misrecognised malware as good software (a false negative, in industry jargon) and let an infection through.

Conceptually, this is no different (in industry jargon, it had a similar failure mode) to what happens when a traditional anti-virus fails to spot malware as malware.

The truth is that any programmatic means of analysing another program and predicting its behaviour must be imperfect.

Regular readers of Naked Security will have heard me pronouncing on this matter before. That's because I'm a big fan of Alan Turing, who studied this very issue back in the 1930s, before digital computers even existed.

It's known as the Entscheidungsproblem (usually rendered into English as the Halting Problem), and it pretty much says that any security software must, at least occasionally, make mistakes.

It's become fashionable recently to bash anti-virus software harder than ever, decrying it as reactive, behind-the-times and even as "digital homeopathy." (Even I had to smile at that tweet.)

Allowlisting is often trumpeted as the preferred, scientific, simpler, cleaner, greener approach.

There's a lot to be said for that, if you can reliably predict in advance the complete list of software files you will need on your computers, and if you don't make any mistakes in ensuring that everything on the list really is good.

Of course, the pace of change is swift enough these days that you need to keep updating the list of known good stuff, and that's where errors can creep in.

In practice, modern anti-virus software doesn't rely on (indeed, hasn't relied on for about two decades already) a purely reactive, list-of-known-badness approach.

Today's anti-malware solutions aren't merely blocklists, and if you buy one and engage only its pure-play blocklisting parts, you're missing a trick.

Several tricks, in fact.

Similarly, any decent product that claims to work by permitting only known-good stuff doesn't rely entirely on allowlisting.

If a file is already known to be bad, you'd be silly not to use that information to ban the file so it never gets onto your allowlist by mistake!

No security solution can be perfect, because no solution can decide all the answers.

That's why defence in depth is really important, and why you should run a mile from any security vendor who still makes claims like "never needs updating" or "all others are imposters."

To the Bit9 crew: when I read the part where you wrote that "the threat from malicious actors is very real, extremely sophisticated, and that all of us must be vigilant," I felt your pain, brothers and sisters.

We may have varying approaches and differing opinions, but we're on the same side here.

I hope you catch the villains behind this, or at least find out more about the who, what and why...

, , , , , ,

You might like

11 Responses to Bit9 hacked, used to inject malware into customers' networks

  1. Ronny GT · 972 days ago

    This happens when You spit to the heaven. Bit9 is ridiculously expensive and preach the white list miracle, I'm very open to hear about new technology's but when You 're the new guy on the security neighborhood You must be humble.

  2. JonBays · 971 days ago

    Hi Ronny Bit9 isn't an AV software program so it isn't priced to match AV but to the value it delivers in solving customers problems that go past AV or antimalware alone.

    The miracle of white listing or application whitelisting is a well researced and endorsed strategy by people like our own DSD. Have you seen their top35 cyber security mitigation startegies?

    So far Bit9 have been very open about the breach and dealt with it very well outlining the issues it represents to all it's customers and the broader IT security community.

    • Paul Ducklin · 971 days ago

      Would be be nice if Bit9 would follow up on the openness and honesty (and ditch at least some of its hubris) by getting rid of the blurb on its site aggressively comparing anti-virus to a "broken record," though.

      "Whitelisting" may be endorsed by DSD (Australia's version of NSA/GCHQ) - indeed, it's currently DSD's #1 threat mitigation - but *please notice the two boldfaced caveats in the article above*.

      One significant problem with allowlisting, especially when you're gung-ho enough to promote it instead of other, behaviour-based, mitigation (such as anti-virus :-), is put clearly into perspective here.

      Bit9 didn't just miss a piece of malware with one part of its detection toolbox. It actively endorsed as trusted files that were overtly malicious, thus turning a sin of omission into one of commission.

      I prefer to steer clear of "miracles" in computer security, whether they're endorsed by the Department of Defence or not, and go for a more balanced approach...

  3. Dave · 970 days ago

    Allowlisting & blocklisting are not words. I find your attempt to invent them clumsy and offensive. Black and white are colours, the terms blacklisting and whitelisting are not inherantly racist. You are the one making them racist which makes you the racist.

    • Paul Ducklin · 970 days ago

      Errrr....yes, well, lost me at "offensive", I'm afraid.

  4. little old man · 970 days ago

    What you are refering is simply the thesis of Fred Cohen about the impossibility of detecting all viruses in his thesis (*1984*):

    [Edited for length]

  5. Nigel · 969 days ago

    Hmmm..."blacklisting" and "whitelisting" are offensive? That's news to me. I'm not disputing it; I've just never heard of it before.

    But while it is news, I suppose it's not really a surprise. Some people are utterly determined to take offense where none is intended. They won't be talked out of it, and the mere attempt to inject some rationality into their perceptions is ITSELF taken as offensive.

    It's not an approach to life that I admire, but I've been forced to admit that it exists. Because those who adopt it generally seem disinclined to be relieved of their delusions, it's usually futile to argue. For my part, I just shrug a "Whatever..." and move on.

    Anyhow, I guess I can't fault Bit9 for hyping their own product, and I give them points for fessing up about dropping the ball by not installing their software on some of their own systems. But I'm somewhat less comfortable with their assertion that there is "no indication that this was the result of an issue with our product" until they reveal more about the nature of the infection.

    • Paul Ducklin · 969 days ago

      My point is that "allowlisting" is clearer than "whitelisting", since it is entirely self-descriptive and doesn't rely on any metaphor involving colour (something that is culturally specific at the best of times). Ergo it is a better choice of word *anyway*.

      Add in to the mix that the colour metaphor unavoidably implies something along the lines of "white is right and black is slack," and there is simply no reason not to err on the side of clarity.

      If you can avoid offending even one person and remove ambiguity at the same time, that's not "political correctness", it's just "clarity with accommodation." (From time to time, things that are politically correct are also just plain correct :-)

      • Nigel · 968 days ago

        Agreed. I just like to rant about political correctness in, assuming that's what's behind the objections of those who find "whitelisting" and "blacklisting" offensive. No argument on the points about semantic precision.

    • Paul Ducklin · 969 days ago

      Oh. Another, more directly important point.

      Bit9's claim that their own software would have prevented this if only they'd been running it...errrr, how, exactly? Sorry. I'm not buying it.

      The crooks used Bit9's infrastructure to do what it was designed for: to sign new executables as trusted, *not* to execute them. How could an allowlisting product possibly do anything to prevent this?

      If the code being signed were already trusted, it wouldn't need to be signed. But it wasn't trusted, so it needed to be tagged as trusted...and only trusted software is needed to carry out that function!

      In short, if Bit9's own code-signing code had indeed been validated by Bit9's own code-signed code checker, the only difference would have been an even greater degree of trust that the crooks would have had in their malware. They'd know for sure that no other crook had got in before them and subverted the code-signing code itself :-)

      • Nigel · 968 days ago

        Thanks for that, Paul. It helps shed a bit more light on Bit9's response, which I did indicate was not entirely convincing. In fact, it reminded me of a duplicitous tactic often used by former British Prime Minister Stanley Baldwin, wherein he frequently disarmed his critics by offering a "sincere admission" that he had erred on some superficial point, which often deflected a deeper examination of his more egregious errors on other more serious points.

        Anyhow, thanks to your additional directly important point, I now have a better understanding of why I wasn't comfortable with Bit9's "sincere admission". Evidently it wasn't so sincere after all. That's one of the reasons why I appreciate Naked Security!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog