What Can We Learn From badBIOS

As time passes it becomes increasingly likely that we are unlikely to see compelling confirmatory evidence from Dragos Ruiu regarding his claims surrounding the malware he has coined badBIOS. One of his latest tweets begins with the disclaimer “No matter which way things work out with this search” which appears to be a stark contrast to the convincing way he spoke about his discovery just a few weeks earlier.

I’ve mentioned on this blog that malware of the type described is indeed technically plausible. One could produce a piece of traditional Windows malware that pulls the current BIOS image and attaches its own code to the image before reflashing. The small payload could simply ensure persistence in much the same way as the venerable anti-theft solution Computrace which was embedded into laptop BIOS images as an ISA component to assure persistence even if the HDD was replaced or erased. Computrace’s BIOS code had rudimentary NTFS support that allowed it to replace a file that Windows executes on boot (rpcnet.exe) with itself. The original file is renamed and is loaded by the persistence code once it has done its thing. In much the same way a trojan could either include its own code (if it was small enough) or run a small downloader to reinfect the machine. As many PCI devices include option code that the BIOS will execute on boot (e.g. PXE code from a NIC or a RAID controller’s array test code) this could also be a potential means of ensuring your code is executed at boot time.

The most controversial claim that Dragos made was that the malware was able to breach an airgap by using a laptop’s built in microphone and speaker. I have elaborated on this in a previous post and even linked to a functional proof of concept. Suffice to say that using the audio hardware to create a low speed mesh network is indeed possible but may be of low utility as throughput would be limited and the risk of detection would be significant. The latter could be minimized by incorporating some kind of negotiation to test the upper usable frequency of the hardware as high frequency characteristics differ wildly between vendors and are dependent not only on the DAC but also the speakers itself (with ceramic speakers being much more favorable) and vice versa on the receiving end. Another technique would be to first sample the ambient noise in the room. It is possible that while a quiet room would allow for an ideal SNR if stealth is the goal a moderately noisy environment may be more useful to mask the noise generated. By using the system clock and sampling the ambient noise the malware could determine a likely time when the environment is unattended (e.g. if it is 0300 local time and the area has been silent for many hours it is a fair bet everyone has gone home). Using the minimum effective amplitude would also make sense.

The most incredible remark that Ruiu has made was that the malware was cross platform and could spread via a USB thumb drive on both Windows and BSD with the latter occurring even when the device hasn’t even been mounted. While we can speculate that the malware was somehow modifying the flash controller of the infected USB thumb drives to present some kind of string that would exploit the system during USB device enumeration I believe the likelihood of not only this occurring but also of the bug being leveraged to allow some kind of cross platform infection is remote. This appears to be the weakest of his arguments.

If we assume for the sake of this argument that Dragos has misdiagnosed the existence of badBIOS, what can we learn from the experience? Well, certainly the first lesson to any aspiring security researcher would be to organize themselves prior to going public. Our hypothetical researcher should have concrete proof that an issue exists and have elucidated the purpose and origin of the malware. It would also help to have a sample of the malware to share with others. Even if this delays your disclosure by weeks or months, it is imperative that you can successfully defend your findings. Failing to adhere to this advice could be disastrous to your reputation and by extension your future career prospects.

Secondly, if you need external help then there should not be an issue in asking for it. Sometimes a second set of eyes will be able to resolve an issue that an individual could be stuck attempting to understand for an extended period of time. From Ruiu’s public discourse on Google+ and Twitter it appears that he has been sitting on badBIOS for approximately three years. Bringing in the community at an early stage and doing so without poorly researched grandiose claims of a new “advanced persistent threat” (ad nauseum) would be well advised.

My final point is that you can bet that malware authors have been reading all about Ruiu’s allegations regarding badBIOS’s feature set and at least some of them will attempt to emulate some of the traits that Ruiu suggested badBIOS possessed. This means that malware that leverages audio hardware or perhaps ensures its own persistence by appending itself to your current BIOS image (in much the same way as Mebromi) are likely just around the corner. In a way, just speaking about badBIOS will likely bring something similar into existence in the medium term.

We can hope that this has drawn some attention toward some aspects of the PC architecture that really aren’t all that robust. Perhaps the ability to flash a BIOS from within the operating system has seen the end of its useful life. In this day and age where all BIOS setup tools have their own integrated flashing tool with USB support then it would make sense to deprecate and eventually remove the ability to reflash except within setup. Cryptographically signing BIOS updates won’t necessarily mitigate some of the issues we have touched on so long as vendors continue to produce BIOS customization tools for their OEMs that invariably leak or are reverse engineered.

I sincerely hope that Dragos Ruiu’s analysis is at least partially on target, however as time goes by I am becoming increasingly skeptical that we will obtain the evidence that we are looking for to confirm the existence of such an advanced threat. Nevertheless as security professionals we must consider the entire system as a whole to assess its overall security. The ability to reflash the BIOS (and other peripherals that, by extension could allow arbitrary code injection on startup) from within user mode remains a concern of mine that is yet to be fully mitigated.