so, it's been almost a month since the patch released (exactly a month would be friday)
Introducing bitpixie (CVE-2023-21563), a 17 year old bug (introduced in 5231.2 from october 2005 at the latest) leading to bitlocker (with TPM) bypass and key dumping
When booting from network via PXE, there's a special type of boot entry allowed called "PXE soft reboot".
This just loads the given PE from the remote PXE server, and does BS->LoadImage and BS->StartImage on it.
...except when BS->StartImage is called, derived BitLocker keys are still in memory!
When Secure Boot is disabled, you can just load any payload you want, of course.
When Secure Boot is enabled, things are slightly more complicated.
Luckily, there's a way for a physically present user to bypass Secure Boot: if you go into advanced options menu and choose "disable driver signature enforcement", win8+ winload will load a selfsigned mcupdate*.dll, and call its entrypoint before ExitBootServices.
When loading bootmgfw again, winload won't know of the older BitLocker keytable, and will enable access to the advanced boot options menu.
You need to set up enough of a Windows image so winload can reach the code path to load and execute mcupdate*.dll.
I used windows 8.1 RTM (9600.16384) for this, the files required from its boot.wim are:
(and of course, your payload as mcupdate_AuthenticAMD.dll and mcupdate_GenuineIntel.dll)
This is a total of 136MB of data uncompressed, and a 42MB WIM. It can probably be smaller than that :)
To dump bitlocker keytables, your payload must scan physical memory pages looking for a valid keytable.
But what about getting the bitlocker keys derived in the first place?
When loading a boot application, BitLocker keys are derived very early. If loading the boot applicaiton PE from disk fails, integrity validation is not performed and derived keys remain in memory.
That way, in a BCD coming from PXE server, the default boot option can have a device of the BitLocker-encrypted OS partition, a path of "" (valid, but will always fail), and a recovery sequence pointing to the pxesoftreboot entry.
Then, for Secure Boot being enabled, you can swap the BCDs on the PXE server after the first one gets loaded. You can slow the boot down by pressing down arrow during bootmgr initialisation to cause the boot menu to show up.
Then just PXE boot from this, using the vulnerable bootmgfw from the system you are attacking :)
If Secure Boot is used for integrity validation (the default when Secure Boot is enabled), a downgrade attack can be performed here, and any vulnerable bootmgfw can be used.
Make sure your systems are patched, and using legacy integrity validation configured to use PCRs 0, 2, 4, 7 and 11. "Secure Boot integrity validation" is not secure!
