"BadBIOS" features explained
blog.erratasec.com
blog.erratasec.com
[1] http://en.wikipedia.org/wiki/John_Forbes_Nash,_Jr.#Mental_il...
I only say this because people want us to take these claims on faith, citing a credential that he hasn't actually established. Furthermore, his tweets so far seem to be full of rookie mistakes. I've seen a fair number of "security enthusiasts" do exactly what he is doing.
My first impression was that badBIOS was an elaborate troll on the part of Ruiu, to make the point that just taking what even a "well-respected researcher" says at face value is NOT good security practice.
His actual claims, as far as I can determine and as corroborated by the Errata Security article, are: (1) that BIOS firmware, and potentially also built-in peripheral device firmware, might serve as a durable reservoir for malware; (2) that buffer overflows and similar sloppy coding practices in USB HID device drivers can serve as infection vectors; (3) that pre-existing malware can use ultrasound as a (buggy, flaky, slow) C&C protocol transport; and, finally and most controversially, (4) that he has live examples, as yet unpublished, of malware which demonstrates all three of these behaviors.
Claim 1 seems not particularly controversial, given that prototypes have been demonstrated at conferences.
Claim 2 has at least one example in the wild, in that a PlayStation 3 jailbreak has successfully used the exact method described as a code injection vector. The PS3, of course, is a static target; how well the method scales to the PC platform is therefore an open question, but given the apparent relative paucity of implementations available, it seems at least plausible as a useful attack vector for malware.
Claim 3 is theoretically valid and, as another HN user pointed out [2] in response to my own skepticism on the subject, has at least one strong proof of concept in the wild.
Claim 4, of course, is unverifiable at this time; given Ruiu's provenance in the field, though, I'm with the Errata Security writer in considering that Ruiu deserves the benefit of the doubt, on the presumption that he'll soon substantiate the claim.
At most, then, his claims are 25% extraordinary, and I argue it took a useless hack like Goodin to make them seem even that much so -- to say nothing of all the recent speculation with regard to Ruiu's mental state, which I can only ascribe to a spectacular failure among HN commenters to consider the source -- specifically, the source of that Ars Technica article, whose lack of credentials should be plain to anyone with the time and interest to examine his journalistic history. What in God's name possessed Ruiu to give a hack like Goodin an interview is entirely beyond me, but that's as close to a sign of poor or impaired judgment as I can see.
I've heard this referred to as the "Nobel disease": http://rationalwiki.org/wiki/Nobel_disease
The surprise is not that, when given a relatively subtle and complex topic such as this, he made such an utter hash of it that the subject of his interview came off like a paranoid schizophrenic. The surprise is instead that Ruiu didn't know better than to give a third-string jackass like Goodin an interview in the first place.
Is it true that if you control the firmware, then you control what the dumps of that firmware will look like? The only way I can imagine getting a clean dump of that machine is by desoldering the chips and imaging them via some specialized tool. If the machine's firmware is rooted, how can you trust any signal the machine sends, especially firmware dumps? The virus could trivially hide itself by detecting a firmware dump is in progress and sending a decoy (clean) image.
Then you can use an external EEPROM reader that can dump the contents, but is not capable of running the code.
The EEPROM is storage only; it's contents are loaded by the PC at boot. So if it is removed, there is no processing that an occur internally than can mask the data inside of it.
EDIT: Sorry for being unclear. I'm aware EEPROM can be overwritten. But presumably that requires special privileges, or a special circumstance (like the user physically holding some button on the motherboard during bootup, or something). The article isn't at all clear how it's possible to write a program that escalates its privileges to such an extent that it can then overwrite EEPROM. Is it really possible? How?
Electronically Erasable Read Only Memory
It's re-programmable (i.e. by re-flashing it).
edit: I should add that motherboard manufacturers could prevent this type of attack by "locking" the BIOS for flashing unless it was explicitly unlocked by changing a setting in the BIOS menu (some have this already, I believe). The problem at the moment is that the BIOS is writable at all times, even when the OS is running. This makes BIOS updates easier (i.e. you can make a Windows application that can do so, for example), but the problem is that this allows ANY process with Admin access to alter the BIOS as well.
I'm speechless that this horrible idea was ever taken seriously, much less implemented. That answers my question as to how a BIOS could become infected.
I'm seriously sitting here in shock. How could any hardware manufacturer think it was a good idea to let a userspace program permanently alter EEPROM, ever? One does not need to be very intelligent to realize hackers will hack that.
This brings us full circle to the original question, though: Did the security researcher write a program to dump the contents of EEPROM rather than desoldering the chips? if so, then he may have been hoodwinked by the virus.
Because most hardware manufactures are selling to consumers and not cypherpunks.
Is this different than getting a dump of the BIOS before flashing it? Are we talking about different chips on the motherboard?
The '80s solution to this problem was way easier, and it worked: a switch on the motherboard required physical access to the machine to flash its firmware.
I'm willing to give Dragos the benefit of the doubt here and just assume that Dan Goodin has his head so far up his ass he can't see clearly and that Dragos has no intention of misleading people.
But having these issues for 3 years? Let's just say that extraordinary evidence needs to come out fairly quickly now. Or at least a massive correction of the hype here. Surely, in 3 years, someone else would have discovered this thing.
I disagree. The definition of plausible is "seeming reasonable or probable".
To say "the idea is completely possible" might be accurate but has a completely different meaning.
A security researcher discovering malware that infects several different BIOS types including on PC and Mac hardware with every major operating system that can spread via USB and communicate via sound between standard speakers and a standard microphone over distance and then going about his normal day-to-day life over the next three years is the very definition of improbable.
1 superficially fair, reasonable, or valuable but often specious <a plausible pretext>
2 superficially pleasing or persuasive <a swindler… , then a quack, then a smooth, plausible gentleman — R. W. Emerson>
3 appearing worthy of belief
No, all you said is that it's plausible. Plausible != possible.
I understand the point being explained here, but is this really accurate? I don't know of any SDR platform, let alone a "dongle" with anywhere near the capacity necessary to operate as a wifi AP.
it's been possible to operate a variety of wifi cards in host AP mode for like 10 years or more. have a search and you'll see this is easily doable.
Maybe some radio smartperson can clarify?
(802.11ac is out of bounds, its channels are 80MHz minimum.)
Hardware backdooring is possible - By Jonathan Brossard http://www.youtube.com/watch?v=yRpilXPv8pU
(This one more recent from nullcon, made a splash from DefCon 20 earlier).
It's not really much of a stretch that an agency (commercial, criminal or government) that dedicated a few man-years of work could come up with something along these lines.
There's really only one-and-a-half "out there" claims: the "half" being networking via audio, the "one" being cross-platform.
It'll be interesting to see if they manage to grab a dump of the malware and we can get more eyes looking at it...
(edit: actually called UEFI: EFI is an old name...)
It doesn't implement PCBIOS APIs (those int10h calls everyone came to lo{ve,athe}), but neither does a PC BIOS implement CP/M BIOS functions.
For the BadBIOS topic (and many other firmware debates), the "UEFI isn't BIOS" thing is useless semantics:
PCBIOS, EFI and UEFI serve the same purpose: They initialize the hardware, load the OS loader, then provide some amount of services to the OS (just through different means).
All of them provide runtime services to the OS (that the OS might or might not use). All of them have extensive control over the OS at all times through SMM, even if the OS decides not to use those runtime services. And all of them make use of these capabilities.
That is: All of them survive the boot process and have a considerable level of control over the hardware at all times.
Are we looking at a future where a standard OS install is a multi-VM situation?
Of course, you're merely moving your trust anchor from code (verifiable, easy to subvert) to CPU (unverifiable, hard to subvert). Pick your poison.
> Dragos believes that two infected computers can communicate with each other over the audio port
Infected computers. The audio communication is between infected machines. It is not the vector of initial infection.
"We had an air-gapped computer that just had its [firmware] BIOS reflashed, a fresh disk drive installed, and zero data on it, installed from a Windows system CD," Ruiu said. "At one point, we were editing some of the components and our registry editor got disabled. It was like: wait a minute, how can that happen? How can the machine react and attack the software that we're using to attack it? This is an air-gapped machine and all of a sudden the search function in the registry editor stopped working when we were using it to search for their keys."
"Ruiu posited another theory that sounds like something from the screenplay of a post-apocalyptic movie: "badBIOS," as Ruiu dubbed the malware, has the ability to use high-frequency transmissions passed between computer speakers and microphones to bridge airgaps."
I presume the computer that had reflashed BIOS, fresh disk drive, with zero data, installed from a Windows System CD, was uninfected. Then it became infected. Then he mentions a theory that it jumps airgaps with speakers and microphones.
This strongly implies that the claim is of a virus that jumps airgaps from an uninfected machine to an infected one through sound.
Which part of this is incorrect?
(Also, the claim that infected computers communicate via sound to bridge airgaps is not mutually exclusive with the claim that infection can spread over airgaps. So what you quoted does not contradict this claim, which is why I didn't take it as a refutation of my previous reading).
At no point has anyone believed a never-infected computer would become magically infected via audio. You are looking for such a suggestion and finding it in poor writing. In reality, it is not there.
If you want to lambast Ars Technica for shitty writing, go right ahead, but don't criticize Dragos's claims until you are certain you know what they are. And as we all know, such a certainty can never come from the press. You must go to the source. Read Dragos's Google+ page and his Twitter feed. And read them carefully, not hastily and not with the intent of finding fantastical claims where they don't exist.
You've been primed by a sensationalist article to look for something sensational. Be conscious of that.
You have crossed from facts which you know into speculation about my mental processes, and in fact you are incorrect about the latter. Without any preconceptions about this whatsoever, I read the Ars article and it strongly suggested to me that the claim was that the infection itself had spread over an air gap.
Otherwise, why even lead from this story into the theory of communicating via sound? If indeed the computer was already infected, then it would be no surprise that it could do something like interfere with running a registry editor. The air gap jumping would be entirely irrelevant to the story.
In other words I'm agreeing with you that the Ars article was misleading. But my initial comment was not meant to be critical of Dragos or anybody else. It was an honest, uncharged question about how my reading of the Ars article would be possible, even theoretically. The answer (it sounds like) is that the Ars article misled me about what Dragos was actually claiming.
However I'd advise to limit the impact UEFI can have on a system (which, right now, is universal). And sometimes I even work on it (https://github.com/pgeorgi/edk2/tree/coreboot-pkg)