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?

1401132_10151680012450588_1416577247_n

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+

24 thoughts on “On BadBIOS and Bad Behavior

  1. Good news (IMHO) is that but research on this issue will highlight other vectors of attack, like Intel’s AMT for example, or that current protection software has ways to go, that “off-shoring” manufacturing of electronic components was really a “great” idea. I know this is not technical comment, but I hope it meets “intelligence” test.

    1. I have several machines working and non-working that this virus could be the only explanation. I first noticed this virus sometime in november of 2011. If anyone knows a lab or someone I could send them to I would be more than happy to do so.

      1. Dear Will, have you found a lab to help you? If so could you possibly communicate with me? I was hit by badbios Dec 16th 2011. Despite my efforts and investments in new equipment etc i am still plagued by this issue. It is very difficult to recieve help and even more difficult to find someone who will actually believe it is even possible.

  2. I 100% have this, I’m an old network admin/systems engineer that moved onto do security for the air force.. I have been dealing with this thing for over a month. Air gap stuff all confirmed, USB issues, 100% confirmed, bios infection, 100% confirmed.. I used an EFI shell on an MSI motherboard meant for gaming… The sucker infects 00000009-00 thru 00000040-FF on that machine and hijacks the NVRAM to install a set of modified “Generic” acpi drivers into the bios… these drivers were part of what it labeked “CORE_DXE” and could NOT be modified or removed manulally through the EFI shell (as you can with other normal bios dirvers and images). The package sets up a chain routine of FS0 (file system) or dev0 (device 0) = (physical character location in EFI)\ = blk0 (block 0) it proceeds to chain all the devices, drivers, and images that way trhgouh up to as many as blk20 and then uses a loopback on last blk by creating an alias that links to previous blk and its own blk as ALAIS BLK20 = NULL and then loops that abck to another blk which maeks them both null ….. I spent three hours in EFI shell and managed to get ONE mountable device back from the blocks it had on there only to get a few tasks done and have the freaking thing blk it again as I was working. This thing is very real and the hyper v potion that is standard with my windows variants of the installs ia a pin in th eass.. it uses that ACPI driver to create a corrupted CD/DVD setup where an ISO type image will always float on any action you take on any cd drive… it can modify the ISO and shadow it over any CD/DVD (which it reads and modifies to its purpose before it lets the ROM do its thing)… that shadowed image is installed versus the actual optical drive… so the CD/DVD you see is always the wrong one. This can be seen in action when in an O/S and you insert a new driver CD and it has not completely scanned it.. eventually you’ll see any useful drivers or files start to disappear off the DVD view… I’m still dealing with it and its a freaking headache…

    1. Your findings are very interesting. I agree with all of the above….when/if you get to the bottom of it please let us know how you sid it and what your other findings were.

  3. To prove how sure I am that this exists. I invite anyone to remote into my machines and have a poke around. I have no fear as if someone wants to steal my identity…….They will not be happy. This is a serious invite. Just post it here and I will give you info on how to reach me. Thanks

  4. Will, thank you for referring this webpage.

    Matthew Myra, thank you for detecting and explaining how ACPI driver creates a tampered ISO. Last week, I posted a thread on this but no one helped.
    http://www.reddit.com/r/Malware/comments/23fxaa/badbios_live_linux_dvds_persistent_storage/

    I will link to your explanation in my thread.

    There is practically no support on how to eradicate BadBIOS. I recommend BadBIOS victims to join reddit’s subreddit on BadBIOS.

  5. ive gone through many systems working with this thing and talked to a great deal of experts, and honestly no one has much progress. the evolution of the what has been referred to as BadBIOS has seemed to been bold since the original period when Dragos started dealing with it years ago. if you all have time you can learn a great deal of why this issue is possible through the CCCs talks on computer tech, this is a very good one on architecture and hardening
    https://www.youtube.com/watch?v=2VvR-vsdMlQ

    ive managed to program a interface debugger by serial porting an audrino board into various systems usb ports and i can tell you that the severity of the problem is far beyond what most people would be able to deal with including myself. ive been able to access some source files from macbook pro (which also is affected by the infection). it seems on the mac a combination of unix base files along with some common library files (coded in languages like python and perl, help it to work on the x86 architecture of mac intel chipset). ill check out the reddit thread but im curious if everyone elses current version mimicks the same file configurations and or system setups.

    i know that after countless hours on debuggers, the most prevelent pain in my ass is seeing how my systems use java injection and dns redirection to control content. that and the constant sandboxing of file operations. i pulled a few chips manually on a intel next gen computing box and managed to get the trusted boot to work, but it wont really save much of anything if everything around me gets infected.

    do the rest of you have webserver system files on your computer (and services running) and java injection into your normal web browsing? and similar symptoms of me as well? im resigned to live with this for the time being but if anyone needs to get a message across to me quicker find me on twitter @svchostisnull

    1. Every thing you say is so the same it is scary. I am way over my head with this stuff but know enough to tell you that it seems like you are looking at my machines.

        1. Another thing I forgot to mention. Last night I was trying to email a svshost dump file to someone to show them that it had a musical note in the code. The note gets changed to a Letter H during the copy and paste process. I ended up taking a pic with my phone to show her.

          1. i can explain this. the code produced for the project to work has a numerous set of redudnancy code to review each o/s that its working on. some of the bridge parser functions (to allow it to exploit south bridge functions on cpus, etc) has various lines of recursive code that assigns variables and defines functions and namespace settings. some of this code tells the program to use one character in unitext on the first pass through and then on secondary and further recursions it assigns a variable that reassigns that character (so anything with an @ symbole in front of it in code for instance will have the @ symbol replaced by a ^v, or anything with a _? would have a function performed.). this also means if the code means to hide something from security or system functions it will made intial code a benign character and then have it replaced later to a functional command or character. it also means that it can use similar inline code functions to avoid type and memcpy commands.

            as long as you are reviewing a logical copy of data/memory/files it will always be modified from what you really need to see. if i had cash id setup a writeblocked forensic system to debug, but my original systems are toast. its rough to get a solid memdump as all files that perform kernel requests or memory access requests are tracked via live kernel logging of the injected systems debugging core. i could write a paper at this point but havent gotten around to organizing my thoughts.

  6. Matthew Myhra, thank you for an update. Thanks for your twitter contact information. Mine is twitter@badbiosvictim. Twitter’s character limit is shorter than character limit for SMS. I would prefer commuting via reddit. My reddit userid is badbiosvictim.

    You are very observant and raised excellent questions. Before discussing new questions, could we discuss your prior observations?

    Could you please give more details on shadow ISO on the thread I started at:

    http://www.reddit.com/r/badBIOS/comments/23zbt0/badbios_creates_shadow_iso_that_is_booted_to/

    Could you please give more details on ACPI driver activity on the thread I started at:

    http://www.reddit.com/r/onions/comments/241vg6/badbios_tampered_live_tails_dvd/

    Did you have microcode injection and microcode driver injection in your logs?

    http://www.reddit.com/r/onions/comments/241shd/microcode_injection_in_tails_a_backdoor/

    Lets share logs on reddit.com. If we all boot to the identical linux live DVD, our logs may be consistent. Best live linux DVD to boot to would be a live TOR DVD such as Tails, IprediaOS or Liberte because reddit has a TOR subreddit forum. /r/onions has over 29,000 members whereas reddit’s BadBios forum only has 29 members. Other forum to post would be r/netsec which also has over 29,000 members.

    1. sure i can hit all those points, i just got done debugging what seems to be some code written in ruby that might be part of the coreservices.framework bundle that allows the program to interject itself into the system. i need to get on a desktop before i hit all those links, im doing most my work on a cellphone (not that it matters). i will hit all those links when i switch out my connection through my network dmz in an hour or so

Leave a Reply