NOTE2: Holy crap lots of comments and I find out that the comment setup isn’t threading them properly so it’s a BEAR to try and make sense of. I am truly and terribly sorry about that. Talk about counter-productive to a conversation! Trying to see if there’s some way to fix this.
NOTE: Approving comments as I get time. If I didn’t do it yet, I just haven’t gotten to it. If I don’t approve yours, it’s either because A) you made it clear you didn’t read or have no clue what you’re talking about, and therefore detract from the conversation or B) you’re trolling / blindly defending / blindly attacking to derail the conversation. In either case, rebutting basic ignorance of technology, complete lack of reading comprehension or someone just being an ass is a waste of everyone’s time. Including your own.
Look, I’m not known for pulling punches and I’m not about to start now. The fact is that everything I have read about #badBIOS is completely and utterly wrong; from the supposed “escaping air gap” to well.. everything. And I should know. I’ve dealt with malicious BIOS and firmware loads in the past. I’ve also dealt with BIOS development and modification for two decades. It’s a very important skill to have when you regularly build systems that are well outside manufacturer ‘recommended’ areas.
The whole of the analysis would be laughable if people weren’t actually taking it seriously and believing it because they’ve seen edge cases or very specific examples. And the result is that they’re looking in the wrong place.
First and foremost, the very idea that there is some malicious BIOS load that can escape airgapping and is portable is beyond laughable. I don’t care what you think you know – BIOS code is not portable, period. Oh, sure, you can have a common source for multiple motherboards. But every single model, revision and minor version requires you to recompile UEFI elements best case. That’s before you get into changes to UEFI libraries and shells.
Secondly, the concept that BIOS malware could somehow escape detection is beyond laughable. Look. I’ve been doing BIOS work for ages and then some. I can and would spot any malicious load pretty much instantly even before flashing a board. Certainly I would have no trouble finding it from a ROM dump. Period.
When I open a BIOS dump in American Megatrend’s MMTool (this is for Aptio V, their UEFI product,) I can not only see but extract every single executable element of the BIOS. That includes CPU microcode, Ethernet Option ROMs, sound hardware firmware, you get the idea. A simple comparison instantly exposes modifications to almost any element. This is not a ‘freely available’ tool, but a bit of searching will easily get it in your hands.
Still not enough for you? Here’s a partially annotated report from MMTool. Notice something? Yeah. Firmware volumes are broken down into paged regions. This is an 8MB (64Mbit) AMI BIOS for a Gigabyte motherboard – which makes it one of the largest BIOSes on the market. Most UEFI motherboards are 4MB (32Mbit). There’s not exactly a lot of room – though I’ll be the first to say I’ve seen a lot more in a lot less. (Scene, ho!)
Here’s the point: any modification here is easily spotted, picked out, and disassembled. Attempting to encrypt anything here would render it so highly system specific that it would literally only work on one computer in the entire world (at least in theory) due to signature fail. And any time you modify any one of these elements, the non-accessible checksum region will alert you. “BIOS Checksum Error: Press F1 to continue, DEL to enter SETUP” is a dead giveaway.
Not only that, but a BIOS is extremely extremely specific. This is code that operates at a level most people are completely incapable of conceptualizing these days. Literally, until you’re in the UEFI shell itself, your $1000 Xeon E5 is a ~2MHz 8086. Not figuratively – quite literally. It’s called real-mode and it’s part of why we have the atrocity that is UEFI.
Regardless, you’re still at an extreme level of specificity because you’re literally manipulating pins and wires alongside registers. You can’t just take an AMI ROMBIOS8 from one board and slap it on another. Yes, there’s a common core – that’s why we have AMI, Phoenix Technologies and used to have Award (plus Insyde as used by Sony/HP.) But to actually use that core requires extensive work to support the specific silicon and wiring used by a given motherboard. That information is always trade secret, and heavily protected.
This is what makes the belief that systems are air gapping with high frequency so utterly hilarious. First of all, yes, it is absolutely possible in theory and there have been proof of concepts using FPGAs and unshielded boards. ProTip: your laptop or desktop meets zero of these conditions period. First of all, to end up on your desk the system requires substantial EFI/RMI shielding which prevents transmission of said signals using voltage varying techniques. Secondly, manipulating said voltages requires running code which can only ever run on one extremely specific motherboard (not even multiple revisions) and is easily detected at 6+ different points before the fault inducing aspects nevermind the relatively low precision of a typical PC SMPS.
And the idea that someone could just release into the wild a multi-platform multi-motherboard highly resistant BIOS because of UEFI only exposes epic ignorance of what UEFI is. UEFI is NOT A DAMN PORTABLE EXECUTABLE SYSTEM. It is about PORTABLE CODE, and even that is fundamentally broken – Intel Tiano code will not run on Phoenix SecureCore will not run on Aptio V will not run on InsydeH2O without modifications. The end. Period. Actually running the code means building it against your target platform – the same as portable C. (Hey, funny how UEFI which uses C behaves just like portable C code, isn’t it? Siiiiiiigh.)
And the idea of it using the sound card to defeat airgapping is beyond hilariously wrong. PC Speaker != Realtek AC889. You have no audio input at the BIOS level because the MIC line even if present isn’t hooked or initalized. People quit wasting precious shadow RAM region on BIOS-level sound card initialization to play sounds around ’05 because it’s pointless and sucks. Oh, you think it does because it makes a “bong” over speakers? NOPE. That’s a soft hook to a GPIO-like soft-trigger in the audio codec’s firmware. Been done in laptops since the late 90’s. So the BIOS is NEVER listening to the microphone, and you don’t have a speaker capable of HFT anyway.
Look. Basic audio 101. A given element has a specified input/output range. Your typical laptop microphone has an input range of say 5,000Hz to 14,000Hz just as an example. Anything outside that range clips to uselessness or is ignored. Your typical laptop speakers are maybe 160Hz to 20,000Hz if you’re lucky. Again: you are SOL. Oh, and anything in that range would be audible too. 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. Between those limitations and FCC mandated and required shielding from high frequency interference, there’s a reason every POC has required one or more unshielded elements.
Is it possible? Yes. In theory it is possible to release an extremely resilient and resistant BIOS level piece of malware. It also would only ever infect one specific machine ever, period. It also would not be even remotely capable of escaping detection using basic diagnostic techniques. Not even advanced security techniques; just basic BIOS diagnostics. Anyone who can follow a guide on updating the Intel RSTe OROM (about half the Internet) could compare dumps and instantly spot it.
So what do I think? I think that A) a number of security experts flapping their gums are good at security and know nothing about how hardware works and B) it’s absolutely not a BIOS/Firmware level piece of malware. There are far, far too many blatant and obvious detection points. There is no way it could hop from Apple to PC, or even PC to PC or Macbook 2013 to Macbook 2011. (Forget Macbook to Mac Pro.)
I’m not saying that UEFI or BIOS is secure – I’ll get to that in another post – but I am saying that calling it badBIOS is wrong. It’s absolutely not. Either it is an extremely limited piece of BIOS malware or it is occurring at the OS and escaping detection through previously unknown methods. Half the claims made regarding what it does (disabling registry editing, etc.) are so far from reasonable and possible with the BIOS it makes me facepalm. Point blank, these things are absolutely not possible, period. This is something going on at the OS level, the end.