The BadBIOS Analysis is Wrong
rootwyrm.com
rootwyrm.com
1. He wastes time talking about “high frequency” as if it means radio EFI, which was never claimed and is an odd tangent.
2. Apparently at some point he actually read the original claims and realized that they were talking about sound and then makes the claim that this is simply impossible due to hardware limitations. See e.g. the running code at https://github.com/borismus/sonicnet.js demonstrating why this claim needed more than his personal assertion to be considered truth.
3. The main logical fault is the extended discussion about how limited the BIOS environment is, apparently under the belief that somehow everything must be implemented at that level rather than, say, shipping with different versions for various manufacturers which use that as a way to inject the actual payload into the OS. Put another way, what are the odds that someone would be competent enough to build any of the other pieces but not realize that you can do hardware detection and build a library of exploits for, say, common Mac laptops?
4. Claims about being able to catch this trivially by dumping the BIOS are suspect unless he's talking about extracting the chip and reading it on a known-good system — anything running on the suspect box runs into a textbook trust problem which isn't even acknowledged in this post.
To make that concrete: I've known about commercial penetration test software[1] that uses multiple levels of agents, trading off footprint vs. capabilities, for over a decade. This is not even remotely a new idea.
[1] E.g. Core Impact from http://www.coresecurity.com/
I think he claimed that packet counts increased with the network hardware pulled from the system - maybe it knows how to stuff them into the loopback interface's queues.
The other option is that you don't have to do full tcp/ip over the "audio link" since it would only be used for specific types of traffic. If you control how the sender transmits you can ditch a ton of the tcp/ip logic and just hardcode to a minimalist subset of functionality.
Ignoring that this doesn't make any sense as a symptom for communication over an audio channel - the whole reason he believes that it is communicating is because a packet counter increased. Not because he has any logs, or because he observed it being controlled, or because he saw any code doing this.
Why are we even discussing the feasibility of the covert channel if the only reason that this topic was even introduced was because he saw packet counts increasing?
I can think of a million benign reasons why packet counts would increase on an unplugged system. That in no way means that the system is compromised or communicating externally. It's not even a reason to be suspicious.
He saw packet counts increasing and it stopped when he disabled the audio hardware. Then there is all the other circumstantial evidence regarding booting from a CD, "self-healing" and systemic blocking of his debug attempts.
I think it is absolutely fair to critique the individual symptoms but the one critique that doesn't fly is that an individual symptom is the only symptom.
Ignoring that this doesn't make any sense as a symptom for communication over an audio channel
In what way does that not make sense?
I guess if you think that detail adds meaning, there's not much I can say.
> Then there is all the other circumstantial evidence regarding booting from a CD
This is extremely common. Macs have had flaky CD booting issues for ages.
https://discussions.apple.com/thread/4292694
"After doing a software update, my Mac Pro got stuck on the gray screen after restart (seems like a very common problem recently). I am able to boot into safe mode by holding shift (only works like 10% of the time) and verified permissions. It says I need to repair my disk, but i can only do this by booting from my install disk.
However, I can not boot from my install disk. It gets stuck at the gray screen every single time."
> "self-healing"
Didn't happen. Because there was nothing to self-heal.
> and systemic blocking of his debug attempts.
It didn't block any debug attempts. He says it disappears on him when he goes to look at it. That's because it isn't there. That's like saying the ghost beside me is evading my photography attempts, and citing this evasion as proof that something is up.
> In what way does that not make sense?
Beeps on the speakers or listening on the mic doesn't involve packets to begin with! Even if that was true, it wouldn't make packet counts go up. You would have to go out of your way to implement this in the stupidest possible way for your audio channel to have anything to do with a network interface. Compared to the obvious way, it would take way more code, completely ruin your stealth, be far less reliable, and add a ton of packet header overhead over what is already extremely low bandwidth. You cannot be smart enough to implement this malware and also be stupid enough to put your covert channel through network interfaces. Yet we are supposed to believe it's so stealthy that no debugging tools can see it ever, and it's disappearing from low level memory accesses and disk reads wherever he looks for it. But it's spewing packets out on an interface that it doesn't actually need to communicate. I mean...really?
All communication is analog at the lowest level, all common forms of network transmission are serial at the lowest level -- your analysis is all argument from ignorance.
Then there is the Blurt project - an 802.11 physical layer interface that runs over speakers and microphones. Its early stage but its just one guy hacking at it, not some billion dollar spy agency.
No, but evidently yours is. Sorry, this is quite straightforward to anyone who has ever used a packet sniffer. The fact that it's analog has nothing whatsoever to do with how packet sniffers work, and he wasn't monitoring a serial bus.
Blurt doesn't do what is being described here. It wouldn't show up in packet logs. Which proves my point.
Here's a simplified start: all common network interfaces transmit serially at the physical layer - one bit at a time, wired ethernet, wifi, 3G/4G/LTE, WiMAX, fibre channel, dsl. None of them are inherently packetized at the very lowest level, they are all just a series of bits. Packetization is done through either synchronous clocking (fixed transmission periods) or, more commonly today, asynchronously via a special sequence of bits that indicate start/stop of a packet.
This is layer 1 of the OSI 7 layer model, we are not even talking packetization like a typical packet sniffer would see, that comes after the physical interface has decoded the transmission like OFDM and undone the 8b/10b then stripped off the bits that make up stuff like the preamble and frame delimiter in the case of ethernet.
Packet sniffers typically work at layer 2, where you can see things like MAC addresses or layer 3 where you see full-fledged IP packets. You run wireshark and you won't see things frame-start bits or the 8b/10b encoding because all that stuff is going on at a level that packet sniffers aren't intended for.
Any audio-based network system like Blurt and the suspected BadBios mechanism would be a full layer 1 implementation. They might do higher layers too or they might encapsulate IP packets and hand them off to the OS's network stack to handle, but the idea that "beeps" don't involve packets is pure ignorance of how modern datacomm systems work. It is ALL analog "beeps" at the lowest level, be it EM "beeps" or audio "beeps." Packetization occurs further up the stack.
1. Play audio on one endpoint and record it from another
2. Open wireshark
YOU WON'T SEE THE AUDIO.
This is how he claimed to see it was communicating. Over IPv6 no less. IF it was happening, it wouldn't show up in a packet sniffer.
I will send you $100 if you can configure wireshark to do what you describe. Using any of the tools in this thread, or any of your own, go ahead and try capturing even 1 packet from an audio interface in wireshark and post the pcap file.
It's not over anyone's head - we have interns who understand why this doesn't work. I have no idea why you might think it would.
Because bridging an air-gap firewall is the holy grail of network penetration. You can't discover the guy on the other side of the air-gap without "spewing" announcement packets.
.... except, at the BIOS level, there aren't many "system libraries". It's basically bare metal.
In the future, AMI might add some OpenGL interfaces, too (see http://www.uefi.org/sites/default/files/resources/8_-_UEFI_S...)
There's a tremendous amount of projects demonstrating amazing things that can be done with much less computing resources available than a BIOS. I have _very_ little doubt that bit-twiddled 12-20kHz audio communication could easily be implemented in under 10% of the 383kB that seems to be available. (Assuming the speaker and microphone are available as GPIO-like interfaces to the BIOS/CPU.)
For that matter, since this thing is claimed to be on the visibly network there's also no reason why additional code couldn't be downloaded — the sound part is claimed as a slow covert channel for an already infected system.
This doesn't mean that BadBIOS is true — only that it's annoying and tedious to play the skeptic with shoddy logic and trust-me assertions being presented as facts.
I made no changes, didn't turn off the music my phone was playing to a bluetooth speaker, etc. This is using the built-in speakers & mics at unadjusted volume levels – the only change I made was unmuting one of the two laptops.
As for the specificity of the BIOS environment - he's saying you'd need to compile the BIOS code against the manufacturer's libraries AND make versions specific to board revisions. ESPECIALLY if you're doing stuff like initializing and using the soundcard (which he also addresses).
So for it to be true, this malware would be created by someone with access to several codebases and hardware docs, etc, of different motherboard manufacturers. Not to mention the test lab they must have to make sure this all works.
Not to mention the fact that in THREE YEARS none of this has been made open. OR a USB analyzer hasn't been tried, etc.
Way too many red flags here.
Hopefully someone will get some more definite evidence soon (eg, an external logic analyzer on the USB wires during a machine infection).
He asserted it but there are working demos showing this being possible. Which of the two is more convincing?
> As for the specificity of the BIOS environment - he's saying you'd need to compile the BIOS code against the manufacturer's libraries AND make versions specific to board revisions. ESPECIALLY if you're doing stuff like initializing and using the soundcard (which he also addresses).
The BIOS doesn't need to contain everything, only the portion needed to load an exploit which compromises the OS and uses the normal code to talk the soundcard, network, etc. Just as no operating system in existence needs to have per-board boot loaders, this doesn't need to do more than load the next stage.
> Way too many red flags here.
Again, I'm not saying the BadBIOS claims don't require proof - only that a post which is confused about those claims and makes arguments which are contradicted by running code isn't a good critique.
For instance, the author of this story claims that UEFI binaries are not compatible with each other. The kernel and processor support blobs of a UEFI ROM are not interchangeable, but more and more, the drivers are: UEFI does not just provide an API, but it also provides an ABI for both drivers and binaries to run. (That's the whole point of it.) Graphics card vendors do not have to produce a new driver for each UEFI implementation and motherboard; and, of course, Microsoft and Red Hat each produce just one UEFI bootloader shim, designed to run on every UEFI-compatible machine. The modular structure of UEFI ROM images, if anything, makes it more plausible that malware could inject itself "cleanly"! [1]
The argument about the BIOS not being able to initialize sound hardware is also surprisingly less-than-true these days. A handful of UEFI ROMs are now capable of calling up the sound card to "speak" error messages, if things have gone wrong during boot. The audio codecs, even if the UEFI ROM doesn't have code of its own to initialize, are relatively well-known, and easy to find datasheets for; I would imagine that a driver for one could be packed into 5 to 10kB of tightly written code, so there's no reason why the BIOS couldn't have this.
As acdha said upthread, too, there are other problems: the author conflates RF and audio frequencies; the BIOS protects its read access through System Management Mode (and hence could hide itself); etc., etc., etc.
Now, none of what I said here is to say that I believe Dragos's claims -- I don't. There are lots of good ways to dismantle his claims, and many people already have. But, well, the "the BadBIOS Analysis is wrong" is wrong.
[1] The author also gets quite a lot more wrong about the PC boot sequence in his technicalities. For instance, the "2Mhz 8088" is just not true these days; different processors boot in different ways, and most of the time, there is not even any DRAM available when the first instructions run! I put this as an aside because it is not part of my main point, but it serves to illustrate additionally how the author is using things that just aren't quite right to back up his argument.
(edited: removed excessive ad hominem against the author. My apologies.)
I should disclaim that I know nothing about the author of this piece, and my knowledge of this whole area of computing is extremely limited. I just mostly suspect that the BadBIOS story is ridiculous.
I agree. The Ars piece yesterday seemed a bit paranoid and short on details. Then this piece today seems to be blowing smoke in the opposite direction. Somewhere in between lies the truth.
I'm hoping we'll hear of something more concrete in the coming days or weeks.
That, and the "UEFI binaries are unportable" bit really indicate that the author doesn't know very much about UEFI.
(Aside of my own: there are typically at most two places in x86 UEFI where you can find 16bit code: first at the init vector, where it sets up the system to move to 32bit - and then 64bit modes - as fast as possible, even before initializing DRAM at all. The other place is the CSM, which provides the legacy BIOS interface, if necessary)
To note: this is a single binary that works on all x86_64 UEFI systems and can be written to the boot partition as any other file. Additionally, you can write a program to change boot order on UEFI bioses from within a running OS; example: efibootmgr. So while it is probably infeasible to infect the BIOS itself, it is somewhat trivial to infect the bootloader and do whatever you desire.
IIRC, the Code Red worm wasn't a terribly large exhibit of malware, but it still managed to propagate.
As it stands, I think the biggest complaint currently regarding badBIOS is the lack of information. Until we find out more, much of the commentary in the linked article (and the comments here and elsewhere) are little more than conjecture.
Still, conjecture can be fun! Let your imaginations run wild--until we get something more concrete.
You only need to transmit the carrier at the high (inaudible) frequency, you can receive at any sub harmonic frequency as long as the transmission protocol is designed with this in mind.
So a carrier signal broadcast at 20KHz (within the range of the speakers) but inaudible to most humans can be picked up by sampling at 10KHz (within the range of laptop microphones). The protocol just needs to send each bit twice (or any multiple of two) at 20KHz.
If you want to stay ultrasonic you will need to use a narrow bandwidth around 20k, otherwise people with a good hearing and children will be able to hear it. I don't think you'll be able to receive anything useful by using a cheap PC microphone at 10k in those conditions, especially if you use it in the way it is intended to be used (the hardware will filter out high freq to prevent aliasing)... Maybe there is a convoluted way to receive a specially crafted transmission by sampling in a subharmonic when a special antialias filter (or no filter at all in otherwise quiet environment) is used.
I don't see much point in trying to use such a channel to transmit bios malware related stuff anyway. The original badBios article seems to be just a joke.
Considering how much research goes into these bootkits/rootkits lately, it is interesting. Kernelmode has some ideas on it(http://www.kernelmode.info/forum/viewtopic.php?f=16&t=2998) and are running a thread on it. This is a rather unique malware though if it even does the airgap communication as well.
The thread you linked to doesn't contain any findings, but it does contain an analysis of Dragos' UEFI showing it to be completely clean, with the code matching the original factory image.
1) Everyone keeps saying that a BIOS dump will show what's happening here. If the "BIOS Dump" function a feature of the bios/motherboard itself, wouldn't the malware have the ability to exclude itself from the returned dump?
2) The argument about a bios-specific malware not being possible because the BIOS itself is not transportable. Couldn't the malware perform a dump of the bios, inject itself based upon a series of patterns found in the dump, and restore itself with the malware intact?
This is absolutely insane, and I don't know what to believe. I do however enjoy thinking about the possibilities that exist in our world.
And that accessibility means that it'll probably end up getting created sooner or later.