When you power on a Windows machine the very first software that comes up is the UEFI BIOS firmware. This firmware initializes and tests the system hardware, including the CPU, memory, hard drives, keyboard and more. It then proceeds to boot the operating system and hands over control to Windows. Given BIOS firmware is the first code executed after power on, its security is critical to overall system security. A compromise at this foundational level can jeopardize the entire system’s security and stability.
But how does the UEFI BIOS firmware get compromised or attacked?
The UEFI BIOS Firmware Ecosystem
Before we answer the question of how UEFI firmware gets compromised, let’s take a moment to explain how firmware gets onto the end device in the first place. The UEFI firmware is often developed by an independent software company that specializes in firmware, such as Phoenix Technologies, AMI, or Insyde Software. These companies are collectively referred to as independent firmware vendors (IFVs). The IFVs write the software but often rely on components from open-source reference code such as TianoCore EDK II and OpenSSL. The UEFI firmware is then provided to downstream vendors such as motherboard manufacturers, original design manufacturers (ODMs) and then ultimately to the original equipment manufacturer (OEM) such as Dell, HP or Lenovo. The exact supply chain sequence and companies involved will vary, but the main point is that the UEFI firmware goes through many hands before it winds up with the end user, and this leaves room for vulnerabilities to be introduced into the process.
Three Categories of Vulnerabilities
There are multiple ways that UEFI firmware can be compromised. Below are three common categories or methods by which UEFI vulnerabilities can be accidentally or purposely introduced and then exploited by malicious actors.
-
Supply Chain Implants
These are perhaps the easiest to understand and are often performed by nation-state actors who are trying to disrupt commerce or otherwise sabotage businesses. One way this can be done is by implanting malicious firmware during the device manufacturing process or while the system is in transit to the customer. In other words, subvert the normal supply chain and inject malicious code along the way. An example of this type of attack is CosmicStrand which is believed to be the work of Chinese hackers and was specifically targeted at Gigabyte or ASUS motherboards. This type of exploit is becoming more common and is something which can affect an end user straight out of the box, so to speak.
-
Source Code Bugs
As with most software, one of the more common ways that vulnerabilities are introduced is via a source code bug. This can take many forms including poor security design, developer error, or reliance on third-party open-source code. UEFI firmware is no exception, and a well-publicized example of a source code bug is PixieFail. In the case of PixieFail, multiple security vulnerabilities were discovered in the network protocol stack of the TianoCore EDK II open-source implementation of UEFI. This reference implementation is utilized by most UEFI firmware software developers. PixieFail could be exploited to achieve remote code execution, denial-of-service (DoS), DNS cache poisoning, and leakage of sensitive information.
Security bugs in large, open-source, reference implementations such as TianoCore EDK II can be particularly difficult to detect. Because in isolation a piece of code may not be vulnerable, but when compiled with other code or given specific data inputs, the code can provide a path for attackers to exploit the software. The vulnerabilities can be sitting out there in the UEFI firmware for years until a security researcher finds them and alerts the vendor that developed the software. This is, however, the best-case scenario and presumes that a malicious actor doesn’t find the exploit first. Unfortunately, this can sometimes feel like a game of whack-a-mole as vulnerabilities are discovered and patched, only to have new ones emerge on the scene. This is why constant vigilance and frequent upgrade of UEFI firmware is imperative to keep attackers at bay.
-
Bad Configurations in Manufacturing
During the lifecycle of a device, such as a laptop, many different vendors have their hands in the process of designing, developing and manufacturing the system. Because of the complexity and number of vendors involved, the result is often that downstream vendors, such as an original design manufacturer (ODM), are not subject matter experts on the UEFI firmware that is supplied by an upstream vendor, such as an independent firmware vendor (IFV). Therefore, the downstream vendor will sometimes use components “as-is” provided by upstream vendor, and will not customize or configure these components; either due to lack of knowledge on the part of the downstream vendor, or lack of instructions on the part of the upstream vendor. The unfortunate result is that devices with bad UEFI firmware configurations and the associated vulnerabilities can make their way into the hands of end users. A high-profile example is a vulnerability that Microsoft has created awareness about called BlackLotus. With BlackLotus, a rogue Windows bootloader could be inserted into the special UEFI partition that the firmware uses to load the operating system. This rogue bootloader, while present on this partition, should never be loaded by firmware because there is a special database called DB/DBX that explicitly tells the firmware which bootloaders are valid. However, the updated DB/DBX must be configured, and if it is not, you have a misconfiguration which results in a terrible exploit.
The following are some specific categories of bad configuration which can lead to extreme firmware vulnerabilities.
Vendor Leaves Debug Mode Enabled
As a part of the design, development, manufacturing, and testing process for a new device, debug features are enabled that provide a deeper level of access to the system. For example, a developer might be able to plug in via USB to the system in a special, low-level debug mode that allows access to privileged information. In a development system, this type of feature is fine to have enabled, but in a released system this feature presents an incredibly powerful vulnerability or attack surface.
If a system has USB debugging enabled, all it would take is an attacker to plug in a special device into the vulnerable device for a few seconds, and the entire device can be compromised at one of the lowest, and therefore highly privileged, levels in the system. This is referred to as an “evil maid” attack; any attack that someone with a few seconds of physical access could successfully pull off. For devices at home, these types of attacks are not as relevant since homes have locks on them, but in the case of offices or hotel rooms where cleaning crews enter at night who are not necessarily trusted, these types of attacks become relevant.Leaving Flash Unlocked
During development, a system’s SPI flash, which contains the system’s UEFI firmware, is often unlocked to allow for flashing arbitrary firmware images to test and develop the firmware. However, once development has ended, and the system has been manufactured, SPI flash must be locked down to prevent malware from being introduced into the firmware. This step is not always done by firmware developers, either due to overlooking a step in the development process, or by intention.Leaving Test Keys in the Firmware
An artifact of the development process that can make its way into a final product are test keys. In UEFI, as well as many other software/firmware projects, cryptographic keys are often used to validate, verify, and ensure the integrity of data inside, or inbound to the system. These keys are used, for example, with Secure Boot. However, during the development process, developers need to be able to boot things that are considered “insecure” such as custom toolsets for testing features of the system, but this needs to be done with Secure Boot enabled, and thus the reasoning for test keys: a way to boot insecure things in a closed environment to test all features of a system. However, an issue that can arise is when these keys accidentally make their way into a shipped product. In the case of the widely publicized PKfail vulnerability, these test keys ended up in delivered systems which could result in malicious code being loaded even with Secure Boot enabled.
What Can Be Done to Protect UEFI BIOS Firmware?
Due to the complexity of UEFI firmware and the manufacturing process it is inevitable that firmware vulnerabilities will continue to exist and without proper diligence these vulnerabilities can wreak havoc on an individual or organization. Fortunately, there are prudent steps and best practices that can be followed to avoid common pitfalls and help secure UEFI BIOS firmware. Following these best practices can help prevent data theft, denial-of-service attacks, operational disruption and more. And some of the most prudent steps to take are keeping UEFI firmware up-to-date and using a UEFI BIOS firmware management tool such as FirmGuard.
