Depending on the customer’s preference, possible initial access vectors in our red teaming exercises typically include deployment of dropboxes, (device code) phishing or a stolen portable device. The latter is usually a Windows laptop protected by BitLocker for full disk encryption without pre-boot authentication i.e. without a configured PIN or an additional key file.

While hardware-based TPM sniffing attacks are well known and covered in public courses, they typically involve hunting down board schematics on Chinese websites and some prowess using a soldering iron. Physical craftsmanship is definitely not a strength of mine, which is why I was particularly interested when Thomas demonstrated a concrete software-only attack in his 38C3 talk: Windows BitLocker: Screwed without a Screwdriver.

Even compared to other software attacks such as the “push button decrypt”, the exploitation of the abused bitpixie vulnerability is non-invasive, does not require any permanent device modifications and no complete disk image, thereby allowing a fast (~5 minutes) compromise and more flexible integration in certain social engineering scenarios.

Bitpixie Linux Edition

While Thomas did release a detailed blog post, the concrete exploit code was not disclosed. To fully understand the attack, reproduce the original research, and demonstrate the concrete impact to our customers, I set out to develop a public proof of concept.

The Linux-based exploitation strategy roughly depicted on the above diagram (from Thomas’ presentation) is to:

1. Enter the Windows Recovery Environment by using Shift+Reboot from the power menu of the login screen
2. Downgrade to vulnerable Windows Boot Manager (bootmgfw.efi) via PXE boot
3. Specify broken default Boot Configuration Data (BCD) to force a pxesoftreboot fallback
4. PXE boot into signed Linux shim loader (shimx64.efi)
5. Load signed GRUB (grubx64.efi) boot loader
6. Load signed Linux kernel and initial ram filesystem
7. Exploit Linux kernel lockdown mode to scan physical memory for BitLocker Volume Master Key (VMK)
8. Mount encrypted volume using the dislocker FUSE driver and the extracted VMK

This video shows a full rundown of this technique:

Bitpixie WinPE Edition

As Thomas describes in his second blog post discussing possible remediation strategies, Microsoft uses different UEFI certificates to sign boot components based on their origin:

• Microsoft 1st party certificate, signs all Windows bootloaders
• Microsoft 3rd party certificate, signs everything else commonly understood to boot under Secure Boot, such as Linux shims

Vendors such as Lenovo with their secured-core PCs disable the latter by default.

As a result, the above attack chain fails at step 4 because the third-party signing certificate used is not trusted. However, there is nothing conceptually stopping an attack flow where third-party signed components are replaced by their Windows native equivalents:

4. Boot into same Windows Boot Manager (bootmgfw.efi) a second time via PXE boot, but specify different BCD
5. Load a WinPE based boot image (boot.wim) and corresponding ram disk (boot.sdi)
6. Load signed Windows boot loader (winload.efi)
7. Load signed Windows Kernel (ntoskrnl.exe)
8. Scan physical memory for a VMK using a modified version of WinPmem which internally uses a signed driver (winpmem_x64.sys)
9. Use VMK to decrypt encrypted recovery password stored in BitLocker meta data
10. Use human-readable recovery password to unlock the encrypted volume

The second stage BCD used in step 4. is constructed according to the official Microsoft documentation. Physical memory is scanned by incorporating the original pattern-matching code into a modified version of WinPmem (winpmem.exe). The recovery of the human-readable recovery password is implemented in a minimal Windows port of the dislocker-metadata utility (dislocker-metadata.exe).

As presented, the WindowsPE-based attack flow uses only core components signed by Microsoft. At least in theory, it should therefore be applicable to all affected devices, as long as they trust the Microsoft Windows Production PCA 2011 certificate used to sign the vulnerable boot manager. In practice, it seems to be somewhat less reliable than its Linux-based counter part. Nonetheless, the provided automation scripts are hopefully useful in case you want to investigate whether your devices are affected.

Remediation

The Bitpixie vulnerability – and more generally both hardware and software-based attacks – can be mitigated by forcing pre-boot authentication, i.e., requiring an additional PIN and/or key file.