SoS Musings - Unified Extensible Firmware Interface (UEFI) Cybersecurity
By grigby1
Unified Extensible Firmware Interface (UEFI) is a software standard essential to most computers as it replaces the legacy BIOS format and acts as a bridge between hardware and operating systems. UEFI is the most widely used software standard for firmware, which manages the physical computing machinery that everything else relies on. UEFI software also manages the various components of computing hardware, such as the processor, hard drive, graphics card, USB ports, and more, so that the operating system can make them work together. However, UEFI is a critical attack surface as malicious actors have exploited UEFI implementation vulnerabilities to gain persistence, which is the ability to continue accessing a compromised system even through system resets and other protective measures. There have been many discoveries that emphasize the need to secure UEFI.
Millions of HP devices were discovered to be impacted by serious UEFI firmware vulnerabilities. Researchers at the firmware security company Binarly discovered 16 high-severity flaws in various implementations of UEFI firmware, impacting many HP enterprise devices. The flaws discovered in HP's UEFI firmware were given CVSS scores ranging from 7.5 to 8.8 and affected HP laptops, desktops, Point-of-Sale (PoS) systems, and edge computing nodes. The exploitation of the disclosed vulnerabilities enables attackers to perform privileged code execution in firmware and deliver persistent code. This code could be capable of surviving operating system reinstallations and enabling the evasion of endpoint security solutions, Secure Boot, and Virtualization-Based Security (VBS) isolation. The most serious flaws involved a number of memory corruption vulnerabilities in the firmware's System Management Mode (SMM), which allow the execution of arbitrary code with the highest privileges.
Researchers discovered two dozen UEFI vulnerabilities impacting millions of devices from major vendors. Binarly researchers identified 23 high-severity vulnerabilities in UEFI firmware code used by the world's largest device makers. These vulnerabilities affected millions of laptops, servers, routers, network appliances, Industrial Control Systems (ICS), edge computing devices, and other enterprise devices. Over 25 vendors were affected, including HP, Lenovo, Fujitsu, Microsoft, Intel, Dell, Bull (Atos), and Siemens. The vulnerabilities were discovered in InsydeH2O UEFI firmware provided by Insyde Software. The problem stems from the reference code associated with InsydeH2O firmware framework code. Researchers explained that all of the affected vendors were using Insyde-based firmware SDK to develop their firmware. The security holes mainly relate to SMM, and their exploitation can result in the execution of arbitrary code with elevated privileges. An attacker who has privileged user access to the targeted system can use the vulnerabilities to install highly persistent malware.
The "CosmicStrand" Windows firmware rootkit emerged, targeting UEFI for stealth and persistence. After a lengthy execution chain, the code deploys a malicious component inside the Windows operating system. This component connects to a Command-and-Control server (C2) and waits for commands to download more code snippets, which the malware maps into kernel space and assembles into a shellcode. Researchers obtained a shellcode sample that was used to create a new user on the victim's machine and add it to the local administrators group. Based on this, the shellcodes received from the C2 server could be stagers for attacker-supplied PE executables, and there were likely many more.
Researchers at the security company ESET reported the discovery of stealthy UEFI malware dubbed "BlackLotus" that can take over a computer's boot process even when Secure Boot and other advanced defenses are active and running on fully updated Windows systems. Unlike CosmicStrand, which works by targeting the UEFI firmware stored in the flash storage chip, BlackLotus targets the software stored in the Extensible Firmware Interface System Partition (ESP). BlackLotus marks a significant milestone in the ongoing evolution of UEFI bootkits. When successful, UEFI bootkits deactivate operating system security protections and ensure that a computer stays infected with stealthy malware running in kernel mode or user mode, even after reinstalling the operating system or replacing the hard drive. The researchers detailed the UEFI bootkit that circumvents Secure Boot on fully updated UEFI systems running updated Windows 10 and 11 versions. To defeat Secure Boot, the bootkit exploits a vulnerability in all supported Windows versions that Microsoft patched in January 2022. The logic flaw, dubbed Baton Drop by the researcher who discovered it, can be used to remove Secure Boot functions from the boot sequence at startup.
A collection of security vulnerabilities named "LogoFAIL" can lead to the installation of UEFI bootkits through bootup logos. The vulnerabilities were found to be affecting image-parsing components in UEFI code from different vendors. According to researchers, attackers could use the vulnerabilities to hijack the execution flow of the booting process and deliver bootkits. Since the problems are in image-parsing libraries, which vendors use to display logos during the booting routine, they have a significant impact, extending to x86 and ARM architectures. Binarly researchers believe that the branding has introduced unnecessary security risks, allowing malicious payloads to be executed by injecting image files into the ESP. An attacker could place a malicious image or logo on the ESP or in unsigned sections of a firmware update. Planting malware through this approach ensures virtually undetectable persistence on the system, as demonstrated by other attacks using infected UEFI components.
The US Cybersecurity and Infrastructure Security Agency (CISA) sounded an alarm regarding the need to improve UEFI cybersecurity. According to CISA, the path to enhancing UEFI cybersecurity requires multiple supply chain stakeholders to improve their Product Security Incident Response Team (PSIRT) operations. CISA encourages there to be a focus on timely vulnerability management, disclosure, and response. Mature PSIRT operations involve collaboration among the PSIRT, UEFI software development team, quality assurance testing team, and update distribution channel software development team. The agency emphasizes that these integration practices are well implemented for traditional software vulnerabilities, but if they were adopted by the UEFI community, threats like BlackLotus would become much easier to manage. UEFI vulnerability response, which includes timely and effective update mechanisms with standard Public Key Infrastructure (PKI), must be built into UEFI software engineering. System owners should be able to audit, manage, and update UEFI components in the same way that they would any other software. Developers of UEFI components should use secure development environments and follow software development best practices. To ensure that UEFI component updates do not burden operational communities or end users, the UEFI vendor community should universally adopt continuous and reliable update capabilities. For example, system administrators should not have to manually revoke or exclude keys that sign vulnerable and updated boot files. The Software Engineering Institute (SEI) at Carnegie Mellon University (CMU) has also published "Securing UEFI: An Underpinning Technology for Computing," which is based on CISA-funded and supported research with CMU, and focuses on technical efforts to secure UEFI. On the road to improving UEFI security, the paper recommends building a robust attestation ecosystem, improving the memory safety of critical UEFI code, applying least privilege and component isolation principles to UEFI code, and more.
Malicious actors have shown that they can exploit UEFI components for persistence and will improve as time goes on. Therefore, the UEFI and Science of Security (SoS) communities are encouraged to continue researching and developing new ways to improve UEFI security.
To see previous articles, please visit the Science of Security Musings Archive.