9 ms·

The BadBIOS Analysis is Wrong

92 points by llimllib 13y ago

deleted 13y ago
[deleted]
wmt 13y ago
I honestly didn't think that anyone was seriously saying that the BIOS code was doing all that, just that the BIOS was infected so that it boots the malware instead of an OS.
- Zancarius 13y ago
  Or you can use the malware to affect the behavior of a known OS and get it to do the rest of the work for you. 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.
tptacek 13y ago
Looking around for that animated GIF of a young Michael Jackson eating popcorn in the movie theater...
- llimllib 13y ago
  I reply to the important comments. http://media.giphy.com/media/ftXvsSyRzKXXG/giphy.gif http://media.giphy.com/media/ftXvsSyRzKXXG/giphy.gif
diorray 13y ago
I still think it's a halloween prank
- akinity 13y ago
  Me too. But if we say nothing about believing this to be a prank, do we become the prankors?
- sitkack 13y ago
  It feels like it. It also feels like it has kickstarted the real thing. I feel like working on it myself.
- oakwhiz 13y ago
  "I want to believe"
maddddddddddddd 13y ago
this analysis that it is wrong is wrong. basically he says, "this would be really hard, so it can't be real"...... uh..... not an argument. then, he says, "i have a tool that can scan for this, so it could never avoid my tool".... again, at such a low level it could detect your tool or hide itself in one of the many other chips on the motherboard that provide data IO. #DUMGUYISDUM
acdha 13y ago
The badBIOS story is frustratingly short on details but this confused post seems to be making a lot of assumptions which add restrictions and then argue that it's impossible because of those guessed details: 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 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.
- saidajigumi 13y ago
  > belief that somehow everything must be implemented at that level 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/ http://www.coresecurity.com/
  - lawnchair_larry 13y ago
    That is not an example of what the author is talking about. Core agents are not implemented at different levels in the system vs bios sense. Impact doesn't have anything at all similar to what badbios is claimed to be doing.
- 13y ago
jevinskie 13y ago
This is a hard article to read between the arrogance of the author and their writing style (I counted six instances of "Period.").
- jaxbot 13y ago
  While you nitpick on grammar, I'll remind you that "their" is plural. ;) /s
  - 0A0D66 13y ago
    Ahem : https://en.wikipedia.org/wiki/Singular_they https://en.wikipedia.org/wiki/Singular_they
  - gfody 13y ago
    He obviously meant the indefinite, generic and epicene, non-referring anaphor "their" and not the definite, plural, referring pronoun "their".
  - growupkids 13y ago
    That person got their argument wrong.
yuhong 13y ago
As a side note, I wonder why nobody bothered to create a UEFI sound protocol.
- geofft 13y ago
  I've heard that this was a deliberate limitation so that nobody has the clever plan of trying to run their general-purpose OS without leaving UEFI. And that accessibility means that it'll probably end up getting created sooner or later.
jlgaddis 13y ago
FWIW, @rootwyrm is a pretentious know-it-all. Take anything he claims with a grain of salt.
jwise0 13y ago
Dragos's original writing is, in fact, mostly incoherent, and highly suspect. However, this article seems to be almost as far out. 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.)
- llimllib 13y ago
  Could you link some of the good Dragos debunkings? 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.
od2m 13y ago
THANK YOU!
anonymous 13y ago
I would like to point out that the modern way to er.. "sidestep" the windows activation process on a UEFI system is to simply install a new bootloader. This is accomplished simply by writing a compiled EFI program to the EFI boot partition and setting it as your bootloader. It them lies to the kernel and makes it think it's running on an already-activated OEM system. Look up WindSLIC, I can't really give a link here for obvious reasons. 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.
- delroth 13y ago
  Infecting the bootloader has been a known technique for a while though (google "bootkits") - long before UEFI, actually. They are the whole reason behind Microsoft pushing for SecureBoot. This is not new, nor what badBIOS is supposedly about.
switch33 13y ago
Uhm. . . http://www.slideshare.net/matrosov/modern-bootkit-trends-bypassing-kernelmode-signing-policy http://www.slideshare.net/matrosov/modern-bootkit-trends-byp... 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 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.
- lawnchair_larry 13y ago
  Bootkits have nothing to do with what is described by this article and badbios. They reside on the filesystem. 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.
alexkus 13y ago
> High-frequency transmission requires that you have elements capable of transmitting externally at very high frequencies and elements capable of receiving at very high frequencies. 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.
- xorblurb 13y ago
  Your sentence "The protocol just needs to send each bit twice (or any multiple of two) at 20KHz." nearly makes no sense. You should learn about modulation, sampling, aliasing, and so over. 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.
- wiml 13y ago
  I think it'd be much easier to use spread-spectrum techniques. With enough coding gain the signal can even be well below the noise floor and still reliably recoverable. (This is the spread-spectrum equivalent to sending a very narrowband signal and receiving it through a very narrowband filter.) Generating a DSSS waveform is extremely computationally cheap; receiving one is less so, but probably still negligible amount of cpu time on a modern processor.
xorblurb 13y ago
Leaving aside the crazy hypothesis coming from nowhere about sound transmission, what can probably be done is hiding a persistent malware in a microcontroler connected to the smbus. Very hard to detect, most (all?) modern motherboards already have at least one, FW distinct from the bios, might not be even readable without a dedicated hardware programmer and custom wiring (even in this case the FW might be locked down), and probably can own the whole system. IIRC the smbus goes pretty much everywhere in a modern computer.
wcummings 13y ago
I'm not sure why he assumes the entire virus would be implemented in BIOS, as opposed to injecting code into the OS when it loads code of the disk during boot. Still kinda out there, though.
mb0 13y ago
I'm not a bios expert, and have a few questions: 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.

92 points by llimllib 13y ago

deleted 13y ago

[deleted]

wmt 13y ago

I honestly didn't think that anyone was seriously saying that the BIOS code was doing all that, just that the BIOS was infected so that it boots the malware instead of an OS.

Zancarius 13y ago
Or you can use the malware to affect the behavior of a known OS and get it to do the rest of the work for you. 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.

tptacek 13y ago

Looking around for that animated GIF of a young Michael Jackson eating popcorn in the movie theater...

llimllib 13y ago
I reply to the important comments. http://media.giphy.com/media/ftXvsSyRzKXXG/giphy.gif http://media.giphy.com/media/ftXvsSyRzKXXG/giphy.gif

diorray 13y ago

I still think it's a halloween prank

akinity 13y ago
Me too. But if we say nothing about believing this to be a prank, do we become the prankors?
sitkack 13y ago
It feels like it. It also feels like it has kickstarted the real thing. I feel like working on it myself.
oakwhiz 13y ago
"I want to believe"

maddddddddddddd 13y ago

this analysis that it is wrong is wrong. basically he says, "this would be really hard, so it can't be real"...... uh..... not an argument. then, he says, "i have a tool that can scan for this, so it could never avoid my tool".... again, at such a low level it could detect your tool or hide itself in one of the many other chips on the motherboard that provide data IO. #DUMGUYISDUM

acdha 13y ago

The badBIOS story is frustratingly short on details but this confused post seems to be making a lot of assumptions which add restrictions and then argue that it's impossible because of those guessed details: 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 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.

saidajigumi 13y ago
> belief that somehow everything must be implemented at that level 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/ http://www.coresecurity.com/
- lawnchair_larry 13y ago
  That is not an example of what the author is talking about. Core agents are not implemented at different levels in the system vs bios sense. Impact doesn't have anything at all similar to what badbios is claimed to be doing.
13y ago

jevinskie 13y ago

This is a hard article to read between the arrogance of the author and their writing style (I counted six instances of "Period.").

jaxbot 13y ago
While you nitpick on grammar, I'll remind you that "their" is plural. ;) /s
- 0A0D66 13y ago
  Ahem : https://en.wikipedia.org/wiki/Singular_they https://en.wikipedia.org/wiki/Singular_they
- gfody 13y ago
  He obviously meant the indefinite, generic and epicene, non-referring anaphor "their" and not the definite, plural, referring pronoun "their".
- growupkids 13y ago
  That person got their argument wrong.

yuhong 13y ago

As a side note, I wonder why nobody bothered to create a UEFI sound protocol.

geofft 13y ago
I've heard that this was a deliberate limitation so that nobody has the clever plan of trying to run their general-purpose OS without leaving UEFI. And that accessibility means that it'll probably end up getting created sooner or later.

jlgaddis 13y ago

FWIW, @rootwyrm is a pretentious know-it-all. Take anything he claims with a grain of salt.

jwise0 13y ago

Dragos's original writing is, in fact, mostly incoherent, and highly suspect. However, this article seems to be almost as far out. 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.)

llimllib 13y ago
Could you link some of the good Dragos debunkings? 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.

od2m 13y ago

THANK YOU!

anonymous 13y ago

I would like to point out that the modern way to er.. "sidestep" the windows activation process on a UEFI system is to simply install a new bootloader. This is accomplished simply by writing a compiled EFI program to the EFI boot partition and setting it as your bootloader. It them lies to the kernel and makes it think it's running on an already-activated OEM system. Look up WindSLIC, I can't really give a link here for obvious reasons. 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.

delroth 13y ago
Infecting the bootloader has been a known technique for a while though (google "bootkits") - long before UEFI, actually. They are the whole reason behind Microsoft pushing for SecureBoot. This is not new, nor what badBIOS is supposedly about.

switch33 13y ago

Uhm. . . http://www.slideshare.net/matrosov/modern-bootkit-trends-bypassing-kernelmode-signing-policy http://www.slideshare.net/matrosov/modern-bootkit-trends-byp... 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 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.

lawnchair_larry 13y ago
Bootkits have nothing to do with what is described by this article and badbios. They reside on the filesystem. 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.

alexkus 13y ago

> High-frequency transmission requires that you have elements capable of transmitting externally at very high frequencies and elements capable of receiving at very high frequencies. 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.

xorblurb 13y ago
Your sentence "The protocol just needs to send each bit twice (or any multiple of two) at 20KHz." nearly makes no sense. You should learn about modulation, sampling, aliasing, and so over. 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.
wiml 13y ago
I think it'd be much easier to use spread-spectrum techniques. With enough coding gain the signal can even be well below the noise floor and still reliably recoverable. (This is the spread-spectrum equivalent to sending a very narrowband signal and receiving it through a very narrowband filter.) Generating a DSSS waveform is extremely computationally cheap; receiving one is less so, but probably still negligible amount of cpu time on a modern processor.

xorblurb 13y ago

Leaving aside the crazy hypothesis coming from nowhere about sound transmission, what can probably be done is hiding a persistent malware in a microcontroler connected to the smbus. Very hard to detect, most (all?) modern motherboards already have at least one, FW distinct from the bios, might not be even readable without a dedicated hardware programmer and custom wiring (even in this case the FW might be locked down), and probably can own the whole system. IIRC the smbus goes pretty much everywhere in a modern computer.

wcummings 13y ago

I'm not sure why he assumes the entire virus would be implemented in BIOS, as opposed to injecting code into the OS when it loads code of the disk during boot. Still kinda out there, though.

mb0 13y ago

I'm not a bios expert, and have a few questions: 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.