A couple of interesting items in the news recently hinting that BIOS malware might just become a problem in the next few years, mainly the debate over whether there’s anything in the ‘badBIOS’ story, and Jacob Applebaum’s exposure of the ANT Catalog at 30c3 the other week. Originally I was going to do a post exploring these, but in the absence of details, a mini literature review on published research would be more useful.
The best stuff I found was by John Heasman of NGS Consulting, two researchers from CORE Security (write-up posted on PHRACK), and another two researchers from Invisible Things Lab. One interesting thing to note is they all date from 2007-2009, just like the ANT Catalogue, which suggests the NSA team hadn’t fully developed the capability at the time.
Typical BIOS Roles and Features
As most people know, the BIOS is the Basic Input/Output System that performs a quick hardware test and fetches the loader from the Master Boot Record when the computer is switched on. Actually a series of other things happen between the processor, BIOS and system memory before anything is fetched from the MBR, and the BIOS contains routines that function as an interface to the hardware during runtime. It must also be capable of printing characters to screen and reading input from the keyboard independently of the OS anyway.
During runtime software applications can read tables maintained in the BIOS to query hardware states. What I also didn’t know until recently is the BIOS typically scans the system for extension ROMs in other hardware components, and whatever code is found within those is loaded into memory before execution prior to the bootloader.
Accessing the BIOS from User Mode
Several command line tools are available that demonstrate that it’s at least possible to query and footprint the BIOS from user space in Linux (with root privileges). I spent about 20 minutes trying out the following.
The dmidecode utility provides limited information about the BIOS vendor, firmware version, its physical memory address, ROM size and other characteristics:
#dmidecode -t bios
It’s also possible to acquire the data structures of the BIOS with biosdecode:
But a malware author would ideally want to dump the BIOS image, do a bit of static analysis and develop an exploit. It’s possible, if the BIOS image exists in system memory during runtime:
#dd if=/dev/mem of=/home/michael/testdump.dump
Since the capture (testdump.dump) is much smaller than the available system memory (which is only memory that’s visible to the OS, and half is designated kernel space), it’s theoretically possible to load this into something like Bokken and read the contents at the ROM addresses we got with biosdecode and dmidecode. Unfortunately I didn’t have much luck, with Bokken crashing before I could reach the address.
Alternatively it’s possible to work on a firmware image supplied by the vendor. In any case, the elements are all there – we have Flash memory that could be read and written to by user-space software, hardware ROMs becoming resident in system memory and hardware interrupts providing entry points to the code.
PCI and Hardware Extension ROMs
Onto the research, the first source I came across (via SecDocs.org) was John Heasman, who discussed the use of BIOS and PCI devices to hide malware. His method leaves no trace on the hard disk, which would make forensic acquisition and analysis extremely awkward.
The main problem Heasman was trying to solve is how to get something in the hardware/firmware layer running at the OS layer during runtime, and his solution was to do it through the ACPI.
Some of the hardware must be initialised before the boot process, and x86 initialisation codes are stored in the ROMs of these devices. What happens is the BIOS (during the POST) will scan the PCI bus, and copy whatever code it finds from the expansion ROMs into physical memory, then sequentially execute them. All this happens before the OS even begins to load.
At a later point, if the ROM images are still resident in memory, hardware interrupts, which are basically signals for whatever routines to execute, are used as an entry point to the memory location containing the malicious code. Again, notice that nothing is written to the hard disk throughout this process.
Detailed as the work is, Heasman discussed only one-way communication, from low-level to OS level. What’s missing is the method for getting code onto the hardware layer in the first place.
Reverse-Engineering and Reflashing BIOS
Anibal Sacco and Alfredo Ortega of CORE Security took a very different and conceptually more straightforward approach of grabbing a BIOS image, reverse-engineering and modifying it, then reflashing the target machine. All they needed was to replace a ROM module within the chip and replace the checksum, so it wouldn’t be read as a corrupted module. I’m assuming the ROM module would be executed and become resident in the physical memory during POST, alongside the PCI expansion modules.
It’s probably easier to pull off, and unlike Heasman’s work, the malicious code here is stored on the BIOS chip itself, which means it’s going to be limited to something basic like a simple backdoor, some code injection or a shell command. This method would also leave traces on the hard disk, as it would require some way of getting root access and reflashing the BIOS with the new image.
Exploiting the Intel BIOS
Rafal Wojtczuk and Alexander Tereshkin reference Heasman’s work, but they ask the question of why we don’t see malware actually reflashing the BIOS and they focus on the security measures that might prevent it.
It turns out that attempting to reflash the BIOS from user space only schedules an overwrite, since the BIOS chip is locked at some point during the boot process, and the actual work happens when the system is next booted. This shouldn’t make any difference, as the firmware still gets overwritten anyway, potentially without the user being aware of it. They also looked at loading stuff through PXE, but this would happen at a later stage of the boot process after the locks have been applied to the BIOS chip.
Another problem they worked around was code signing, which applies to almost (not quite) all the fimware, and they worked around this by modifying the one thing that isn’t signed – the BIOS splash image, which is displayed before any locks are applied. Using the Intel Integrator Tookit, it was possible to embed arbitrary code or an exploit into the .bmp file, perhaps to overflow the buffer, overwrite another part of the BIOS and get something else to execute.
Whatever the NSA is supposed to have done and whatever the truth behind badBIOS, this research shows what the cutting edge was at the time. At most, I think the malware listed in the ANT Catalog is for targeted attacks against specific networking hardware, and to implant simple backdoors on routers/firewalls with static IP addresses. Hardware would have to become standardised enough across personal computers (including laptops, tablets, etc.) to provide a common attack vector before it’s something the average person needs to worry about. But again, we only have limited information about what the NSA allegedly did five years ago.
Another reason we don’t really encounter it in the wild is the proof-of-concept attempts were by researchers who already had physical access to the BIOS chip, plus the ability to perform all the stages to get the code onto their own systems. A malware creator would have to develop a method that’s invisible, automated, reproducible across say 50% of machines, and reliable, then somehow integrate that with an exploit.