Revoking vulnerable Windows boot managers

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Community Hub.

If you're worried about the BlackLotus UEFI bootkit vulnerability (CVE-2023-24932) and how it might affect your device's security, you'll be pleased to learn about the measures Microsoft is taking to help keep you safe.

Back in February, we shared steps you can take to prepare to update the Secure Boot trust anchors for Windows, as the existing ones are approaching expiry. With the update to the Secure Boot trust anchor, we can address the threat of all previous, potentially vulnerable Windows boot components by revoking the old trust anchor. To this effect, the April 9 security updates includes a new Secure Boot revocation update (DBX).

If you're interested in applying this revocation on systems with the updated trust anchors, this article describes how to do just that. For now, we strongly recommend the steps in this article for testing and validation only.

The security benefits of Secure Boot

Secure Boot is a security feature in the Unified Extensible Firmware Interface (UEFI) that helps ensure that only trusted software runs during the system's boot sequence. We recommend the use of Secure Boot to help make a safe and trusted path from UEFI through the Windows kernels' Trusted Boot sequence.

As an industry standard, UEFI's Secure Boot defines how platform firmware manages certificates and authenticates firmware, and how the operating system (OS) interfaces with this process. For more details on UEFI and Secure Boot, refer to the Secure Boot page.

Secure Boot's main focus is to help protect the pre-boot environment from bootkit malware. A bootkit is a malicious program designed to load as early as possible in a device's boot sequence. Secure Boot helps ensure that only verified code executes before Windows. Verified code is firmware that runs early in the boot sequence, initializes the PC prior to the launch of Windows OS, and is trusted based on certificates configured in the firmware. Examples include UEFI firmware drivers, bootloaders, applications, and option ROMs (Read-Only Memory). Disabling Secure Boot puts a device at high risk of infection by bootkit malware.

Addressing the BlackLotus malware

The BlackLotus malware exploits a known security vulnerability called “Baton Drop,” tracked by CVE-2022-21894. It bypasses Secure Boot and then installs malicious files to the EFI (Extensible Firmware Interface) System Partition (ESP), which are then launched by the UEFI firmware. Baton Drop allows rollback of Windows boot managers to previous vulnerable versions that are not in the Secure Boot Forbidden Signature Database (DBX). It then exploits the vulnerability in Windows boot manager as part of an attack. For more information, refer to Guidance for investigating attacks using CVE-2022-21894: The BlackLotus campaign.

Windows boot manager mitigations that we released previously

To address this vulnerability, as part of the May 2023 servicing updates, we introduced a code integrity policy that blocked vulnerable Windows boot managers based on their version number. For versions of Windows boot manager that remained unaffected by this fix, we added them to the DBX.

However, we have found multiple cases that can bypass the rollback protections released during the May 2023 servicing updates. As a result, we are putting forth a more comprehensive solution that involves revoking the Microsoft Windows Production PCA (Product Certificate Authority) 2011.

New measures to help secure Windows boot managers

Here are the next steps to help protect against the malicious abuse of vulnerable Windows boot managers:

What we're doing: As our current trust anchors are expiring in 2026, we're already migrating to new ones (catch up on this in KB5036210: Deploying Windows UEFI CA 2023 certificate to Secure Boot Allowed Signature Database). This transition allows us to revoke trust for the Windows signing certificate, Microsoft Windows Production PCA 2011. This Product Certificate authority (PCA) is currently used to authorize trust for all Windows boot managers in Secure Boot.
What you can do: Once you've followed the steps in KB5036210 to add the new Windows trust anchor, you can follow the optional steps below to revoke trust in the Windows Production PCA 2011. Note that the earlier KB cautions that these updates should be done on “representative sample test devices” first. At this time, we strongly recommend the same cautious approach. Take the steps described in this article on “representative sample test devices” before attempting to perform these steps on production devices.

Guidelines for evaluating the Secure Boot DBX update

Understand the upcoming changes

By applying the DBX update to a secure boot enabled device, that device will no longer be able to boot from any Windows boot manager signed by the Microsoft Windows Production PCA 2011. This includes booting through existing recovery media, USB media, and network boot (WSD/PXE/HTTP) servers that do not have updated boot manager components. PXE boot is especially likely to be impacted. That's because you cannot update the binaries served by PXE until all machines supported by the network boot server are updated to run with the new DB update.

Plan the deployment

To prepare your device to receive the DBX update package, ensure that you have applied the DB update package first and deployed the new updated boot manager components signed by the Microsoft Windows UEFI CA 2023. Refer to KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932 for more details.

Confirm that your device has successfully applied the DB update package first. Open a PowerShell console and ensure that PowerShell is running as an administrator before running the following command: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023'
Screenshot of a PowerShell console with a command string.

If the command returns “True,” the update was successful. In the case of errors while applying the DB update, refer to the article, KB5016061: Addressing vulnerable and revoked Boot Managers.
After applying the April servicing updates, begin by testing the updates with individual devices. Test on the same firmware and specifications in the enterprise environment to minimize the risks in the case of firmware bugs in your devices.
Verify that your UEFI firmware version is the most recent available version by your firmware vendor or OEM.
For data backup steps, refer to this guide.
If you use BitLocker, or if your enterprise has deployed BitLocker on your machine, Back up your BitLocker recovery key. See this portal to ensure that your BitLocker keys are backed up before your next reboot for your selfhost device. In the unlikely event that device becomes inoperable after receiving the update, you can still unlock the hard drive.
For devices with third party full device or disk encryption, check with your disk encryption provider to perform your own set of tests before applying the update packages.
For detailed instructions on applying the DBX updates, refer to KB5025885: How to manage the Windows boot manager revocations for Secure Boot changes associated with CVE-2023-24932.

Why you need to update the DB before applying the DBX update

Note: You cannot apply the DBX update package through Windows updates on a device without first applying the DB update.

As part of the planning for the DB and DBX update packages, Microsoft, in collaboration with some of our OEM partners, has conducted extensive testing on various device configurations to detect and resolve any bugs in firmware implementations that could cause system failures or render a device unreceptive to these update packages. Despite our thorough testing, we acknowledge that we cannot cover every possible device configuration, so we strongly recommend customers to perform their own tests on their devices before applying the DB and DBX update packages.

Some of the associated risks with applying the DBX update package before updating the DB update package include:

The device firmware might encounter difficulties in processing the DB and DBX updates, leading to operational issues. In the handful of cases that we've encountered, we've notified the OEMs of the issue and blocked those devices from applying both DB and DBX updates until the issue can be remedied.
While unlikely, you might inadvertently cause BitLocker to enter recovery and lose Virtualization-based Security (VBS) protected secrets that are used by Windows Hello or Credential Guard.
Updating the PXE server to use 2023 signed binaries without applying the DB update first will cause the system to fail to boot, and inversely, applying the DBX update package will prevent any 2011 signed media from booting.

DO NOT apply the DBX to a device without DB update through manual update, using set-securebootuefi, as the system will not boot. Specifically, this will bypass the safety checks included in our servicing tool (Windows Updates) to guard against breaking issues. Update your device by relying on our published mitigations.

Continuing the journey of trust

In short, to establish new trust anchors, you need to untrust the Microsoft Windows Production PCA 2011. These updates are only a part of Microsoft's ongoing dedication to security. Microsoft anticipates releasing DBX updates in the future, with a goal of achieving mandatory enforcement no sooner than January 2025. We encourage IT admins and enterprise customers to invest in building workflows that ensure an efficient rollout of these updates across their device fleet.

Make sure you're getting the most out of your security experience by checking out the following resources:

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.