Tag Archives: Universal Serial Bus

On BadBIOS and Bad Behavior

So, unless you are in the security industry and have been living under a rock in the last couple of weeks, you probably know what this #BadBIOS thing refers to.

It started when Dragos Ruiu, a highly respected researcher and the founder and organizer of CanSecWest (and PacSec, and EuSecWest) started posting about his exxperience with what seems to be a targeted attack on some of his computing environment:

It started with this post:

IMHO Copernicus BIOS verification tool, (From John Butterworth / MITRE – presenting at PacSec) is one of the most important new security tools in recent history. We’ve already found some persistent BIOS malware that survives re-flashing with it. And that isn’t even the interesting part, the malware seems to have a hypervisor and some kind of SDR (software defined radio) that bridges air gaps, even in laptops with the wifi and Bluetooth cards physically removed. It’s also OS specific, the one we found targets Windows… Time to recheck the OSX boxes too.

Followed by more specific mention of the audio issues that were related to the malware behavior:

So it turns out that annoying high frequency whine in my soundsystem isn’t crappy electrical noise that has been plaguing my wiring for years. It is actually high frequency ultrasonic transmissions that malware has been using to communicate to airgapped computers… one “ghost” located at least. And now we know how the “hypervisor” functions, its probably stored in the realtek firmware, and thats one of the ways it survives reinstalls and BIOS reflashing. Off to find tools to dump the RealTek audio chips, and to try to find clean firmware to compare it to. Haven’t ruled out video firmware yet, either.

And a more comprehensive post circling back to the USB infection vector, and the TTF font files:

More on my ongoing chase of #badBIOS malware. It’s been difficult to confirm this as I’m down to a precious few reference systems that are clean. I lost another one yesterday confirming that simply plugging in a USB device from an infected system into a clean one is sufficient to infect. This was on a BSD system, so this is definitely not a Windows issue.- and it’s a low level issue, I didn’t even mount the volume and it was infected. Could this be an overflow in the way bios ids the drive?

Infected systems seem to reprogram the flash controllers on USB sticks (and cd drives, more on that later) to attack the system (bios?). There are only like ten different kinds of flash controllers used in all the different brands of memory sticks and all of them are reprogrammable, so writing a generic attack is totally feasible. Coincidentally the only sites I’ve found with flash controller reset software, are .ru sites, and seem to 404 on infected systems.

The tell is still that #badBIOS systems refuse to boot CDs (this is across all oses, including my Macs) there are other more esoteric problems with partition tables and devices on infected systems. Also USB cd drives are affected, I’ve bricked a few plugging and unplugging them too fast (presumably as they were being reflashed) on infected systems. Unsafely ejecting USB memory sticks has also bricked them a few times on #badBIOS systems for clean systems, though mysteriously they are “fixed” and reset by just simply replugging them into an infected system. Extracting data from infected systems is VERY tricky. Yesterday I watched as the malware modified some files on a cd I was burning to extract data from an infected system, don’t know what it was yet, I have to set up a system to analyze that stuff.

On windows my current suspicion is that they use font files to get up to some nastiness, I found 246 extra ttf and 150 fon files on a cleanly installed windows 8 system, and three stand out, meiryo, meiryob, and malgunnb, that are 8mb, instead of the 7 and 4mb sizes one would expect. Unfortunately ttf files are executable and windows “previews” them… These same files are locked by trusted installer and inaccessible to users and administrators on infected systems, and here comes the wierd part, they mysteriously disappeared from the cd I tried to burn on a completely new system (a laptop that hadn’t been used in a few years) that my friend brought over which had just been freshly installed with win 8.1 from msdn, with the install media checksum verified on another system.

I’m still analyzing, but I’m certain we’ll ALL have a large problem here. I have more data and info I can share with folks that are interested.

Up to this point, all that was available were Dragos’ accounts of what he’s going through and the assumptions and forensic efforts made in order to uncover what was going on. Shortly after that an article by Dan Goodin was published on ArsTechnica which went through the incident and also mentioned the different assumptions made so far. It’s important to remember that there weren’t any real insights there yet, as the forensic process was not completed.

Nevertheless, the industry exploded. From more sensible breakdowns of the elements mentioned by Dragos – such as Errata’s Robert Graham’s post, to the more popular reaction which was to simply call bullshit on the whole thing and dub it as a marketing effort.

Then came the naysayers, with more elaborate explanations of why this can’t happen, focusing specifically on the parts they felt they had the most experience with – and while at it, completely ignoring what was reported and the context of that part, for example – a great post by Phillip Jaenke focusing on how it would be impossible to deploy a fully functional malwae of this sort solely through BIOS – especially not while utilizing audio functionality straight from BIOS code (of course…).

Now, don’t get me wrong – I’m still the annoying sarcastic skeptical engineer at heart that I am, but seriously – this is still work in progress. Details are emerging as they become available, and frankly I do think that Dragos is doing the best he can to make these available (it’s his reputation on the line after all). Why can’t we either focus on working with empirical data, or just hold on until the entire picture becomes clear? In an industry that is supposed to be highly scientific (I know – I’m also holding on from bursting out laughing when I think of some of the people that made it into the industry when I mention scientific here…), and analytical, there is no room for too much emotions. Definitely not the school-yard bullying kind that some people show (again – love comments such as “i call bull”, and “it’s a fake”. The rigor of these arguments is just awesome). And no – I don’t expect Anti-Virus companies to be able to deal with this (or talk about it yet – at least not until they have their signatures in place…). They can’t deal with simple tools that are being used for pentesting, do you really think they can handle an actual attack?


And yes – this is especially interesting for me, if not only for one (yes, just one) element of this which involves the use of audio to communicate between machines. As if that is anything new – we’ve been doing this with acoustic couplers since the 60’s. I’ve personally been employing similar techniques in red teaming since 2009-2010 (and also published this) – hence my continued interest in tracking down more examples of such uses.

Bottom line – I’m going to keep waiting for more details and data to work with. My personal familiarity with Dragos’ body of work allows me to speculate, but that’s not for sharing publicly. I’m sure that like myself, there are others with narrower and specific interests in other elements of this who have been working on the assumptions surrounding this (either to approve or disprove), and for the love of science – if you don’t have something intelligent to say, just keep quiet.

update: more data keeps coming in for examination from Drags on his Google+