.webp)
At the last Black Hat event in Vegas, I presented the first publicly known concept of an attack on a specific implementation of Intel Boot Guard technology - technology that is mostly undocumented. While I was working on this research one thought bothered me: the specification of a technology can be almost perfect, but after all, the implementation part is done by 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 there are places where making a small mistake allows an attacker to bypass the security of the entire technology.
I proved how many mistakes can be done in practice and demonstrated that on Gigabyte hardware with modern CPU and 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 lead to serious problems.
From the attacker’s perspective, the most logical way to do malicious activities nowadays is to simply move down to the next level into the software stack, to the system firmware (BIOS).
Figure 1: Moving down the software stack
The persistence at the BIOS level is very different from 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 the 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 in rootkits complexity due to mitigations implemented at OS level is motivating attackers to go into the firmware space.
Also, I want to direct the 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 noticed the significant increase of the security issues in UEFI firmware security space. This research showed the last three years of relevant data according to Intel PSIRT. In Figure 2 it is presented the vulnerability distribution over the years (the chart copied from original publicly available Intel’s slide deck).
Figure 2: Intel Security issues over 3 year period
We can clearly see the increase in the class issues “Platform capability not properly configured” were third-parties vendors are responsible for mostly all those bugs. This class of bugs was exactly about the implementation mistakes when developers forgot to setup something or didn’t follow the specification. Accordingly, Intel has the following description for this class of security issues: “Locks not set, devices not properly initialized, features not disabled, etc”. This kind of issues can also be a result of supply chain attacks when hardware are insecurely reconfigured, infected by malicious pieces of firmware or implants. Google announced the Titan chip which intends to protect the hardware root of trust. It is becoming a critical task 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 a company develops its own hardware to control the platform root of trust, can become popular for other big cloud and data companies like Amazon, Microsoft, Apple, etc. Specifically with Titan, even if the platform has been compromised by a firmware rootkit, isolated root of trust will prevent Secure Boot and firmware update attacks because of controlled Platform Controller Hub (PCH) and Baseboard Management Controller (BMC) access to the boot firmware flash. Google is the first company that started using this integrated approach to increase their cloud security and prevent hardware backdoors but definitely it won’t be the last. It would be great to acquire a piece of hardware with a Titan chip inside for my dirty games :-)
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 several different “embedded” pieces of 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. This allows not only to BIOS implant installations but also it makes it possible to install one of the “embedded” firmware updates without authentication, or even to bypass it completely.
Figure 3: How many different pieces of firmware fit into one firmware update
Basically, each firmware is an additional place where an attacker can store and execute code; an opportunity for a malicious implant. So how many pieces of firmware do our fancy modern hardware usually have? It is a very good question. As an example, if Intel Management Engine (ME) opens access to read and write to the ME memory regions from the BIOS, a skilled attacker can try to leverage this opportunity. I found a similar issue in a recent Gigabyte hardware which combined with a weak configuration of Boot Guard, helped me bypass the implementation of Intel Boot Guard on this hardware (CVE-2017–11313, CVE-2017–11314). This issue has already been confirmed and patched by the vendor.
Another example is the Intel Active Management Technology (AMT) vulnerability (CVE-2017–5689) explained by Embedi at a Black Hat talk. A recent trend shows researchers looking deeper into other parts of the UEFI firmware ecosystem like AMT and Management Engine (ME). There had been multiple Intel ME issues reported by Positive Technologies researchers. One of them, already patched, allows an attacker to disable ME. Another one allows an attacker to execute unsigned code inside the ME memory which is very interesting from the persistent implant point of view (presented at Black Hat Europe talk).
Let’s get back to Intel Boot Guard, the main topic of this blog post, and discuss a bit about implementation details.
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 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 way the system is protected from persistent implants. Both technologies are run on platform reset (different from reset-vector) and executed in a 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. These “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 the 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 the 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.
Figure 4: Intel Boot Guard
Intel Boot Guard is a very complex piece of technology with a lot of flexibility for third-party 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 authenticates the Boot Guard ACM code (Figure 4).
The Root of Trust for Secure Boot moves to the hardware directly from the UEFI firmware because any SMM attacks can compromise it. Even the Measured Boot scheme relies on TPM as the Root of Trust can be compromised from SMM. Only in 2013, Intel introduced Boot Guard with Field Programming Fuse (FPF) that stores the value of the hash of the OEM public key. The FPF can be programmed only one time, and the hardware vendor should lock this configuration during the manufacturing process. The Figure 6 shows the full chain of the root of trust for Intel Boot Guard technology.
Figure 5: RoT for Intel Boot Guard
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 the 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? This can only be achieved if configuration is locked in hardware by a programmed FPF.
Intel Boot Guard components are:
- 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 valuesAnyway, to bypass Boot Guard a lot of reverse engineering work has been done by researchers. From reversing different PEI/DXE/SMM drivers all the key structures have been reconstructed. Here is an example of Key Manifest structure reconstructed from AMI-based BIOS:
Figure 6: Key Manifest structure
One more example shows Initial Boot Block Manifest structure reconstructed from AMI-based BIOS:
Figure 7: I BB Manifest
During one of my research, I also looked at the state of firmware security for most common hardware vendors. Here is a spreadsheet of the results for specific hardware.
Figure 8: State of System Firmware security by vendor
As a response to my research and BlackHat talk, Intel provided an official statement for the issues found in AMI-based Boot Guard implementation:
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 received a statement from Gigabyte about the same 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.
This research demonstrates the problem with being able to modify the configuration when the Root of Trust isn’t locked. The attacker, in this case, can change all the keys and recalculate all the structures containing Boot Guard policies. There are only five steps needed 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
- Modify Root Key manifest
◦ Recalculate SHA256 hash of the public key from Root Key Manifest
- Modify ME region with new key (CVE-2017–11314)
◦ Modify Boot Guard configuration with active verified boot policy
- Lock Boot Guard configuration by programming the FPF fuse (CVE-2017–11313)However, this shows only a way to bypass Intel Boot Guard with configuration issues when the attacker can modify any policy and reconfigure everything. Let’s talk about other ways to bypass this technology.
Embedi published a blog post describing a new way of bypassing the Intel Boot Guard technology discovered by Alexander Ermolov. Intel released a patch for CVE-2017–5722 on NUC platforms only a few days after. Intel NUC is based on the AMI firmware framework. This means that we are dealing with the same implementation of Boot Guard I reversed engineered for my Black Hat talk.
However, at the end of my talk, I dropped some information about a 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, there isn’t any validation because the BootGuardDxe checks only the value of one Boolean flag - BootGuardVerifyTransitionPEItoDXEFlag (one byte of data in HOB).
Figure 9: Boot Guard validation checks
Actually after my talk some of the hardware vendors confirmed it was an issue that was already patched. Looks like even after the talk not all of them paid attention and patched the issue :-)
Here is reconstructed C code for Boot Guard validation flow from BootGuardDxe:
EFI_STATUS BootGuardPei(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;
}The security check is obvious and the logical bug is clearly visible. Basically, here it checks only for the Boot Guard state from the previous validation of the chain of trust and returns 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 all the hardware vendors are always fighting for shorter boot time and sometimes are making compromises on the security. The full validation flow reconstructed from VerifyFwBootGuard SMM driver:
1. Find and Verify ACM SVN
2. Find and Verify Key Manifest (KM) SVN
3. Find and Verify Boot Policy Manifest (BPM) SVN
4. If something wrong return EFI_SECURITY_VIOLATIONYou never attack the standard, you attack the implementation, including the process.
A new build of UEFITool is available that can be leveraged to visual validate the Intel Boot Guard coverage. The code was pushed to the github repository. Also, a standalone binary of the UEFITool can be downloaded here.
1. YELLOW — some of the bytes covered by either Initial Boot Block (IBB) or vendor’s entry
2. RED — every byte is covered by one of IBB entries
3. CYAN — every byte is covered by one of vendor’s chain-of-trust code entry
4. WHITE — not covered by any protection technology known to UEFITool
Figure 11: IBB validation check
Visualization of IBB coverage for a PEI volume in Gigabyte image by UEFITool NE A44 :
Figure 10: IBB coverage for a PEI volume in Gigabyte image
We can see in the previous figure some yellow parts exist in the PEI volume which means some of the regions are not fully covered by IBB. As an example, one of them is the Intel ACM for Boot Guard for which only the header is covered. In this case, it’s enough because microcode is verified by ACM before execution but, in other cases, it can be an issue.
.svg)
