UEFI Bootkits and Where UEFI Security Fails

UEFI Bootkits and Where UEFI Security Fails

Speakers: Martin Smolar, Malware Researcher, ESET

Conference: RSAC 2024

YouTube: https://www.youtube.com/watch?v=X3YOKkTdj_k

Overview

This talk, presented by Martin Smolar, a Malware Researcher at ESET, delves into the escalating threat of UEFI bootkits and the systemic failures in UEFI security that enable them. Smolar highlights that despite the widespread adoption of UEFI Secure Boot, which was intended to secure the system boot process, recent discoveries like BlackLotus have unequivocally demonstrated that bootkits remain a potent and evolving danger. The presentation serves as a critical call to action, emphasizing that relying solely on default Secure Boot settings is insufficient and that a multi-layered approach involving firmware developers, hardware manufacturers, and security professionals is essential to bolster UEFI cybersecurity.

Smolar articulates the profound impact of a successful UEFI bootkit deployment, granting attackers complete, stealthy, and persistent control over a compromised system. This level of compromise allows for the disabling of critical operating system security features such as virtualization-based security (VBS), PatchGuard, and driver signature enforcement, as well as the subversion of any installed security software. With UEFI firmware running on billions of devices globally—including workstations, laptops, servers, and critical infrastructure components—the implications of these security vulnerabilities are vast, affecting not only individual users but also the backbone of modern digital society.

The core of Smolar's presentation focuses on dissecting how UEFI Secure Boot, despite its foundational design, can be bypassed and why its revocation mechanisms have repeatedly fallen short. Drawing on ESET's extensive first-hand experience in analyzing real-world UEFI malware, including the discovery of almost half of all publicly known UEFI threats, the talk uncovers critical red flags in the UEFI security ecosystem. It provides a comprehensive analysis of past and present vulnerabilities, illustrating how delayed, incomplete, or flawed revocations have left countless systems exposed, and ultimately offers actionable strategies for both preventing and mitigating UEFI bootkit infections.

Background

▶ Watch: Introduction: Why care about UEFI bootkits? BlackLotus bypass. (0:00)

The landscape of system boot security has evolved significantly with the advent of UEFI (Unified Extensible Firmware Interface), replacing the legacy BIOS. Introduced with Windows 8, UEFI Secure Boot was designed to prevent malicious software, specifically bootkits, from loading during the system startup process. The premise was simple: only digitally signed and trusted bootloaders and drivers would be allowed to execute, ensuring the integrity of the boot chain. For a time, many in the security community believed this largely mitigated the threat of bootkits.

However, recent events have shattered this perception. The discovery of BlackLotus in 2022 marked a pivotal moment, as it was the first UEFI bootkit proven capable of bypassing UEFI Secure Boot on fully updated Windows systems. This revelation garnered significant attention, prompting the NSA to issue a mitigation guide and America's Cyber Defense Agency (CISA) to publish a "Call to Action: Bolster UEFI Cybersecurity Now." These advisories underscored the urgent need to address the often-overlooked vulnerabilities within UEFI firmware.

UEFI bootkits distinguish themselves from other malicious software by their deep-seated persistence and control. Once deployed, a UEFI bootkit executes before the operating system (OS) kernel, giving it unparalleled power. As quoted in the talk, an attacker can "be creative with what you could do to the kernel that is just sitting there in memory, not protected by anything." This includes disabling fundamental OS security features like virtualization-based security (VBS), PatchGuard, and driver signature enforcement. Furthermore, bootkits can modify OS behavior to conceal their presence and disable any endpoint security software, rendering traditional defenses ineffective.

It's crucial to differentiate UEFI bootkits from UEFI firmware implants. Firmware implants, such as LoJax, MoonBounce, and CosmicStrand, reside directly on a small memory chip on the motherboard, alongside the UEFI firmware itself. Their deployment and modification often require specialized software or hardware, making them difficult to install and remove. In contrast, UEFI bootkits, like BlackLotus and ESpecter, are located on the computer's disk drive, specifically on the EFI System Partition (ESP). This makes their deployment significantly simpler, often as straightforward as copying any other file to the file system. While publicly known UEFI bootkits have predominantly targeted Windows systems, the underlying architecture means Linux systems are equally susceptible, though no such bootkits have been discovered in the wild yet.

ESET has played a prominent role in uncovering UEFI threats, having discovered almost half of all publicly known UEFI malware. Their extensive research and first-hand experience provide a unique perspective on the evolving tactics of attackers and the inherent weaknesses in the UEFI security model. This talk leverages ESET's expertise to shed light on how these threats operate and, more importantly, how to defend against them.

Key Findings

▶ Watch: UEFI runs on billions of devices, including critical infrastructure. (3:08)

The talk presents several critical findings that collectively paint a concerning picture of the current state of UEFI security:

1. UEFI Secure Boot is Insufficient: Despite its design to prevent bootkits, UEFI Secure Boot, in its default configuration, has proven to be an inadequate defense. The emergence of BlackLotus, which successfully bypassed Secure Boot on fully updated Windows systems, is the definitive proof that the security model has significant exploitable weaknesses.
2. Systemic Failures in Revocation Mechanisms: A recurring theme is the profound inadequacy and delay in revoking vulnerable binaries.

• Delayed Revocation: Even for simple cases involving a single binary, revocation can take excessively long (e.g., 10-15 months for a Microsoft-signed Grub vulnerability). This extended window leaves systems vulnerable.
• Incomplete Revocation: In some instances, only a subset of vulnerable binaries is revoked, or the revocation process is flawed (e.g., HP removing files from their website instead of proper DBX revocation for some Grub versions; Microsoft mistakenly revoking flat file hashes instead of PE authenticode hashes for Eclypsium-discovered vulnerabilities). This means binaries remain exploitable for years.
• Pulled Revocations: Microsoft even had to pull a DBX update because it rendered unrelated HP devices unbootable, further delaying protection.

1. BlackLotus: A Game Changer: BlackLotus's significance lies in its exploitation of a vulnerability that was already fixed by Microsoft in January 2022 but not immediately revoked. This allowed attackers to bring their own vulnerable, but still trusted, binaries to a system to bypass Secure Boot, demonstrating a critical flaw in the revocation process. Microsoft's subsequent guidance and optional revocation phases further highlight the complexity and delay in addressing such widespread issues.
2. OEMs and Microsoft's Critical Role and Responsibility: OEMs (like HP, Lenovo, Acer) and Microsoft collectively control what is trusted and allowed to execute on the vast majority of computer systems. Their certificates (e.g., Microsoft Windows Production PCA 2011, Microsoft Corporation UEFI CA 2011) dictate the Secure Boot ecosystem's safety. However, their review processes for signing third-party or even internal utilities often appear lax, leading to signed binaries with critical vulnerabilities (e.g., custom PE loaders without integrity checks, UEFI shells with memory manipulation commands).
3. "Vulnerable Forever" Devices: A significant portion of devices will remain perpetually vulnerable to certain UEFI firmware vulnerabilities due to the end of development support from vendors. This means that even if a vulnerability is discovered and fixed for newer models, older, unsupported hardware will never receive the necessary patches, creating a persistent attack surface.
4. Lack of Transparency: There is a notable lack of transparency regarding the total number of UEFI applications signed by OEMs and Microsoft, as well as the detailed review processes employed before signing these binaries. This opacity hinders independent security research and proactive defense efforts.

These findings underscore that UEFI security is not merely a technical challenge but a complex issue involving vendor responsibility, timely updates, and robust revocation practices that are currently falling short.

Technical Deep Dive

▶ Watch: ESET's significant role and first-hand experience in UEFI research. (5:30)

Understanding UEFI bootkits and Secure Boot bypasses requires a deep dive into the UEFI boot process and its cryptographic underpinnings.

When a computer with UEFI firmware is powered on, the firmware first initializes hardware and then proceeds to boot the operating system, typically from a disk drive (HDD or SSD). Every UEFI system contains an EFI System Partition (ESP), which is a dedicated partition where all bootloaders and related components are stored. The UEFI firmware determines which bootloader to execute by consulting UEFI boot variables, specifically the BootOrder variable, which specifies the order of available boot options.

Attackers deploying UEFI bootkits primarily target this mechanism for persistence. Common strategies include:

1. Replacing High-Priority Bootloaders: Attackers can identify the highest-priority boot option in the BootOrder variable and replace the legitimate binary on the ESP with their bootkit.
2. Replacing Default OS Bootloaders: A simpler and common approach is to replace the operating system's default bootloader. For Windows systems, this is typically \EFI\Microsoft\Boot\bootmgfw.efi. For Linux systems, it could be \EFI\ubuntu\shimx64.efi or \EFI\fedora\grubx64.efi among others.
3. Utilizing the Fallback Bootloader: The UEFI default option, often called the fallback bootloader (\EFI\Boot\bootx64.efi for 64-bit systems), is executed if no other valid boot option can be found or executed. Attackers can target this path to ensure execution.

How UEFI Secure Boot Works and Where it Fails

UEFI Secure Boot relies on a hierarchy of cryptographic keys to establish a chain of trust:

• Platform Key (PK): Owned by the OEM, used to enroll Key Exchange Keys.
• Key Exchange Keys (KEK): A list of keys, typically including OEM and Microsoft keys, used to sign updates to the DB and DBX databases.
• DB (Authorized Database): Contains public key certificates or hashes of trusted bootloaders and UEFI applications that are allowed to execute.
• DBX (Forbidden Database): Contains public key certificates or hashes of untrusted or revoked bootloaders and UEFI applications that are explicitly not allowed to execute.

When the UEFI firmware attempts to load a UEFI driver or application, it performs a cryptographic verification. The binary must be signed by a certificate present in the DB database, AND its hash or signing certificate must not be present in the DBX database. If both conditions are met, the binary is executed; otherwise, a Secure Boot violation occurs.

On most real-world machines, OEMs pre-install their own PK, KEK, and DB entries. Microsoft then requires OEMs to include Microsoft certificates in the KEK and DB databases. This means that OEMs and Microsoft together control the trust chain for the majority of systems. Microsoft's key certificates include:

• Microsoft Windows Production PCA 2011: Used to sign all production boot applications developed directly by Microsoft.
• Microsoft Corporation UEFI CA 2011: Used to sign third-party boot applications (e.g., Linux bootloaders, full disk encryption software) that require default Secure Boot support.

The critical point of failure lies in the revocation process. If a vulnerability is discovered in a signed binary, its authenticode hash (or signing certificate) should be calculated and added to the DBX database. This DBX update is signed by a KEK owner (Microsoft for Microsoft-signed binaries, OEM for OEM-signed binaries) and then distributed. However, reality has shown numerous failures:

1. BlackLotus Bypass (CVE-2022-21894): BlackLotus exploited a vulnerability affecting hundreds of Windows boot applications. While the vulnerability was fixed in January 2022, Microsoft failed to revoke the vulnerable bootloaders. This allowed attackers to supply their own copies of these older, vulnerable, but still trusted, bootloaders to bypass Secure Boot. The subsequent revocation timeline was protracted, with optional phases stretching into 2024 and mandatory enforcement delayed. This demonstrated that a fix without immediate revocation is an open door for attackers.

1. Grub Vulnerabilities (ValdikSS, Dmytro Oleksiuk): Independent researchers discovered vulnerabilities in signed versions of Grub, an open-source boot manager. Specifically, the insmod command, which loads ELF executables as Grub modules, could be used to bypass Secure Boot even when enabled.

• One Microsoft-signed Grub binary took 10 months to revoke, and the update was then pulled, extending the vulnerability window to 15 months.
• HP-signed Grub binaries were also affected. While some were revoked in 4 months, ESET later found additional vulnerable HP-signed Grubs that had not been revoked. HP chose to remove these binaries from their website rather than issuing a proper DBX update, leaving older HP machines permanently vulnerable.

1. Eclypsium's "One Bootloader to Load Them All" Research: Eclypsium researchers discovered three Microsoft-signed (via Microsoft Corporation UEFI CA 2011) UEFI applications with severe vulnerabilities:

• A custom PE loader that would load and execute any UEFI binary from a hardcoded path without any integrity verification.
• UEFI shells containing an mm command, allowing read-write access to physical memory, which could disable Secure Boot.

When Microsoft issued a DBX update in August 2022 to revoke these, they mistakenly revoked flat file hashes instead of the correct PE authenticode hashes. This meant the binaries remained exploitable until ESET reported the error, and Microsoft promptly issued a corrected DBX update.

1. ESET's "SecureBackDoor" Discoveries: ESET uncovered several UEFI drivers, mistakenly included in production firmware images, that were originally intended for manufacturing processes. These drivers allowed the modification of UEFI Secure Boot settings directly from the operating system. A notable example was a Lenovo driver humorously named "SecureBackDoor" by its developer, which inadvertently led ESET to discover seven other Secure Boot bypasses. While Lenovo issued advisories, many affected devices remained vulnerable for months, and a significant number of older, unsupported devices will remain vulnerable "forever" due to end-of-life development support.

These real-world examples unequivocally demonstrate that the Secure Boot ecosystem, despite its robust cryptographic design, is prone to human error, slow response times, and a lack of comprehensive enforcement, creating persistent vulnerabilities that threat actors are quick to exploit.

Demo / Proof of Concept

▶ Watch: Talk agenda: UEFI basics, Secure Boot bypass, protection. (6:45)

While the talk did not feature a live, interactive demonstration, it referenced several instances of how UEFI bootkit capabilities and Secure Boot bypasses are proven and exploited in practice. These examples illustrate the practical feasibility and the ease with which these vulnerabilities can be leveraged:

• Publicly Available Proof-of-Concept Bootkits: The speaker explicitly stated that "many proof of concept UEFI bootkits are available on the internet," complete with source code and deployment suggestions. Some of these are capable of disabling or bypassing Windows security features, indicating that the technical know-how is not limited to sophisticated APT groups but is accessible, allowing for "copy-paste" bootkit creation.
• BlackLotus Installer's Inspiration: The BlackLotus installer, which was uploaded to VirusTotal in late August 2022, was "heavily inspired" by a proof-of-concept exploit for the underlying vulnerability (CVE-2022-21894) that appeared on GitHub just 14 days prior in early August 2022. This rapid transition from PoC to active malware highlights how quickly attackers can weaponize disclosed vulnerabilities.
• Exploiting ESET-Discovered Vulnerabilities: For one of the UEFI drivers discovered by ESET, which allowed modifying Secure Boot settings from the OS, the speaker described a straightforward proof-of-concept exploitation: "you simply create a UEFI boot variable and then you reboot your system. That's it, UEFI Secure Boot is disabled." This demonstrates that some vulnerabilities can be triggered with minimal effort, requiring only a simple OS-level operation to compromise the boot integrity.
• Grub insmod Command: The vulnerabilities found in signed Grub bootloaders, exploited by the insmod command, effectively allow loading arbitrary ELF executables during the boot process, thereby bypassing Secure Boot. This illustrates a functional demonstration of code execution at a critical boot stage.
• UEFI Shell mm Command: Similarly, the mm command found in vulnerable UEFI shells allowed reading and writing to physical memory during boot. This capability, in the hands of an attacker, can be used to directly manipulate memory regions responsible for Secure Boot enforcement, effectively demonstrating a bypass.

These examples underscore that the vulnerabilities discussed are not theoretical but have clear, actionable exploitation paths, many of which have been publicly demonstrated or actively leveraged by malware like BlackLotus. The ease of access to such PoCs and the directness of their exploitation further emphasize the urgency of implementing robust defensive measures.

Defensive Implications

▶ Watch: UEFI bootkits are not new; POCs are widely available. (9:25)

Given the profound and persistent nature of UEFI bootkit threats, relying solely on standard security recommendations is no longer sufficient. While essential, measures like latest operating system updates, latest firmware updates, Secure Boot enabled, and installed security software must be augmented with more proactive and granular controls. The inherent problems in the UEFI security ecosystem—namely, the protracted and often flawed delivery of revocation updates, and the lack of transparency regarding signed UEFI applications—necessitate a shift towards a more self-reliant defensive posture.

Defenders must recognize that once a bootkit like BlackLotus is executed and compromises the operating system, it's often too late. BlackLotus, for instance, included built-in anti-removal and anti-scanning features, rendering its components invisible and immutable to OS-level tools. Therefore, defense strategies must focus on preventing bootkit installation or, at minimum, stopping their execution during the system boot.

Here are concrete defensive strategies:

1. EFI System Partition (ESP) Access Control:

• Implementation: The most straightforward and highly effective measure is to implement host-based access rules that restrict any modification attempts on the ESP. This involves blocking write access to specific files or entire directory trees within the ESP.
• Rationale: The ESP is not a partition that should be modified daily by untrusted software. Legitimate modifications are typically limited to OS updates or upgrades. By whitelisting specific, trusted processes (e.g., Windows Update, Linux distribution upgrade tools) and blocking all other write attempts, defenders can prevent bootkits from establishing persistence by replacing or adding malicious bootloaders. Most modern security solutions or endpoint detection and response (EDR) platforms offer the capability to create such granular file system access rules.

1. Customized UEFI Secure Boot:

• Overview: UEFI BIOS setup menus (and sometimes remote management solutions like BMCs) allow for customization of Secure Boot settings beyond the default OEM/Microsoft configuration. There are two main types:
• Full Customization: This involves clearing all existing Secure Boot keys (PK, KEK, DB, DBX) and replacing them entirely with an organization's own custom keys.
• Pros: Offers the highest level of security, granting complete control over the boot chain.
• Cons: Extremely challenging to manage at scale. Every single boot component, including OS kernels and bootloaders, would need to be signed with the organization's private certificates after every update or modification. This requires significant administrative overhead and expertise, making machines temporarily unbootable if not executed perfectly. This approach is generally recommended only for very sensitive systems with dedicated, experienced administrators.
• Partial Customization: This involves enrolling an organization's own Key Exchange Key (KEK) and potentially appending custom entries to the DB or DBX databases, without necessarily removing all OEM/Microsoft keys.
• Scenario 1: Faster Manual Revocations: By enrolling a custom KEK, organizations can quickly add PE authenticode hashes of newly discovered vulnerable or unwanted UEFI binaries to their local DBX database. This allows for immediate revocation, bypassing the often-lengthy and flawed official revocation processes from Microsoft or OEMs. This significantly reduces the window of exposure to newly identified threats.
• Scenario 2: Reduce Attack Surface (Linux Exclusive): For machines exclusively running Linux, organizations can reduce the attack surface by removing the Microsoft Windows Production UEFI certificate from the DB database. This prevents any Windows boot components from loading, effectively neutralizing vulnerabilities like the one exploited by BlackLotus, which relied on Windows boot components for its bypass.
• Scenario 3: Reduce Attack Surface (Windows Exclusive): For machines exclusively running Windows, organizations can consider removing the Microsoft Corporation UEFI CA 2011 certificate (the third-party certificate) from the DB database. This prevents the loading of third-party boot applications, including many Linux bootloaders and potentially vulnerable utilities signed by this certificate. This further narrows the attack surface for Windows-only environments.

Bootkit Removal Strategies

Should a system become compromised by a UEFI bootkit, removal can be challenging but is achievable through several approaches:

1. Operating System Reinstallation: The simplest and most comprehensive method. A clean reinstallation of the operating system will overwrite the ESP, removing the bootkit's components, and also eliminate any OS-level persistent installers or malicious components that might attempt to reinstall the bootkit.
2. EFI System Partition (ESP) Restoration from External Media: This approach involves booting the system from a trusted external medium (e.g., a USB drive with a clean OS installer or recovery environment) and then restoring a clean backup of the ESP. This effectively removes the bootkit from the ESP but does not address any potential OS-level components that might detect the bootkit's absence and attempt to reinstall it.
3. Triggering Bootkit's Uninstall Feature: Some sophisticated bootkits, like BlackLotus, may include a built-in uninstall feature. However, leveraging this requires deep knowledge of the specific bootkit's internal workings and how to trigger this functionality, making it a case-by-case and highly technical solution.

By combining robust prevention mechanisms like ESP access control and customized Secure Boot with clear removal strategies, organizations can significantly enhance their resilience against the growing threat of UEFI bootkits.

Key Takeaways

• UEFI bootkits are a critical and evolving threat. The discovery of BlackLotus confirmed that even with UEFI Secure Boot enabled on fully updated systems, bootkits can bypass defenses, impacting billions of devices globally.
• UEFI security suffers from systemic failures. Issues include excessively long and often flawed revocation processes, incomplete DBX updates, and a lack of transparency from OEMs and Microsoft regarding signed binaries.
• Many devices will remain "vulnerable forever." Due to the end of development support, a significant number of older devices will never receive critical firmware updates, creating a persistent and unpatchable attack surface.
• Standard security measures are necessary but insufficient. While OS and firmware updates, enabled Secure Boot, and security software are foundational, they do not provide complete protection against sophisticated UEFI bootkits.
• Proactive, granular defenses are crucial. Implementing EFI System Partition access control to prevent unauthorized modifications and utilizing partial UEFI Secure Boot customization for faster manual revocations or attack surface reduction are highly effective strategies.
• Full Secure Boot customization offers maximum security but demands high expertise. While replacing all Secure Boot keys with an organization's own provides ultimate control, its complexity and potential for rendering systems unbootable mean it's best reserved for very sensitive systems with dedicated administrative resources.

About the Speaker(s)

Martin Smolar is a Malware Researcher at ESET, a global leader in endpoint security and EDR (Endpoint Detection and Response) solutions. ESET boasts nearly 30 years of experience in threat intelligence and threat hunting, with its team being behind numerous significant cybersecurity discoveries. Notably, ESET has played a crucial role in researching and mitigating cyberattacks related to the Russian invasion of Ukraine, including the identification of initial wiper attacks in 2022 and new versions of the Industroyer malware targeting Ukrainian energy providers. Within the specialized field of UEFI research, ESET's contributions are particularly prominent, with the team responsible for discovering almost half of all publicly known UEFI threats found in the wild, including the ESpecter UEFI bootkit. Smolar's expertise stems from this extensive first-hand experience in analyzing real-world UEFI malware, positioning him as a leading voice in understanding and combating these low-level threats.