BIOS Level malware attack

[f0dder]

Uh... oh...

Via slashdot:
[attachimg=#]

I guess the attack would have to be BIOS-specific (for finding a spot to put the malware) and slightly chipset-specific (for flashing the code to BIOS flashrom), but it's nasty nevertheless... combine this with SMM exploit and a hypervisor, and you're unremovable (except of course on motherboards where the flashrom chip can be removed from the motherboard - most seem to be directly soldered on, though).

Undetectable is still hard, even with a hypervisor, and I doubt it can be fully done. But you can go very stealthy.

[gexecuter]

That's pretty awful, if someone would release a virus that messes with your BIOS like that i would feel pretty scared.

[40hz]

The concept has been proposed before. And there have been several urban legends about so-called rogue BIOS infections. However, if this story turns out to be true, this is the first time anybody who figured out how was willing to demo it.

Either way, it's worth noting that in order for something like this to work, somebody has to flash the BIOS. It doesn't install itself. It requires user intervention. Or does until they start to deploy  self-updating BIOS chips. (Don't hold your breath on that one! ) And even then, requiring a simple hardware switch setting to flash the BIOS would stop it cold.

Unfortunately, there's nothing anybody can do to completely protect a system from its owner's actions.

So how much has changed in the wake of this development? Not much really. I don't think this is going to be all that big a security threat. It's just going to be one more potential risk we'll need to be aware of and watch out for.

In the past, we never used to worry all that much about flashing our BIOS. Now, maybe we should. Just a little...

[f0dder]

40hz: you don't need the user to do anything - it's not like the idea is to create an infected image and have the user flash that to his BIOS.

Instead, you use whatever traditional infection vector that gives you admin/root privileges. From there, you a drive (Windows) or LKM (Linux) to go kernel-mode/ring0, from where you have full access and can re-flash the BIOS.

The flashing process is going to be chipset-specific, but how much I don't know - I would assume that there's a couple of standard flash controllers, so you don't have to support a lot of different ones. Whether the type of controller can be auto-detected I don't know either. This is one part of the challenge.

The second part of the challenge is finding a "bios cave" to hide your malware in. This is probably easier than it sounds, though - scan the BIOS space for an appropriately large block of zeroes. From what I remember about BIOS initialization sequences, BIOSes will at boottime scan their memory image at <some kilobytes> boundaries looking for a magic identifier. When such a magic identifier is found, and a checksum after the chunk matches, an entry-point in the chunk is called; this is used for BIOS extensions, and you can think of this type of malware as, well, a BIOS extension. The tricky part here is exploiting the system in a way that doesn't interfere with chipset setup and such, but it's probably doable doing this relatively generically.

AFAIK there hasn't been any malware/rootkits doing this before, the closest was the CIH virus which would simply erase your BIOS... which is of course bad enough. Many BIOSes these days have "flash protection", but I'm not sure how well that works - does it disable the flash controller, and can it be re-enabled by software without a reset cycle? (certain CPU features like hypervisor support can be disabled, and once disabled requires a reset cycle to be re-enabled... should be possible to use the same design for flash controllers, but is it done that way?)

[Stoic Joker]

Found this while polking through the information above. It's a group of papers from older hacking conferences that (somewhat) outline the history of this attack vector.

@f0dder - From what I was reading, if you start early enough in the BIOS execution, they (pretty much) all start in the same place, so it doesn't really need to be that BIOS specific. (e.g. The initial "launch" is very one size fits all...)


From the Persistant BIOS Infection paper:
- The first instruction executed by the CPU is a 16 byte opcode located at F000:FFF0

- The Bootblock POST (Power On Self Test) initialization routine is executed.

- Decompression routine is called and every module is executed.

- Initializes PCI ROMs.

- Loads bootloader from hard-disk and executes it.

[Eóin]

Any chance locking BIOS flashing either through a setting or a jumper on the motherboard would make things safer or is that really just a superficial lock?

[Stoic Joker]

Any chance locking BIOS flashing either through a setting or a jumper on the motherboard would make things safer or is that really just a superficial lock?

The "spin" that most of the researchers seemed to put on it implied that that would be a good start ... but it didn't eliminate the isue of other hardware items being targeted.

I'm not intimately familliar with the low lever archetecture stuff ... but I can follow the conversation, and the upshot is that everybody was so busy trying to defend the OS that the box it ran on was completely ignored ... until now. ...Which kinda makes for an "Oh Shit" ripple effect. ...Best I can tell.

Looks like this thing has been brewing since 03.

[4wd]

... (except of course on motherboards where the flashrom chip can be removed from the motherboard - most seem to be directly soldered on, though).

And any motherboard that has dual BIOS chips since the 'backup' BIOS is generally non-writable, (well, at least on the Gigabyte boards), so you can always cross-flash the normal boot BIOS back into the hacked BIOS.

IIRC, the Gigabyte boards also default back to the non-writable BIOS if something out-of-ordinary is detected in the default boot BIOS, (I'll have to read my manual a bit more I think).

[Stoic Joker]

... (except of course on motherboards where the flashrom chip can be removed from the motherboard - most seem to be directly soldered on, though).

And any motherboard that has dual BIOS chips since the 'backup' BIOS is generally non-writable, (well, at least on the Gigabyte boards), so you can always cross-flash the normal boot BIOS back into the hacked BIOS.

IIRC, the Gigabyte boards also default back to the non-writable BIOS if something out-of-ordinary is detected in the default boot BIOS, (I'll have to read my manual a bit more I think).

Not quite, because you still have to boot the afflicted Mboard to perform the flash. In which case the "Bugg" can simply block the overwrite of its own block. The creators of the expliot referred to this "feature" as being trivial to implement.

[f0dder]

... (except of course on motherboards where the flashrom chip can be removed from the motherboard - most seem to be directly soldered on, though).

And any motherboard that has dual BIOS chips since the 'backup' BIOS is generally non-writable, (well, at least on the Gigabyte boards), so you can always cross-flash the normal boot BIOS back into the hacked BIOS.

IIRC, the Gigabyte boards also default back to the non-writable BIOS if something out-of-ordinary is detected in the default boot BIOS, (I'll have to read my manual a bit more I think).

Not quite, because you still have to boot the afflicted Mboard to perform the flash. In which case the "Bugg" can simply block the overwrite of its own block. The creators of the expliot referred to this "feature" as being trivial to implement.

Well, if the backup BIOS is used to boot, the malware isn't going to activate, is it?

[Stoic Joker]

I'm not so sure ... If the backup BIOS is accessed with a jumper, then true the bugg has no change to jump in. but if the backup BIOS is acessed via hotkey then the bugg has time to load while the keyboard is being found.

At least that's the impression I got from one of the articles from your link.

[f0dder]

In the case of hotkey, I guess it depends on how early bios-selection code is done - and whether you do a 100% targeted attack or aim for a generic method.