Who Watch BIOS Watchers?
On the last Black Hat event in Vegas, I presented the first publicly known concept of attack on a specific implementation of Intel Boot Guard technology (mostly undocumented as a technology). When I worked on this research one thought it bothered me: the specification of technology can be perfect but after that, the implementation part goes to the third-parties and it is challenging to maintain proper level security in this case. Intel Boot Guard is an excellent example of a complex technology where exist a lot of places where making a small mistake allows an attacker to bypass full technology. I proofed on practice how many mistakes can be done and demonstrate on Gigabyte hardware with modern CPU an insecure configuration with fully active Boot Guard. But before we go deep into Intel Boot Guard details let’s talk a little bit about why the firmware issues can be serious problems.
Why Firmware Security is Important?
From the attacker’s perspective, the more logical way to do things nowadays is to simply move to the next level down into the software stack — after boot code, that is the way to the BIOS.
The BIOS level of persistence is very different with anything else. The firmware implants or rootkits can survive after an operating system reinstallation, or even after a full hard drive change. It is an entirely different level of persistence, which can keep the rootkit infection active for the whole cycle of usage of infected hardware. The firmware level is the last boundary before the hardware, as it is precisely the BIOS that starts the initial stages for the hardware setup into the boot process. An increase of mitigation’s on OS level will cause the rootkits complexity and motivation for the attacker to go into the firmware space.
Also in I want to pay attention of the readers to the research published on Black Hat 2017 by Intel “Firmware is the New Black — Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities”. Where the authors pay attention to the significant increase of the security issues in UEFI firmware security space. This research shows the data for the last three years accordingly to Intel PSIRT. On the next chart, present vulnerability distribution over the years (the chart copied from original public available Intel’s slide deck).
We can clearly see the increase of the class issues “Platform capability not properly configured” were third-parties’ vendors responsible mostly for all those bugs. This class of bugs was exactly about implementation mistakes when developers forgot setup something or don’t follow to specification. Accordingly, Intel we have the following description for this class of security issues: “Locks not set, devices not properly initialized, features not disabled, etc”. But this kind of issues also can be a result of supply chain attack when hardware insecurely reconfigured or infected by malicious firmware’s or implants. Also, an interesting news comes from Google about Titan chip focused on protecting hardware root of trust by this chip. It’s getting critical to trust your hardware configuration especially when we are talking about the cloud security where the impact multiplies by the number of affected clients.
This approach when the company develops their own hardware to control platform root of trust can become popular for big clouds and data companies like Amazon, Google, Microsoft, Apple, etc. Specifically with Titan even if the platform has been compromised by firmware rootkit isolated root of trust will prevent Secure Boot attacks and firmware update attacks because of controlled Platform Controller Hub (PCH) and Baseboard Management Controller (BMC) access to the boot firmware flash. Google the first who start using this integrated approach for increase their cloud security and prevent hardware backdoor’s but definitely not the last one. It will be very interesting to get the hardware with Titan chip inside for my dirty games :-)
How many Firmware’s in Update Image?
The instructions for UEFI firmware updates usually mention an update for the BIOS, which is the main firmware. But in the same way, that usual BIOS update delivers a lot of different “embedded” firmware to the various hardware units inside the motherboard or even in the CPU. Any BIOS vulnerability that bypasses authentication for a BIOS update image opens the door for the delivery of malicious components. However, it opens the door not only to BIOS implant installations, if any other issues make it possible to install one of the “embedded” firmware updates without authentication, or even to bypass it completely.
Basically, each firmware is an additional place where an attacker can store and execute code; an opportunity for a malicious implant. So how much firmware in our fancy modern hardware do we usually have? It is a very good question. As an example, if Intel Management Engine (ME) opens access to read and write to ME memory regions from the BIOS, a skilled attacker can try to play with this possibility. I found a similar issue in recent Gigabyte hardware. Combined with the weak configuration of Boot Guard, this issue helped me to bypass implementation of Intel Boot Guard on this hardware ( CVE-2017–11313, CVE-2017–11314). This issues already patched and confirmed by a vendor.
Also, we have Intel Active Management Technology (AMT) vulnerability (CVE-2017–5689) explained by Embedi at Black Hat talk. Interesting trend of this year researchers starts looking deeply into other parts of the UEFI firmware like AMT and Management Engine (ME). The multiple issues found by Positive Technologies researchers inside Intel ME. One of them already patched and allow an attacker disable ME. Another one will allow an attacker to execute unsigned code inside ME memory which very interesting from persistent implant point of view. I look forward to the details which is will be presented on in December at Black Hat Europe talk.
Let’s back to the main topic of this blog post to Intel Boot Guard and discuss a bit about implementation details.
How Intel Boot Guard Works and Fails?
The level of BIOS 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. Modern operating systems like Microsoft Windows 10 are relying more and more on firmware security, because the 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. 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 an on platform reset (different with reset-vector) it executes in protected AC-RAM (no-evict mode (NEM) or Cache-as-RAM) on the 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.
Let’s look briefly at some details about Intel Boot Guard implementation. There is no official Intel documentation publicly available about this technology yet. 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 third-parties 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 authenticate ACM code.
The Root of Trust for Secure Boot moves to the hardware directly from the UEFI firmware because any SMM attacks can compromise it. Even Measured Boot scheme relies on TPM as Root of Trust can be compromised from SMM. Only in 2013, Intel introduced Boot Guard with Field Programming Fuse (FPF) lock 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.
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 the 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 the 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 ACM, IBB, Key Manifest, Boot Policy, and associated PEI (BootGuardPei), DXE (BootGuardDxe) and SMM (VerifyFwBootGuard) 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? Only if configuration locked in hardware by programmed FPF.
Intel Boot Guard components:
- FPF — stores OEM hash (SHA-256)
- ACM — verifies the initial integrity before BIOS executes
- Key Manifest (KM) — provides third-parties hardware vendors approach to delegate IBBM public key (RSA 2048) authority
- Boot Policy Manifest (BPM) — provides Intel Boot Guard policy and Boot Guard features configuration
- Initial Boot Block Manifest (IBBM) — provides integrity of IBB hash values
Anyway, for bypass Boot Guard tons of reverse engineering work has been done. From different PEI/DXE/SMM drivers has been reconstructed all key structures. Here is an example of Key Manifest structure reconstructed from AMI-based BIOS:
One more example shows Initial Boot Block Manifest structure reconstructed from AMI-based BIOS:
During my research for Vegas, I also looked at the state of firmware security for most common hardware vendors. Here is a spreadsheet of the results for specific hardware.
Intel provided me an official statement for this issues found in AMI-based Boot Guard implementation for Black Hat talk.
Intel provides a 6th and 7th generation Core Platforms Secure Configuration Specification, which covers how to securely configure the platform. Additionally, Intel makes available a utility that our ecosystem partners can use to test and identify potential configuration issues.
Also I have a statement from Gigabyte about this issues:
For FPF issue, we discuss with internal the BIOS don’t need any update but we will add ME Lock tool to our production process soon, the new production ship will include ME Lock.
Attack from my research demonstrates mostly the problem with the wrong configuration when the Root of Trust doesn’t lock. The attacker, in this case, can change all the keys and recalculate all the structures contains Boot Guard policies. Here is only five steps to reach this goal:
- Modify UEFI firmware update image or Disable Intel Boot Guard
- Initial Boot Block (IBB)
- Recalculate signature on 2048-bit RSA key pair for IBB
- Modify IBB manifest inside UEFI firmware update file
- Recalculate signature for IBB manifest with different 2048-bit RSA key pair
3. Modify Root Key manifest
- Recalculate SHA256 hash of the public key from Root Key Manifest
4. Modify ME region with new key (CVE-2017–11314)
- Modify Boot Guard configuration with active verified boot policy
5. Lock Boot Guard configuration with by FPF (CVE-2017–11313)
However, it shows only the way to bypass Intel Boot Guard with configuration issues when we can modify any policies and reconfigure everything. Let’s talk about other ways to bypass this technology.
Recent Boot Guard Bypass (CVE-2017–5722) by Embedi
On the last week, Embedi publishes a blog post about the new way of bypass Intel Boot Guard technology discovered by Alexander Ermolov. And Intel only a few days after released a patch for CVE-2017–5722 on NUC platforms. Intel NUC based on AMI firmware framework. That’s mean it is the same implementation of Boot Guard as I reverse engineered for Black Hat talk.
However, at the end of my talk, I drop information about the logical issue in the Root of Trust validation process during the transition from sleep mode (S3 state). This issue shows the weak security checks for Boot Guard policies after resuming from S3 mode. Honestly speaking it’s no validation because of BootGuardDxe check only one flag value TRUE or FALSE (one byte of data in HOB).
Actually after my talk some of the hardware vendors confirmed it was an issue but they already patched. Looks like even after the talk not all of them pay attention and patch the issue :-)
Here is reconstructed C code for Boot Guard validation flow from BootGuardDxe:
EFI_STATUSBootGuardPei(EFI_PEI_SERVICES **PeiServices, VOID *Ppi)
{
...Status = GetBootMode ();
if ( EFI_ERROR( Status ) ) {
return Status;
}...if ( (BootMode == BOOT_IN_RECOVERY_MODE) || (BootMode == BOOT_ON_FLASH_UPDATE) || BootMode == BOOT_ON_S3_RESUME) {
return Status;
}BootGuardVerifyTransitionPEItoDXEFlag = 0;
...CalculateSha256(BootGuardHashKeySegment0);
CalculateSha256(CurrentBootGuardHashKey0);if ( !MemCmp(BootGuardHashKeySegment0, CurrentBootGuardHashKey0, 32) ) {
BootGuardVerifyTransitionPEItoDXEFlag = 1;
} else {
BootGuardVerifyTransitionPEItoDXEFlag = 0;
return EFI_SUCCESS;
}
if ( !((BootGuardHashKeySegment1 == 0) {
CalculateSha256 (BootGuardHashKeySegment1);
CalculateSha256 (CurrentBootGuardHashKey1);if ( !MemCmp(BootGuardHashKeySegment1, CurrentBootGuardHashKey1, 32) ) {
BootGuardVerifyTransitionPEItoDXEFlag = 1;
} else {
BootGuardVerifyTransitionPEItoDXEFlag = 0;
return EFI_SUCCESS;
}
}return Status;
}
We can see security check is an obvious and logical bug is clearly visible. Basically here is check only for the Boot Guard state from previous validation of chain of trust and return TRUE if the result has been correct before.
EFI_STATUS BootGuardDxe(EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE *SystemTable)
{
...if ( BootGuardSupported() == FALSE ) {
return EFI_SUCCESS;
}...BootMode = GetBootMode();
if ( (BootMode == BOOT_IN_RECOVERY_MODE) ||
(BootMode == BOOT_ON_FLASH_UPDATE) ) {
return EFI_SUCCESS;
}...if ( BootGuardVerifyTransitionPEItoDXEFlag == 0 ) {
BootGuardRegisterCallBack();
}return EFI_SUCCESS;
}
This issue exists because of all hardware vendors always fighting for less boot time and sometimes going to compromises with security. The full validation flow reconstructed from VerifyFwBootGuard SMM driver:
- Find and Verify ACM SVN
- Find and Verify Key Manifest (KM) SVN
- Find and Verify Boot Policy Manifest (BPM) SVN
- If something wrong return EFI_SECURITY_VIOLATION
You never attack the standard, you attack the implementation, including the process.
New UEFITool with visual validation of Boot Guard coverage
Today I released a new build of UEFITool with visual validation of Intel Boot Guard coverage. The code pushed to the github repository. A standalone binary of UEFITool can be downloaded here.
- YELLOW — some of the bytes covered by either Initial Boot Block (IBB) or vendor’s entry
- RED — every byte is covered by one of IBB entries
- CYAN — every byte is covered by one of vendor’s chain-of-trust code entry
- WHITE — not covered by any protection technology known to UEFITool
Visualization of IBB coverage for PEI volume in Gigabyte image by UEFITool NE A44 :
We can see in the previous figure some yellow parts exist in the PEI volume that’s mean some of the regions not fully covered by IBB. As an example, one of them is Intel ACM for Boot Guard and the only header is covered. In this case, it’s enough because anyway microcode will be verified ACM before execute but in some cases, it can be an issue.
In the next blog post, I will try to collect some of the examples from common hardware vendors with mistakes in Boot Guard IBB coverage.
