New exploits can bypass Secure Boot and modern UEFI security protections
Two teams of researchers have revealed vulnerabilities this week in Unified Extensible Firmware Interface (UEFI) implementations and bootloaders that could allow attackers to defeat the secure boot defenses of modern PCs and deploy highly persistent rootkits.
Researchers from firmware and hardware security firm Eclypsium published a report on vulnerabilities they found in three third-party bootloaders that are digitally signed by Microsoft’s root of trust. They can be deployed on PCs as a replacement for the OS bootloader to support pre-boot capabilities for specialized enterprise software such as PC hardware diagnostics, disk rollback, or full disk encryption.
Earlier this week in a presentation at the Black Hat USA security conference researchers from firmware security company Binarly revealed 12 vulnerabilities that could lead to pre-boot remote code execution in UEFI implementations from Intel, HP and independent firmware vendor AMI. The flaws defeat the latest firmware defense technologies such as Intel BIOS Guard and were demonstrated on a recently released Intel CPU.
How the vulnerabilities bypass Secure Boot
Secure Boot is an UEFI technology present on most modern PCs that’s meant to cryptographically verify the integrity of code loaded by the CPU in the early stages of a PC booting up until the operating system is initialized. Most UEFI implementations come preloaded with a certificate called the Microsoft 3rd Party UEFI Certificate Authority (CA) that establishes the root of trust for the entire platform.
All subsequent components started by the firmware, including the piece of code known as the bootloader that initializes the OS kernel, need to be signed by this root certificate or by an intermediary certificate signed by it. Microsoft offers a service through which third-party OS developers, such as Linux distributions, but also specialized pre-boot software, can sign their bootloaders for them to be functional and deployable on systems with Secure Boot enabled in UEFI.
In July 2020, researchers from Eclysium found a serious vulnerability in the GRUB2 bootloader that’s used by most Linux distributions. The flaw, tracked as CVE-2020-10713 and dubbed BootHole, could have allowed attackers to execute malicious code inside the bootloader, giving them full control over the OS before other security features kicked in. Since GRUB2 is also capable of initializing Windows, attackers could also replace the Windows bootloader with a vulnerable GRUB2 version on a compromised system and still have it pass Secure Boot validation. This meant that to fully mitigate the attack, all vulnerable signed GRUB2 binaries had to be blacklisted. As it turns out, this is not that easy.
At the DEF CON 30 conference on Friday, the Eclypsium team presented three similar vulnerabilities. One flaw, tracked as CVE-2022-34301, is in a signed bootloader developed by Eurosoft (UK) Ltd, a company that sells a hardware diagnostics solution called Pc-Check UEFI that’s capable of running tests before the OS starts. A second flaw, CVE-2022-34302, affects a bootloader developed by a company called New Horizon Datasys, Inc., that develops data restore, disk snapshot and rollback solutions. The third one, CVE-2022-34303, is in a bootloader developed by a company called CryptWare IT Security GmbH and is associated with a software solution called CryptoPro Secure Disk for BitLocker that provides pre-boot authentication options for Microsoft’s BitLocker disk encryption such as smartcards with PINs and usernames with passwords.
The Eurosoft and CryptoPro bootloaders provide UEFI shells with graphical user interfaces. By exploiting the identified vulnerabilities, which can be automated with startup scripts, attackers can use the built-in capabilities of the shells, such as mapping memory, reading and writing to memory and listing handles, to evade Secure Boot and execute malicious code. While the malicious interaction with the shells might be visible on PCs, it will not be visually detectable on servers or industrial computers that don’t typically have monitors attached.
The vulnerability in the New Horizon Datasys bootloader is even stealthier as it presents no visual indicator to the system owner and the bootloader contains a built-in bypass for Secure Boot that leaves it enabled but disables its checks.
“In this case, an attacker would not need scripting commands and could directly run arbitrary unsigned code,” the researchers said. “The simplicity of exploitation makes it highly likely that adversaries will attempt to exploit this particular vulnerability in the wild.”
Like with the GRUB2 BootHole vulnerability, the mitigation involves adding the vulnerable bootloaders to a blacklist built into UEFI known as the Secure Boot Forbidden Signature Database (DBX). This database can be updated through UEFI updates released by the PC vendor, but also from inside the operating system via special commands or through Windows Update. Microsoft has released a security update that blacklists these vulnerable bootloaders earlier this week, but notes that some OEM firmware might block the installation of the update and that the update might also fail on systems with the BitLocker Group Policy Configure TPM platform validation profile for native UEFI firmware configurations enabled and PCR7 selected by the policy.
How Pre-EFI (PEI) attacks work
In addition to attacking a system’s bootloader, attackers can go even deeper and deploy malicious implants inside UEFI components that are executed even earlier. This can be achieved by exploiting vulnerabilities or misconfigurations in various UEFI implementations, and there have been many such flaws over the years. One example of UEFI malware is a Chinese rootkit called CosmicStrand that has been in use since 2016 and attacks systems with Gigabyte or ASUS motherboards with outdated firmware.
UEFI attacks are by nature more targeted because the vulnerabilities are PC OEM or UEFI vendor specific, so they will only work on a specific subset of PCs or servers. However, there’s no shortage of such flaws. Over the past nine months the research team from Binarly found 42 high-impact vulnerabilities related to the SMM (System Management Mode) and DXE (driver execution environment) of firmware from multiple manufacturers. That said, more UEFI security mitigations have been added over the years, such as Intel BIOS Guard, which is part of the company’s Intel Hardware Shield technology and includes the Intel Platform Properties Assessment Module (PPAM) and the Intel SMI Transfer Monitor (STM).
According to Binarly’s Black Hat talk, while these technologies have made some exploits harder, they have also increased the attack surface by adding code that might contain vulnerabilities. To demonstrate these, the team demonstrated several vulnerabilities they found recently that can enable what they refer to as Pre-EFI (PEI) attacks. These are attacks that execute even earlier in the boot stage before the mitigations are even applied.
“During the most part of PEI phase no security protections against SPI [the flash chip where UEFI is stored] modifications are enabled,” the researchers said in their presentation. Technologies like BLE, SMM_BWP, PRx or Intel BIOS Guard are not enabled at this moment, they said.
The researchers disclosed three PEI memory corruption vulnerabilities that affects firmware made by Intel and AMI and could lead to arbitrary code execution (CVE-2022-28858, CVE-2022-36372, CVE-2022-32579), one vulnerability that can lead to DXE arbitrary code execution (CVE-2022-34345), and three SMM memory corruption flaws (CVE-2022-27493 and CVE-2022-33209). They also found and disclosed six SMM memory corruption issues in HP firmware that can lead to arbitrary code execution (CVE-2022-23930, CVE-2022-31644, CVE-2022-31645, CVE-2022-31646, CVE-2022-31640 and CVE-2022-31641).
“Remember that complexity is an enemy of security,” Binarly CEO Alex Matrosov said during the talk, reminding vendors that UEFI security features should be properly configured and consistent across the entire ecosystem and that information stored in UEFI static storage contains a lot of important data and should be considered as a potential attack vector that can enable attackers to perform easy bypasses.
Full article attribution is made to its original source and author.