Hey, guys! How are y’all doing today?
Today, we’re going to look at the security flaws in Microsoft WPBT that were freshly unearthed by security researchers from the firmware security company, Eclypsium. One cannot turn a blind eye to these flaws because they affect ALL Windows-based devices all the way from Windows 8!
Shocked, yet? Let’s understand the whole story, shall we?
A little bit of backstory
Introduced in the early 2000s, there’s this protocol called Advanced Configuration and Power Interface (ACPI). This protocol 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. When Windows 8 came about, ACPI 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.
However, 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.
ACPI & WPBT in depth
Advanced Configuration and Power Interface (ACPI)
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. To enable operating systems to configure and manage the power of hardware components instead of depending on BIOS/UEFI firmware is the main reason ACPI was invented. Through the shift of power to the OS, ACPI allowed for more dynamic and complex power management decisions than could be coded into firmware.
ACPI functions 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.
Windows Platform Binary Table (WPBT)
First introduced in Windows 8, Windows Platform Binary Table (WPBT) is an ACPI table which has the ability to 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.”
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. A number of vendors has used this technology, including Lenovo, ASUS, and many others.
Unfortunately, where the balance tilts is, by executing files and modifying the operating system, this type of functionality can be seen as a vendor-specific rootkit. Alex Ionescu, Acclaimed researcher and co-author of Windows Internals, has been vocal about the dangers of WPBT as a rootkit as early as 2012 and continues to do so today.
Eclypsium’s big discovery
In June 2021, the firmware security company publicly disclosed a series of 4 vulnerabilities, adoringly known as ‘BIOSDisconnect’, that allowed remote code execution within the firmware of a device during a BIOS update. They were to perform this attack on the most recent and secured Dell platforms, including Secured-Core PCs. They went on to present their findings with complete technical details at DEF CON 29, where they also performed 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.
During their presentation, they mainly focused on compromising the BIOS update but didn’t really touch much on how they were able to deposit the malicious executable in the Windows startup folder. This is where the WBPT security flaw discovery comes in.
When compromising the BIOS update process, they were able to load their own implant DXE driver, which controls various boot-related functions. Since UEFI ACPI protocols allow drivers to modify ACPI tables, Eclypsium researchers were able to add a new WPBT table of their choice. The WPBT table specifies the actual location of the system binary that Windows will execute. As a result, they were able to use their “malicious” driver to create a WPBT table pointing to the payload of their choice. Alternatively, they could have patched an existing table using techniques shown in the SignedUEFIShell project on GitHub.
The point to be made here is, this should NOT have worked because WPBT requires any binaries to be properly signed. Microsoft’s WPBT code-signing policy backs this up, too. It 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.”
Yet, Eclysium’s testing exposed that this check will still pass even if the code signing certificate has been explicitly revoked.
As POC, they signed their malicious code using a Hacking Team code signing certificate that was revoked back in 2015. As to where they got these certificates from, 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. Eclypsium purposefully used this certificate to highlight the severity of the issue, but the same process would work with other revoked certificates as well.
This attack is also noteworthy because it allows a hacker 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 uses firmware to directly write the malicious code to disk. However, in the case of WPBT, a hacker could simply avoid BitLocker since the malicious file is pushed to the OS and stored in c:\windows\system32 and run on startup.
Eclypsium’s Firmware Attack Demo: https://youtu.be/Ca8NRYT-HZA
How can a hacker use this vulnerability to their advantage?
There are many different ways to go about exploiting this security flaw.
In Eclypsium’s POC, they started in a privileged position having already compromised the system’s firmware during the firmware update process. Nonetheless, 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.
Some of the possible threat vector includes:
- 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.
Conclusion
Since this is a problem in Microsoft’s implementation of WPBT, this will affect virtually all Windows machines, going back to Windows 8 when WPBT was first introduced in October 2012.
Eclypsium was unsuccessful in finding documentation from Microsoft detailing how to disable WPBT. However, others have published options such as the dropWPBT project on GitHub that organizations can take into consideration. Still, as there is no unofficial solution at the moment, organizations should evaluate these options and apply them at their own discretion.
This issue further sheds light on the complexity and challenges involved in securing the boot process of modern devices. These past few 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 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 different areas ranging from establishing the root of trust on devices and kernel protections, to virtualization-based security.
However, it is vital to know that in reality, we are talking about many technologies and many different vendors working together. Details will differ from OEM to OEM, which opens up many opportunities for mistakes or vulnerabilities. A flaw in the chain can jeopardize 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 way 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. Just like any complex system, organizations need the ability to audit the system, find vulnerabilities, and verify their integrity.
So, there you have it! For more interesting news and updates, sit tight and stay tuned.
Until next time, friends!
Credits: Eclypsium