A Call to Action: Bolster UEFI Cybersecurity Now

Unified Extensible Firmware Interface (UEFI) is a critical software standard in modern computing, yet most people have never heard of it. UEFI is essential to most computers; it replaces the legacy BIOS format, serving as an interface between hardware and operating systems. Attackers have exploited UEFI implementation flaws to gain persistence – that is, the ability to maintain access to a compromised system despite system resets and defensive actions. Based on recent incident responses to UEFI malware such as BlackLotus, the cybersecurity community and UEFI developers appear to still be in learning mode. In particular, UEFI secure boot developers haven’t all implemented public key infrastructure (PKI) practices that enable patch distribution (the Linux ecosystem implements it well).

The Cybersecurity and Infrastructure Security Agency (CISA) is sharing this information with the community regarding the challenges in responding to UEFI attacks to drive solutions that will provide value to system owners who will benefit from UEFI firmware that can be properly updated.

UEFI software is an important component

UEFI is the dominant software standard for firmware. Firmware is the software that manages the physical computing machinery that everything else depends on. When you press a power button, UEFI is what gets you from an intricate brick of lifeless silicon to your operating system. The operating system then does the business of the computer: logging you in, being a wireless router, playing a game, or managing an industrial robot. UEFI software also manages the different pieces of computing machinery (i.e., processor, hard drive, graphics card, USB ports, Wi-Fi antenna, etc.) so the operating system can make them function coherently together.

UEFI is a critical attack surface

Attackers have a clear value proposition for targeting UEFI software. UEFI is a compilation of several components (security and platform initializers, drivers, bootloaders, power management interface, etc.) so what attackers achieve depends on which phase and what element of UEFI they are able to subvert. But every attack involves some kind of persistence.

UEFI subversion can provide malicious software the ability to persist through

• A system reboot, as BlackLotus does – the malware survives basic defensive actions such as turning the device off and on again.
• An operating system reinstallation— Most incident response practices treat a reinstalled operating system as a clean device. Malware that persists through reinstallation can evade this standard incident response practice.
• A partial physical part replacement—For example, a compromised component in the motherboard or a corrupted PCI persistent flash storage would persist through a replacement of the physical hard drive. A device infected with this level of persistent malware basically needs to be thrown away rather than repaired.

These are just some examples of the persistence that a UEFI compromise grants an attacker. More persistent malware leads to increased difficulty and costs for removing an attacker from an organization’s systems.

Secure by Design and PSIRT maturity: The UEFI community’s response matters

As we evolve our responses to UEFI incidents and strengthen secure by design in the UEFI community, we should strive to create an environment where the threat from the adversary targeting UEFI is significantly reduced. The path to success involves multiple supply-chain stakeholders maturing their PSIRT (Product Security Incident Response Team) operations with a focus on timely vulnerability management, disclosure, and response. Mature PSIRT operations will require integration between the PSIRT, UEFI software development team, quality assurance testing team, and the update distribution channel software development team.  While these integration practices are well established for traditional software vulnerabilities, if they were integrated by the UEFI community, threats such BlackLotus would be much more routine to manage.

UEFI vulnerability response, including timely and effective update mechanisms with standard PKI, needs to be designed in to UEFI software engineering. Within UEFI-community organizations specifically, executives and leaders should provide support and resources to PSIRTs so they can conduct effective vulnerability management.

How Can We Improve UEFI Cybersecurity?

Secure by Design and PSIRT maturity work jointly to reinforce a holistic security engineering solution, which is more than just secure code. A holistic security engineering solution includes people and an operational mechanism for the feedback loop.

BlackLotus exploits a failure in secure update distribution – an issue at the intersection of Secure by Design and PSIRT maturity. BlackLotus can roll back a file to a vulnerable version and then exploit it, rendering the update distribution channel for UEFI updates on Windows not sufficiently resilient or secure. On May 9, 2023, Microsoft released guidance on how to manually prevent rollback to a vulnerable file version. Microsoft also released plans to automate revocation in early 2024, which is a step in the right direction.  However, we continue to work with Microsoft toward a Secure by Default update distribution implementation. BlackLotus highlights the importance of standard-practice PKI usage in secure boot file signing. There are other paths forward the entire UEFI community should take in parallel:

• System owners should be able to audit, manage, and update UEFI components just like any other software that is being acquired, including with software bill of materials. AMI has suggested a good start.
• Operational teams should expect to be able to collect, analyze, and respond to event logs that identify UEFI-related activities (e.g., changes, updates, add/remove components) using UEFI native watchdog and reporting capabilities relayed to the operating system or endpoint detection and response tools as appropriate. 
• UEFI component developers should use secure development environments and adopt software development best practices, just like any other software.
• The UEFI vendor community should universally adopt uninterrupted and reliable update capabilities to ensure that UEFI component updates are not burdensome to operational communities and end users. For example, keys that sign vulnerable and updated boot files should not have to be manually revoked or excluded by system owners.
• With the UEFI Security Response Team (USRT) continuing to provide leadership, the UEFI community should broaden engagement in communities, like FIRST, to expand adoption of best practices for PSIRT operations.

For more detail on each of these paths, the Software Engineering Institute at Carnegie Mellon University has an important deeper dive in their publication Securing UEFI: An Underpinning Technology for Computing; this material is based on work funded and supported by CISA with CMU. Also, the National Security Agency published additional mitigation guidance for system administrators, BlackLotus Mitigation Guide.

Adversaries have demonstrated that they already know how to exploit UEFI components for persistence, and they will only get better with practice. CISA encourages the UEFI community to pursue all the options discussed in this blog with vigor. And the work must start today.