What makes OS drivers dangerous for BIOS?
I was very interested in the recent discovery of UEFI rootkit Lojax by ESET researchers. But after some analysis, I was surprised by the simplicity of the delivery/infection methods used by this rootkit. Basically, all the techniques used by Lojax is already known for the years from the past discoveries and presentations by BIOS researchers. Also, Lojax has multiple common techniques with HackingTeam rkloader rootkit (NTFS parser, FS injection technique with tracking EFI_EVENT_GROUP_READY_TO_BOOT). In this blogpost I want to focus more on the topics related to techniques for UEFI firmware exploitation from OS (especially MS Win10).
A lot of people thinking about BIOS exploitation as something really difficult but a lot of vendors think about firmware security differently. Sometimes it creates very easy targets. As an example sometimes they just leave SPI flash open on write or don’t authenticate BIOS updates properly. In the last two years, this picture significantly changed in the positive direction. But not all the vendors the same (as you can see from the slides of my talk “Betraying the BIOS”). To understand this kind of attacks, we need to think more about attacker tactics for persistent schemes of infection from the operating system. What does the attacker need to do in order to be able to modify the SPI flash memory? I have visualized the necessary steps for the possible remote scenario:
Stage 1 User-Mode: A client-side exploit, such as web browser remote code execution (RCE), drops a malicious installer onto the system. The installer then uses another exploit to elevate its privileges to LOCALSYSTEM and continues execution with new privileges.
Stage 2 Kernel-Mode: The installer bypasses code signing policies (discussed in Chapter 6) to execute its code in kernel-mode. The kernel-mode payload (driver) runs an exploit to gain privileges to SMM.
Stage 3 System Management Mode (SMM): The SMM shellcode successfully executes, and privileges are elevated to SMM. The SMM payload disables protections of SPI flash memory modifications.
Stage 4 SPI Flash: All SPI flash protections are disabled and the flash memory is open to arbitrary writes. The rootkit/implant is then installed into the firmware onto the SPI flash chip. The highest level of persistence in the system is reached.
This generic infection scheme comes from my mind some time ago when I was working on research “UEFI Firmware Rootkits: Myths and Reality” presented last year. Lojax rootkit has been abused legit and signed driver (RWEverything) for the attack on BIOS from OS. Almost the same approach used for PoC with UEFI ransomware on MS Win10 (with all updates installed for the time of presentation). The main difference is the driver (AMI Firmware Update tool) used to communicate with UEFI firmware.
The main problem with vendors of UEFI Firmware update tools they using the same approach to deliver the update as UEFI rootkit will use for the attack on BIOS. In the recent update (RS5) for Win10 some of the drivers have been blocked by code integrity checks (HVCI based on blacklist approach) include RWEverything. But it’s hard to block all legit BIOS update tools. I don’t believe it’s possible without alternative ways to deliver an update.
RWEverything is not a hack tool. It’s actually a very useful tool for hardware assessment accidentally turned to the dual-use direction a long time ago before Lojax been discovered. Multiple BIOS researchers have been using this driver for PoC development back to 2014. Also, in 2016 Dmytro Oleksiuk released his PoC code for RwDrv.sys on github. Intel chipsec tool also uses techniques in their driver (unsigned) to collect information about the hardware/firmware configuration. Let’s dig into the root of causes which actually makes this driver dangerous and interesting from the attacker perspective.
All these drivers use a legit kernel-mode function MmMapIoSpace() to have RW access to the physical memory space and compiler intrinsics __outbyte() or __inbyte() to write/read into hardware ports (or can be also used directly as assembly instructions in or out). As an example, this function is enough to have read access to the memory region where the configuration of BIOS protection bits stored (BLE, BIOS_WP …). To call SMI handler for exploit vulnerability attacker need access to write into the physical memory to map input parameters and shellcode for SMI handler and write to the hardware port to invoke SMI handler.
In this blogpost any place where mention SMI handler I talking about software SMI handlers which are invoking over APMC I/O Port 0xB2. BIOS developers trying to reduce the numbers of active SMI handlers accessible this way but for compatibility a lot of them still active.
Most of BIOS update tools from common vendors use a user-mode application as a part where all the logic created for the update process and the kernel-mode driver as a proxy to work with physical memory space, write MSR’s, call SMI’s. But any other 3rd party application can load manually this driver and use in the same manner.
As an example, Lenovo Thinkpad BIOS update tool uses tpnflhlp.sys driver which is exactly a proxy like described before. A perfect example of the dual-use signed driver for creating an attack like Lojax did with RWEverything. Also, it contains hardware port R/W functionality as well. Perfectly works on MS Win10 v1809 (tested on one of my recent Lenovo laptops).
Another example AMI Firmware Update Tool (AFU) where signed amifldrv64.sys looks even worst from dual-use perspective. It has implemented a different type of SMI handlers where parameters received from ACPI. Everybody blames RWEverything as firmware rootkits swissknife tool but AFU looks more dangerous for me. Also, tested on Win10 with recent updates and works perfectly.
I demonstrate this two examples only to describe the problem which is hard to solve without architectural changes and unified BIOS update process supported by OS. Definitely blacklist approach will not help and only create a pseudo security feeling. Nowadays I can see how much more hardware vendors start to focus on the security of the firmware but more attention needed for the whole ecosystem include a BIOS update tools too.
