In our upcoming Black Hat Vegas talk, we will summarize our research about the UEFI firmware protections and our newly-discovered security problems.
This talk raises awareness of these security challenges for hardware vendors, BIOS-level security researchers and defenders, and sophisticated stakeholders who want to know the current state of UEFI exposure and threats. The situation is serious but, with the right tools and knowledge, we can prevail.
The state of UEFI firmware security has become more serious in the last few years. On one hand, there has been an increase in activity from the security research community leading to increase in reported UEFI firmware vulnerabilities (Year-over-Year) as the UEFI ecosystem became more and more complex. On the other hand, more and more information about UEFI implants has become available, for example, HackingTeam and state-sponsored implants.
But most often, this information becomes public because of leaks, primarily because no detection tools are available and UEFI implants are typically used for targeted attacks. Recently, Intel has announced a new bug bounty program, which also includes the firmware. Hopefully, their effort will lead to more secure firmware.
UEFI’s place in the world has grown rapidly in the last few years, from the desktop/laptop and server market to the Internet of Things (IoT), mobile, automotive, drones, etc. Fortunately, UEFI security has advanced in many different directions, too. The level of security demonstrated by some modern enterprise hardware vendors has greatly improved.
But not all hardware vendors are the same. Unfortunately, some vendors don’t enable the protections offered by modern hardware, such as the simple protection bits for SMM and SPI flash memory (BLE, BWE, PRx), which Intel introduced years ago. This makes them easy targets for attackers, since they have no active memory protections at the hardware level.
In my talk at Black Hat Asia this year, I demonstrated these kinds of weaknesses with the installation of a persistent rootkit inside SPI flash (from Microsoft Windows 10 with active Secure Boot). In the abstract of presentation “Firmware is the New Black - Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities” for Black Hat Vegas, the security researcher from Intel mentions the number of 90+ security vulnerabilities handled by Intel Product Security Incident Response Team (PSIRT) in the past three years, alone.
Modern operating systems like Microsoft Windows 10 are relying more and more on firmware security, because firmware is becoming the defacto root of trust in many cases. The problem with this is, of course, that if the firmware is compromised, all the next levels of the system boot process can be broken, including Secure Boot.
Modern operating systems have started developing more security technologies for hardware-assisted memory isolation, as an example Microsoft Virtual Secure Mode (VSM). It is very difficult to guarantee the same level of OS security on different hardware and UEFI firmware.
Hardware vendors, such as Intel, have introduced new protection technologies like Intel Boot Guard (since Haswell) and BIOS Guard (since Skylake). Boot Guard protects Secure Boot’s “Root of Trust” from firmware-based attacks by verifying that a trusted UEFI firmware is booting the platform. When BIOS Guard is active, only guarded modules can modify SPI flash memory; this can protect from persistent implants. Both technologies run on a on platform reset (different with reset-vector) it executes in protected AC-RAM on main CPU, known as the “Authenticated Code Module” (ACM), which isolates them from attackers and protects from race condition attacks. Those "Guard" technologies are sometimes referred to as UEFI rootkit killers.
Quick Look Into Intel Boot Guard
Let’s look briefly on some details about Intel Boot Guard implementation. There is no official Intel documentation publicly available about this technology yet. Only one presentation from the past year, at the ZeroNights conference, is available with some reconstructed technical details.
The classic UEFI Secure Boot root of trust starts from UEFI Driver Execution Environment (DXE) phase. This phase is almost the last one before control is passed to the operating system bootloaders. If UEFI firmware is compromised at this stage, an attacker can completely bypass or disable Secure Boot.
Without hardware-assisted verification, there is no way to guarantee integrity on the early stages of the boot process before DXE phase including verification of the DXE drivers. Intel Boot Guard technology has been introduced since Intel 4th Generation of CPU (Haswell) and accessible on the hardware supported intel vPro. CPUs like Atom, Quark, and other budget processors don’t come with these advanced security technologies built in.
Intel Boot Guard is a very complex piece of technology with a lot of flexibility for hardware vendors to support and tweak it. The integrity verification flow starts from reset which is the first step for Intel x86 hardware boot process. After that CPU microcode (bootrom) authenticate ACM code and verify following stages of boot flow:
All pieces of Intel Boot Guard are stored in the UEFI firmware image. When hardware starts booting, the assisted microcode loads the firmware image into the memory and extract all the components. For faster navigation into the firmware image, parser uses Firmware Interface Table (FIT) that provides offsets to specific sections stored the modules. The Firmware Interface Table is partially documented in Intel EDK2 github repository in the header file FirmwareInterfaceTable.h. (https://github.com/tianocore/edk2/blob/master/IntelSiliconPkg/Include/IndustryStandard/FirmwareInterfaceTable.h).
Figure 1
UEFITool, an open source tool for UEFI image navigation, can parse FIT table from the firmware update image and help us find parts associated with Boot Guard technology. The result of parsing for UEFI image supported Intel Boot Guard looks like this:
Figure 2
The ACM, IBB, Key Manifest, Boot Policy, and associated PEI and DXE modules can be extracted from the firmware update image. But if everything can be extracted and modified, how does this technology protect the integrity of the keys and digital signatures from malicious modifications? The hardware called Field Programmable Fuse (FPF) stores the value of the hash of OEM public key. The FPF can be programmed only one time and the hardware vendor should lock the configuration during the manufacturing process.
The following figure shows the full chain of the root of trust for Intel Boot Guard technology.
In our Black Hat talk and upcoming blog posts, we will discuss more technical details and show the attack scenarios, including implementation mistakes in different hardware, which can lead to the bypass of measured and verified boot schemes of Secure Boot. We will also provide tools for reverse engineering Intel Boot Guard technology from the firmware update image. But first, we wanted to highlight one particularly interesting piece that we looked into.
What Is Inside ACM?
The Authenticated Code Module (ACM) is interesting and one of the most mysterious parts of Intel Boot Guard technology. The ACM executes in isolated memory before the reset vector. The Boot Guard ACM verification checks measure the integrity of Initial Boot Block (IBB) before passing control to the IBB entry point. If IBB verification fails, the boot process will be interrupted.
The IBB part of the UEFI firmware (BIOS) executes on a normal CPU (not isolated or authenticated). Next, IBB continues the boot process, following the Boot Guard policies in verified or measured mode to platform initialization phase (PEI). The PEI driver verifies the integrity of the DXE drivers and continues the transition of the chain of trust to DXE phase. The DXE phase continues transition of the chain of trust to operating system bootloaders.
The ACM uses Intel’s Trusted Platform Module (TPM) and Trusted Execution Technology (TXT) for hardware-based attestation. The ACM module is authenticated by microcode before execution. The extracted ACM module with UEFITool contains the header and the code. The header also contains the RSA digital signature, which is highlighted in the following figure:
Figure 3
The integrity of the ACM module is controlled by microcode, which makes it very difficult for ACM code modifications. I reverse engineered the structure of the ACM header from the firmware drivers. I will provide more detailed explanation of this structure in our Black Hat presentation.
Figure 4
From the reconstructed structure, we can see the type of CPU is x86 compatible for ACM code execution. The ACM code is developed and supported by Intel. Most likely the updates from Intel delivering to the hardware vendor in the same way as microcode updates. Entry point value can help us to find the main routine inside the code section. The reverse engineering process has uncovered few interesting tidbits:
- ACM code parses and extracts the main structures responsible for IBB Manifest (IBBM) and Key Manifest (KM)
- ACM verifies Initial Boot Block code before execution
One or two sentences about why this is interesting. What impact does this potentially have? What advantage does an attacker gain due to these two points?
The entry point routine for Intel Boot Guard ACM module extracted from target hardware looks like this:
Figure 5
First, we called on the entry point responsible for Intel Boot Guard intizialization, which contains manifests parsers. After that, we can see the GETSEC instruction with 3 as a value in EAX register, which is the main exit from Authenticated Code (AC) and transfer control to non-AC code responsible for IBB.
The following is responsible for the parsing of IBBM and KM manifests:
Figure 6
Very few technical details are publicly available about these Intel technologies (Boot/BIOS Guards). In my presentation, I will discuss the implementations on hardware with the most recent Intel CPUs, such as Skylake and Kaby Lake. Most of the information has been extracted from UEFI firmware modules by reverse engineering. The DXE and PEI modules cooperated with the ACM-code for enabling, configuration, and initialization.
Our talk will also cover some weaknesses of those guards. In the presentation, we’ll answer where the BIOS guardians are failing and how difficult it is to bypass these protections and install a persistent rootkit from the operating system.
Currently, we are in the disclosure process with multiple hardware vendors (ASUS, MSI, Gigabyte, and Lenovo) regarding the vulnerabilities which we found during the research for our Black Hat talk.
Here’s the Breakdown of What We’ll Cover in Our Black Hat Vegas Talk:
- Introduction to known UEFI implants/rootkits techniques, as well as the evolution of future attacks.
- Reverse engineering UEFI firmware update process. How most common vendor update tools work? The problems of BIOS update software with active MS Virtualization Based Security (VBS) features and Device Guard. Some techniques to install malicious unsigned firmware update with active Secure Boot from the operating system.
- Intel Boot Guard overview. The results of reverse engineering UEFI modules responsible for Boot Guard configuration. The weak policies and common mistakes in Boot Guard configurations. Comparison of different vendors’ implementations (at least four).
- Intel BIOS Guard overview. The results of reverse engineering UEFI modules responsible for BIOS Guard configuration. The weak policies and common mistakes in BIOS Guard configurations. Comparison of different vendors’ implementations (at least four).
- Methods of rootkit infection on a system with active Boot Guard and BIOS Guard.
- Mitigations, or how to configure modern systems with fancy Guard technologies to be secure.
- Conclusions. Summary of bypass techniques and weaknesses. Future plans and research directions.
