Windows WPBT vulnerability allows Rootkit installation

Windows[German]I would like to once again flush up a security issue that affects users of Windows systems. In September, it became known that a vulnerability in WPBT allows attackers to install a rootkit on Windows machines. There is virtually nothing users can do about it and they have to hope for Microsoft's security features like WDAC.


Microsoft, Intel and other manufacturers have been telling us for years how secure systems have become. Intel's Management Engine, Microsoft's UEFI, Secure Boot and TPM, and whatnot. In fact, some of the systems are as full of security holes as a Swiss cheese in terms of security.

Nightmare WPBT

We need to take a leap back in time to 2015. At the time, I had already addressed the issue of WPBT in the German blog post Backdoor 'Windows Platform Binary Table' (WPBT). At that time, it was about the Lenovo Service Engine, which messed up, but also survived a Windows reinstallation (see my German blog post Lenovo Service Engine (LSE) – Superfish reloaded II) – WPBT makes this possible.

A platform can be provisioned with the Windows operating system by entities including an enterprise, a system reseller, or an end-user customer. If the platform has drivers, system services, or executable files that are integral to the platform, the platform binaries must either be distributed as part of the Windows image or they must be injected into the Windows image by each of the possible provisioning entities. A rich set of tools exist to aid Windows provisioning, ranging from driver injection and offline registry management to sysprep imaging tools. However, there is a small set of software where the tools are not enough. The software is absolutely critical for the execution of Windows but for one reason or another, the vendor is unable to distribute the software to every provisioning entity. This paper describes a mechanism for a platform, via the boot firmware, to publish a binary to Windows for execution. The mechanism leverages a boot firmware component to publish a binary in physical memory described to Windows using a fixed ACPI table.

The information provided here was originally published in conjunction with the availability of Windows 8. The guidance and requirements to use WPBT functionality has been updated for the Windows 10 timeframe.

With Windows 8, Microsoft has laid the groundwork for doing some pretty nasty things on systems. The technology is called 'Windows Platform Binary Table' (WPBT) and is described in detail in this Word .docx document.

WPBT provides the ability to execute code to manipulate Windows operating systems at the BIOS boot stage (UEFI is also included). Thus, drivers, updaters, etc. can be injected in the boot phase (from the ACPI tables of the BIOS). The original idea was to allow OEMs to perform updates – regardless of whether the user performed a Clean Install of Windows.

Lenovo used this to include its own updater in the Windows autostart, no matter what the user did. And here is the hint that HP and Dell use this to inject drivers from the BIOS into a Windows via the function key [F6].


The WPBT vulnerability

Security researchers at Eclypsium had addressed the issue in mid-September 2021 in the post EVERYONE GETS A ROOTKIT. The Eclypsium research team identified a vulnerability in Microsoft's WPBT feature that could allow an attacker to execute malicious code with kernel privileges when a device boots up.

The problem arises because, although Microsoft requires that a WPBT binary be signed, it will accept an expired or revoked certificate. This means that an attacker can sign a malicious binary with any readily available expired certificate. This issue has affected all Windows-based devices since Windows 8, when WPBT was first introduced. The researchers have successfully demonstrated the attack on modern Secured Core PCs running the latest boot protections.

This vulnerability can potentially be exploited across multiple vectors (e.g., physical access, remote access, and supply chain) and through multiple techniques (e.g., malicious bootloader, DMA, etc.). Organizations must consider these vectors and take a layered approach to security to ensure all available fixes are applied and potential device vulnerabilities are identified.

WDAC: Protection via belts and suspenders

The colleagues at Bleeping Computer picked up on this in this post, and also address Microsoft's solution to protect against something like this. Microsoft recommends using a Windows Defender Application Control (WDAC) policy. This can be used to control which binaries can run on a Windows device. This also works for binaries contained in WPBT.

However, this recommendation has several catches. WDAC is only available in Windows 10 Enterprise systems from Windows 10 1903 and higher, on Windows 11 or on Windows Server 2016 and higher, or the policies can only be created there. On older versions of Windows, administrators can use AppLocker policies to control which apps are allowed to run on a Windows client.

But all home editions are left out. Again, an example where vendors' "smart ideas" pretty much leave users out the window. Linux installations are rather not at risk in this scenario, as they do not run the Windows WPBT binaries. Again, a case that shows that we need to move towards open source hardware and software so that such messes as WPBT can be removed.

Cookies helps to fund this blog: Cookie settings

This entry was posted in Security, Windows and tagged , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *