Eclypsium Researchers Identify Weakness in Microsoft WPBT Impacting All Windows-based Devices Since Windows 8
Executive Summary
In a connected, digitally transformed age, the term “no good deed goes unpunished” could perhaps be rephrased as ”no good feature goes unexploited”. The protocol called Advanced Configuration and Power Interface (ACPI) was introduced In the early 2000s when it became apparent that the energy consumption of billions of rapidly proliferating computing devices was a significant and increasing drain on national and regional energy supplies. ACPI was designed to efficiently manage energy consumption in PCs, along with several additional well-meaning use cases. As laptop usage and portable computing became universal demands, ACPI became a de-facto standard for nearly all systems. With the advent of Windows 8 the protocol evolved to include an object called the Windows Platform Binary Table (WPBT) and has since been included in every single Windows OS shipped since 2012. In June 2021, Eclypsium researchers discovered significant flaws in WPBT. These flaws make every Windows system vulnerable to easily-crafted attacks that install fraudulent vendor-specific tables. These tables can be exploited by attackers with direct physical access, with remote access, or through manufacturer supply chains. More importantly, these motherboard-level flaws can obviate initiatives like Secured-core because of the ubiquitous usage of ACPI and WPBT. Security professionals need to identify, verify and fortify the firmware used in their Windows systems.
Introduction
The Eclypsium research team has identified a weakness in Microsoft’s WPBT capability that can allow an attacker to run malicious code with kernel privileges when a device boots up. WPBT is a feature that allows OEMs to modify the host operating system during boot to include vendor-specific drivers, applications, and content. Compromising this process can enable an attacker to install a rootkit compromising the integrity of the device.
The issue stems from the fact that while Microsoft requires a WPBT binary to be signed, it will accept an expired or revoked certificate. This means an attacker can sign a malicious binary with any readily available expired certificate. This issue affects all Windows-based devices going back to Windows 8 when WPBT was first introduced. We have successfully demonstrated the attack on modern, Secured-core PCs that are running the latest boot protections.
This weakness can be potentially exploited via multiple vectors (e.g. physical access, remote, and supply chain) and by multiple techniques (e.g. malicious bootloader, DMA, etc). Organizations will need to consider these vectors, and employ a layered approach to security to ensure that all available fixes are applied and identify any potential compromises to devices.
“Microsoft recommends customers use Windows Defender Application Control (WDAC) to limit what is allowed to run on their devices. WDAC policy is also enforced for binaries included in the WPBT and should mitigate this issue. We recommend customers implement a WDAC policy that is as restrictive as practical for their environment. You can find documentation on WDAC – https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview“
ACPI and WPBT Background
Advanced Configuration and Power Interface (ACPI) is a specification that provides a hardware abstraction layer between a system’s firmware, operating system, and its components. ACPI was originally developed in order to let operating systems configure and manage the power of hardware components within a system instead of relying on BIOS/UEFI firmware. By moving this control to the OS, ACPI opened the door to more dynamic and complex power management decisions than could be coded into firmware.
At a functional level, ACPI works by using ACPI tables. These tables are loaded into memory by the firmware during the boot process and tell the OS what components are on the system and how they can be managed.
WPBT — The OEM Rootkit
Windows Platform Binary Table (WPBT) is an ACPI table first introduced in Windows 8. And while ACPI was originally intended to give the OS more control, WPBT can give the firmware a foothold in the OS. Microsoft describes WPBT as follows:
The WPBT is a fixed Advanced Configuration and Power Interface (ACPI) table that enables boot firmware to provide Windows with a platform binary that the operating system can execute. The binary handoff medium is physical memory, allowing the boot firmware to provide the platform binary without modifying the Windows image on disk.
- Source: Microsoft, Windows Platform Binary Table (.docx)
This functionality was intended to let OEMs include important files, drivers, or executables for the system without needing to modify the Windows image on disk. The technology has been used by a number of vendors including Lenovo, ASUS, and many others. However, by executing files and modifying the operating system, this type of functionality can be seen as a vendor-specific rootkit. Acclaimed researcher and co-author of Windows Internals, Alex Ionescu, has been calling out the dangers of WPBT as a rootkit as early as 2012 and continues to do so today.
Using and Abusing WPBT to Gain Malicious Code Execution
In June of this year, we publicly disclosed BIOSDisconnect, a set of four vulnerabilities that allowed us to gain remote execution within the firmware of a device during a BIOS update. Notably, we were able to perform this attack on the most recent and secured Dell platforms, including Secured-Core PCs. We subsequently presented the full technical details of these vulnerabilities at DEF CON 29, during which, we showed a demo of an exploit on a Secured-Core PC laptop with all available protections switched on, ending with a malicious executable being deposited in the Windows startup folder.
While our talk detailed how we compromised the BIOS update process, we did not show exactly how we were able to place that executable in the Windows startup folder. For that piece, we turned to WPBT and discovered an interesting weakness along the way.
By compromising the firmware update process, we were able to load our own implant DXE driver which controls various boot-related functions. Since UEFI ACPI protocols allow drivers to modify ACPI tables, we were able to add a new WPBT table of our choosing. The WPBT table specifies the actual location of the system binary that Windows will execute. As a result, we were able to use our “malicious” driver to create a WPBT table pointing to the payload of our choosing. Alternatively, we could have patched an existing table using techniques such as those shown in the SignedUEFIShell project on GitHub.
However, this officially should NOT have worked, as WPBT requires any binaries to be properly signed. Microsoft’s WPBT code-signing policy states:
All binaries published to Windows using the WPBT mechanism outlined in this paper must be embedded signed and timestamped. These images should be linked with the /INTEGRITYCHECK option and signed using the SignTool command-line tool with the /nph switch to suppress page hashes.
- Source: Microsoft, Windows Platform Binary Table (.docx)
However, our testing revealed that this check will pass even if the code signing certificate has been explicitly revoked. To highlight this, we signed our malicious code using a Hacking Team code signing certificate that was revoked in 2015. This and many other expired or revoked certificates are readily available to anyone on GitHub. This particular cert was revoked when the company’s tools including a UEFI rootkit were exposed in a major breach. We used this certificate just to highlight a particularly egregious example, but the same process would work with other revoked certificates as well.
This attack is also significant because it allows an attacker to drop a malicious file in the OS even while BitLocker encrypts the disk. BitLocker would prevent other types of threats such as the Hacking Team implant, which used firmware to directly write the malicious code to disk. However, in the case of WPBT, an attacker could avoid BitLocker since the malicious file is pushed to the OS and stored in c:\windows\system32 and run on startup.
Potential Attack Vectors and Scenarios
It is important to note that this weakness can be exploited in a variety of ways. In our example, we started in a particularly privileged position having already compromised the system’s firmware during the update process. However, this type of attack is possible using any technique that can write to memory where the ACPI tables (including WPBT) are located.
This can also be done by a malicious bootloader that could be introduced by the widespread BootHole vulnerability or via a DMA attack launched from a vulnerable component or peripheral.
With this in mind, security teams should consider the following potential threat vectors:
- Attacker With Physical Access – An attacker with physical access can launch a DMA attack to directly read and write system memory, and thus patch the WPBT table. Some DMA attacks can be performed without opening the device chassis while others will require the more invasive step of opening the device itself.
Countermeasures: Security teams should scan devices to identify components that are vulnerable to DMA attacks and verify that all vendor DMA protections are properly enabled.
- Remote Attacker – Remote attackers can compromise devices in a variety of ways. Malware such as TrickBot can identify vulnerable UEFI firmware that can be compromised directly. With control of firmware the attacker could directly control WPBT. Likewise, malware or remote attackers could use vulnerabilities such as BootHole to run a malicious bootloader capable of updating WPBT.
Countermeasures: Security teams will need to scan devices for any of the many vulnerabilities that could allow attackers to compromise the firmware or boot process. Teams will likewise need to verify that all available vendor protections are enabled including protections included with UEFI, chipset vendor, OS vendor, and any OEM-specific protections. Teams will likewise need to make sure their UEFI dbx revocation database is up to date. Teams should verify the integrity of all firmware, scan for known implants, and monitor the behavior or firmware on the device.
- Supply Chain Attack – Malicious firmware can also be introduced in the supply chain or vendor update process. In our example, we were able to compromise the valid firmware update process of the device, so it is important to note that such a compromise can happen before as well as after a device is acquired. In addition to compromises to UEFI/BIOS firmware, firmware within DMA-capable devices such as SSD, network adapters, or PCIe interfaces could lead to a corruption of the WPBT table.
Countermeasures: Security teams will need to verify the integrity of all system and component firmware to verify that it matches the approved vendor-supplied version of firmware. Again, teams will need to scan for the presence of known firmware threats and implants. Additionally, it is particularly important for teams to monitor firmware for any abnormal or anomalous behaviors since in the case of a supply chain attack, the approved, vendor-supplied firmware may already be compromised.
Impact and Take-Aways
Since this is a weakness in Microsoft’s implementation of WPBT, the issue will affect virtually all Windows machines, going back to Windows 8 when WPBT was introduced (October 2012).
“Microsoft recommends customers use Windows Defender Application Control (WDAC) to limit what is allowed to run on their devices. WDAC policy is also enforced for binaries included in the WPBT and should mitigate this issue. We recommend customers implement a WDAC policy that is as restrictive as practical for their environment. You can find documentation on WDAC – https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/wdac-and-applocker-overview“
In our research, we have not found documentation from Microsoft detailing how to disable WPBT. However, others have published options such as the dropWPBT project on GitHub that organizations can consider. However, as with any unofficial solution, organizations should evaluate these options and apply them at their own discretion.
This issue further highlights the complexity and challenges involved in securing the boot process of modern devices. In recent years chipset vendors, OS vendors, and OEMs have rightly developed a variety of features and capabilities to help make the boot process more secure. This includes things like UEFI Secure Boot, Intel’s Boot Guard, and Microsoft’s System Guard, System Management Mode (SMM) protections, and BitLocker.
Microsoft’s Secured-core initiative is an umbrella term that includes a collection of these protections that can be implemented by OEMs to build Secured-core branded devices. Secured-core covers a variety of areas ranging from establishing the root of trust on devices and kernel protections, to virtualization-based security. However, it is important to remember that in reality, we are talking about many technologies and many different vendors working together. Details will vary from OEM to OEM, which opens many opportunities for mistakes or vulnerabilities. A weakness in the chain can undercut the integrity of the entire process, allowing issues such as a weakness in WPBT, insecure firmware processes, or other issues to provide adversaries with a path around these protections.
As such, organizations should welcome the arrival of technologies such as Secured-core, yet be aware that they are not a checkbox that removes the risk to the boot process. Like any complex system, organizations need the ability to audit the system, find vulnerabilities, and verify their integrity.
To learn more contact us at [email protected]
