this comment is interesting
It’s obvious you are not an InfoSec guy. If you were, you would know that we’ve had hypervisor based rootkits for some time that can evade traditional forensic analysis. Meaning, you will get a bios dump from whatever virtual environment the malware presents to you.
Try thinking of it this way…
You have a piece of malware that attacks USB micro-controllers. This vastly reduces the scope of the attack as there are only a handful of vendors out there (six I think). This is stage 1.
Stage 2 is the installation of the hypervisor rootkit (google ‘blue pill rootkit’ for a working example of this). This does not have to be installed into the BIOS. In fact, I don’t think the BIOS is getting modified in any meaningful way, other than disabling booting from the CDROM. It’s important to note that this rootkit could actually include an embedded system with an IPv6 stack and audio drivers.
Stage 3 is the downloading of further components to hook into the specific guest OS.
But, to be clear, I’m not saying this is what is happening. What I am saying is that everything described so far is both technically possible and in most cases has already been demonstrated by IT security researchers.
Phillip's response http://www.rootwyrm.com/2013/11/the-badbios-analysis-is-wrong/#comment-2251
Edited by AlphaC - 11/3/13 at 3:26pm
Well, never claimed to be. But as I said, I am a BIOS guy. I’ve been up to my guts in it for many, many years.
The problem herein is that even your initial payload would have to be absolutely and utterly board specific. The other factor in it is the space and limited facilities. Hypervisors run in, you guessed it, protected mode. And on nearly any compatible hardware. Not so with something in the BIOS. In addition to that, you’ve got very, very limited space to work with. Where by ‘limited’ I mean ‘none.’ Let’s say I wanted to load a UEFI driver that hijacks memory space to figure out the OS and download a payload – that means it has to go into Volume 02. Well, your typical UEFI Aptio V BIOS, it’s not technically possible.
Consider this. UEFI gives you all the tools, sure. But you still need room for the initial bootstrap itself. Typical UEFI board has 32Mbit to 64Mbit of SPI Flash. The Supermicro X9SCM/X9SCL family with 64Mbit? Has 6KB or less available. Sure, you can do lots in 64KB using various tricks. But 6KB or less? Something that complicated? Even leveraging the UEFI networking stack, that’s not enough room for something that complex. I mean consider the most comparable known one: Flame. The payload is 20MBish. And any bootstrap has to NOT interfere with the majority of the BIOS, since that would prevent the system from operating potentially. There’s no value in a bricked system, and nobody on earth is going to put that much effort into something with a significant risk of bricking. There are much easier ways to brick it thanks to the lack of security in BIOS handling – which is another post.
As I mentioned: my suspicion is that there’s a bootstrapper lurking on a GPT boot layout as a boot sector virus, which would give it the ability to stealth payload, leverage certain common UEFI behaviors, and escape detection through non-interference. (Run payload, boot normal device.)