diff --git a/readme.md b/readme.md index 290b68e..f549879 100644 --- a/readme.md +++ b/readme.md @@ -37,10 +37,10 @@ Where code execution can be obtained inside a boot application, it may be possib | [bitpixie](#bitpixie): PXE soft reboot does not wipe derived bitlocker keys from memory | **Only exploitable on UEFI systems (not legacy BIOS, or CSM). Legacy integrity validation affected (where vulnerable bootmgr is used), secure boot integrity validation affected**

PXE soft reboot is allowed when booting from network, and just does `BS->LoadImage()` and `BS->StartImage()`.

Derived BitLocker keys are still in memory at the time `BS->StartImage` is called.

They can then be dumped from memory.

In addition: BitLocker keys are derived very early into loading a boot application. If loading the PE from disk failed, integrity validation is not performed and derived keys remain in memory.

A PXE soft reboot can then be performed, thus this bypasses legacy integrity validation too.

See also [the public disclosure](https://haqueers.com/@Rairii/109817927668949732).

Fixed by wiping bitlocker keytables in `bootmgr!BlNetSoftReboot` before calling `bootmgr!PxeSoftReboot`. This bug is CVE-2023-21563. | November 2022 (build 25236); January 2023 (backport)

Where Secure Boot integrity validation is used, **a downgrade attack would still work to exploit this vulnerability.** | February 2023, discovered in August 2022 | Rairii | | [push button decrypt](#push-button-decrypt): reset in WinRE can be interrupted during decrypt, enabling attacker to get a shell to disable key protectors | **Windows Server is not vulnerable due to not supporting the reset feature. Legacy integrity validation and secure boot integrity validation affected, where vulnerable winre image is used**

When booting to a system's WinRE, keys are derived for the associated osvolume. These keys are allowed to stay in memory when doing a push button reset (with data removal).

Starting a "just remove my files" reset will start decrypting the drive at ~98% completion.

Rebooting at this point will cause a reboot into winre which will show an error and a button which reboots.

After rebooting, windows setup is launched into an upgrade screen. `Shift+F10` to get a shell works here.

A shell here is enough to pause decryption and remove all key protectors, the plaintext VMK can then be used to decrypt the FVEK which can be used with a previously made disk image.

Fixed by requiring a BitLocker recovery key before a reset. This bug is CVE-2022-41099. | November 2022 (winre image must be patched manually) | May 2023 | Unknown | | [dubious disk](https://wack0.github.io/dubiousdisk/): arbitrary code execution in the context of the boot environment | Exploitation of this bug or its variants achieves arbitrary code execution in the context of the boot environment, therefore allowing for either derivation of bitlocker keys (with arbitrary code execution in bootmgr) or dumping of the bitlocker keytable (with arbitrary code execution in some other boot application).

This bug and variants of it are CVE-2022-30203, CVE-2023-21560, CVE-2023-28269, CVE-2023-28249, (unknown), and CVE-2024-38065. | Various fixes between July 2022 and July 2024. **A downgrade attack would still work to exploit these vulnerabilities.** | June 2024 (public writeup, missing the variant fixed in July 2024); originally discovered in August 2021 and exploited between January and March 2022 | Rairii | +| CrashXTS: cryptographic attack, allows for precise corruption of SYSTEM hive leading to hiberfile written in the clear | BitLocker uses AES-XTS. By taking several images of the crypted partition, it is possible to find the offset of the `SYSTEM` hive, and therefore the offset of `SYSTEM\ControlSet001\Control\CrashControl` key, and corrupt the hive in such a way that the filter driver used for encrypting the hiberfile when writing it out to disk is not loaded. Therefore, one can then hibernate the system, dump the partition again, and get a full plaintext (compressed) RAM dump including the volume keys.

See also [the public writeup](https://dfir.ru/2025/01/20/cve-2025-21210-aka-crashxts-a-practical-randomization-attack-against-bitlocker/).

Fixed by causing a bugcheck if that filter driver is not present for loading when it is required. This bug is CVE-2025-21210. | January 2025 | January 2025 | Maxim Suhanov | | break out in hives: systemdatadevice element causes winload to use attacker specified SYSTEM hive | Starting from Windows 10 (th1), support for the `systemdatadevice` element was added to winload. If present, winload reads the SYSTEM hive from this device instead of osdevice.

Thus, attacker can grab SYSTEM hive from WinPE, modify Setup!CmdLine to cmd.exe, and cause winload to use this hive when booting WinRE.

When booting WinRE after this, a SYSTEM shell will open with the bitlocker keys in memory for osvolume if they were derived; thus, bitlocker bypass.

Fixed by removing the ability to load SYSTEM hive from systemdatadevice. This bug is CVE-2024-20666. | January 2024 (winre image must be patched manually) | February 2025; discovered in March 2023 | Rairii | | break out in hives 2: alternative method for exploiting systemdatadevice element, usable with a downgrade attack | The fix for break out in hives updated winload.

However, earlier (unfixed) revisions of winload can **potentially** still run to boot its major version of Windows (may not work in practise for every version).

Thus, attacker can bring in an old winload, modify BCD to boot from it, and repeat the attack, however a different exploitation method must be used.

**The `winpe` element must be set in BCD (if it is not, the SYSTEM hive in the bitlocker encrypted osvolume will get corrupted!)**

The working SYSTEM hive here would come from an `install.wim` image of the same major version of Windows (not WinPE/WinRE). The Win32 subsystem will not be able to initialise fully, but smss can be configured in `ControlSet001\Control\Session Manager!SetupExecute` to achieve arbitrary native subsystem code execution as SYSTEM with derived keys in memory.

Fixed by wiping `systemdatadevice` element in bootmgr if Secure Boot is enabled, but the fix was only applied to the PCA 2023-signed bootmgr_ex, so **without the KB5025885 mitigation enabled, this vulnerability is still present and remains unfixed.** This bug is CVE-2025-21213. | January 2025, in PCA2023-signed bootmgr_ex only | February 2025; discovered in January 2024 (after the original fix) | Rairii | - ### dangerous association A vulnerable system will have the May 2022 or June 2022 updates installed, but not any later updates.