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:

Windows\apppatch\drvmain.sdb
Windows\Boot directory
Windows\fonts\vgaoem.fon
Windows\Inf directory
and in Windows\system32:
Boot, config, drivers directories
apisetschema.dll
bootvid.dll
ci.dll
C_*.NLS
C_G18030.DLL
C_IS2022.DLL
hal.dll
HalExtIntcLpioDMA.dll
kd.dll
kdcom.dll
kdstub.dll
l_intl.nls
ntoskrnl.exe
PSHED.DLL

(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!

#infosec #BitLocker #CVE_2023_21563 #Windows

when I say "it's easily deduced from bindiffing", I mean: it's a stupid 16+ year old bug, I'm fully expecting public details to appear before I can be bothered to make a writeup.

#CVE_2023_21563

So, now that CVE-2023-21563 and CVE-2023-21560 got patched:

I initially saw the fixes for these two land in bootmgfw.efi of rs_prerelease build 25236, which was released on 2022-11-02.

The underlying issue for CVE-2023-21563 is easily deduced from bindiffing.

Patch, and make sure your osdevice BitLocker is configured securely. (This means legacy integrity validation set to PCRs 0, 2, 4, 7, 11. If you use Secure Boot as integrity validation - the default setting - then you're still vulnerable to downgrade attacks.)

Also, just to be clear, CVE-2023-21560 - named "Windows Boot Manager Security Feature Bypass Vulnerability", is mentioned in its FAQs as being a bitlocker bypass. It can also be used to bypass Secure Boot.

#infosec #BitLocker #CVE_2023_21560 #CVE_2023_21563 #PatchTuesday