Understanding and Exploiting UEFI Secure Boot with Intel’s EDK2

The Unified Extensible Firmware Interface (UEFI) Secure Boot is a security standard developed by members of the UEFI forum. It helps to ensure that a system boots using only software that is trusted by the Original Equipment Manufacturer (OEM). However, like any other technology, it is not immune to attacks. In this article, we will delve into the intricacies of UEFI Secure Boot, explore how it can be exploited using Intel’s Extensible Firmware Interface Development Kit II (EDK2), and discuss how to mitigate such attacks.

UEFI Secure Boot

UEFI Secure Boot is a protocol of the UEFI specification. It is designed to protect the boot process from bootkit attacks by verifying the digital signatures of EFI (Executable File Format) binaries against a set of trusted certificates stored in the firmware. If the signatures are valid, the system boots; if not, the boot process halts. The verification process is performed by the DxeImageVerificationHandler routine, which is part of the DxeImageVerificationLib library in the EDK2.

Intel’s EDK2

Intel’s EDK2 is a development framework for building UEFI firmware. It is open-source and widely used by various OEMs and security researchers. The EDK2 provides a robust implementation of UEFI, including Secure Boot, and serves as a valuable resource for understanding the inner workings of UEFI firmware.

Hierarchical Authentication in the UEFI Secure Boot Proces

The UEFI Secure Boot process relies on a hierarchical system of keys to authenticate each step of the boot process, from the initial platform initialization to the loading of operating system components. This hierarchy ensures that each component is authenticated by a trusted source before it is executed, providing a robust defense against unauthorized modifications, but at the same time, it presents a significant vulnerability if the upper key in the hierarchy is tampered with.

UEFI hierarchical authentication keys

The diagram above illustrates the hierarchical authentication process in the UEFI Secure Boot system. At the top of the hierarchy, we have the Platform Initialization (PI) Firmware and the Platform Key (PK), which form the root of trust for the system. The PK, stored in the Hardware Security Module (HSM), is used to authenticate the Key Exchange Key (KEK). The KEK, in turn, authenticates the signature databases (db and dbx). These databases contain the keys and certificates used to verify the bootloaders and drivers. The Non-Volatile RAM (NVRAM) is where the KEK, db, and dbx are stored, while the SPI Flash is where the UEFI firmware, including the PI Firmware, resides. In this way, each step of the boot process is authenticated by the corresponding key in the hierarchy.

In addition to these keys, the Trusted Platform Module (TPM) and the Intel Management Engine (ME) both play significant roles in the UEFI Secure Boot process.

The TPM is a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices. It provides a hardware-based root of trust. The TPM contains several Platform Configuration Registers (PCRs) that can hold measurements (typically cryptographic hashes) during the boot process. These measurements can be used to verify the integrity of the boot process.

the Trusted Platform Module (TPM).ntegrated into either the motherboard or the CPU itself

On the other hand, the Intel ME is a separate microcontroller embedded in the motherboard that starts running as soon as the system is powered on. Unlike the TPM, which measures components during the boot process, the Intel ME is primarily involved in the authentication of the BIOS/UEFI firmware as part of Intel’s Boot Guard technology. The ME checks that the firmware has been signed by a trusted source (such as the system manufacturer) before allowing it to execute. This authentication process helps to protect the system against unauthorized modifications to the firmware. After the system has booted, the ME continues to run and provides various system management functions.

ME displays its Ring (-3) power

However, the Intel ME, though protected with RSA 2048 encryption, also represents a potential vulnerability point as part of the “-3 security ring”. The ME operates at a level of privilege that is even higher than the system’s kernel (ring 0), hypervisor (ring -1), and System Management Mode (ring -2). This means that if an attacker were able to compromise the ME, they could potentially gain complete control over the system, without being detected by the operating system or any security software running on the system.

Together, the TPM and the Intel ME provide a robust defense against unauthorized modifications to the boot process, each contributing in different ways and at different stages of the process. The TPM focuses on measuring and verifying the integrity of the boot process, while the Intel ME is primarily responsible for authenticating the BIOS/UEFI firmware and providing system management functions, but also represents a potential security risk.

The Intel Management Engine (ME): A double-edged sword that can simplify the life of a system administrator, but also potentially create a nightmare

The Boot Process

The boot process involves several components, including the Initial Boot Block (IBB), Authenticated Code Module (ACM), and Firmware Interface Table (FIT). The ACM (signed by Intel’s private key) is loaded and executed in a secure and isolated environment, and it implements Verified ( using the corresponding public key — from the same RSA pair as the private key used for signing ) and Measured Boot functionality (computing a cryptographic hash). It loads the IBB into memory and verifies and/or measures it. The IBB is part of the firmware that contains code executed at the reset vector. After the ACM verifies and/or measures the IBB, these measurements are extended into the TPM’s Platform Configuration Registers (PCRs). These PCRs can then be used to verify the integrity of the boot process. This process of measurement and verification ensures that any unauthorized modifications to the boot process can be detected and prevented from executing. The exact location of the ACM is provided in the FIT, a special data structure stored in the firmware imag

Exploiting UEFI Secure Boot

Despite the security measures provided by UEFI Secure Boot, vulnerabilities can still be exploited. One such vulnerability arises from the ability to modify UEFI NVRAM variables. These variables store Secure Boot configuration parameters, such as whether Secure Boot is enabled, the Platform Key (PK), Key Exchange Key (KEK), and signature databases (db and dbx). An attacker with write access to the SPI flash memory, where these variables are typically stored, could modify their content.

Here is a simplified example of how an attacker might modify the PK variable using C code:

#include <Uefi.h>
#include <Library/UefiRuntimeServicesTableLib.h>


EFI_STATUS EFIAPI UefiMain (
  IN EFI_HANDLE        ImageHandle,
  IN EFI_SYSTEM_TABLE  *SystemTable
  )
{
  EFI_STATUS Status;
  EFI_GUID EfiGlobalVariable = EFI_GLOBAL_VARIABLE;
  UINT8 NewPK[] = { /* New PK data */ };


  Status = gRT->SetVariable(
    L"PK",
    &EfiGlobalVariable,
    EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS,
    sizeof(NewPK),
    NewPK
  );


  return Status;
}

In this code, the SetVariable function is used to overwrite the PK variable with a new value. This could allow the attacker to add their own keys to the KEK, db, and dbx databases, effectively bypassing Secure Boot.

he security breaches occurred due to leaked keys at various stages of the boot process, as indicated by the red lines

Mitigating Attacks

• Firmware Update: The most direct mitigation measure is to update the firmware of the affected devices. This would involve replacing the compromised keys and re-signing the firmware with new, secure keys. However, this is a complex process that requires coordination across the entire supply chain, from silicon vendors to device manufacturers.
• Key Revocation: Another mitigation measure is to revoke the compromised keys. This would prevent any new firmware signed with these keys from being trusted. However, revoking keys can be a lengthy process and may not be possible in all cases due to the design of the system.
• Secure Key Management: The leaks highlight the importance of secure key management. Measures should be taken to ensure that keys are securely stored and handled, and access to keys should be strictly controlled.
• Supply Chain Security: Integral need for improved security across the entire supply chain. This includes better security practices at silicon and device vendors, as well as improved security in the manufacturing process.
• Use of Security Tools: The Binarly team, in the article below cited, provides tools like FwHunt to detect vulnerable devices at scale and help the industry recover from firmware security failures. These tools can be used to identify devices that are using compromised keys and may need to be updated or replaced.
• Industry-wide Solutions: The Binary Team suggests as well as that fixing vulnerabilities for a single vendor is not enough due to the complexity of the firmware supply chain. There are gaps that are difficult to close on the manufacturing end since it involves issues beyond the control of the device vendors. Therefore, industry-wide solutions are needed to address these challenges.

Remember, these are potential mitigation measures and the effectiveness of each will depend on the specific circumstances of each case.

To mitigate such attacks, it is crucial at the core to protect the SPI flash memory from unauthorized write access. This can be achieved by implementing hardware-based write protection or using the BIOS Control Register to disable BIOS write access as well.

Furthermore, it is essential to follow best practices when implementing UEFI Secure Boot. This includes properly validating inputs, using secure coding practices to prevent buffer overflows and other common vulnerabilities, and regularly updating firmware to patch known vulnerabilities.

Conclusion

While UEFI Secure Boot provides a significant improvement in system security, it is not foolproof. Understanding the potential vulnerabilities and how they can be exploited is crucial for developing effective mitigation strategies. By leveraging resources like Intel’s EDK2, we can gain a deeper understanding of these vulnerabilities and work towards more secure systems.

References:

1. Intel’s EDK2 GitHub Repository
2. Setup for Failure: Defeating Secure Boot
3. Summary of Attacks Against BIOS and Secure Boot
4. Matrosov, Alexander. Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats. No Starch Press.
5. Binary Research Team: Leaked MSI source code with Intel OEM keys