I just spent a day or so figuring this out, and CVE-2022-41099 is... really stupid...

I decided to call this "push button decrypt".

basically when you boot to WinRE tied to an OS install, keys for the os volume are derived (this is done by having a sha256 hash of a wim in the bitlocker metadata)

anyway, WinRE does not require bitlocker recovery key when choosing to "reset my PC" and "remove everything".

When choosing "just remove my files", winre starts to decrypt the bitlocker volume at ~98%.

Hard resetting (hard power off / power on) here will reboot back into WinRE and show an error.

Clicking OK on the error will cause a reboot back to the OS, and starts windows setup which shows an "upgrade" screen.

...where Shift+F10 works to get a shell, you can then pause the decryption, remove all key protectors, then dump plaintext VMK, decrypt the FVEK with that, and use that FVEK to decrypt a disk image you made earlier.

This is the *second* time that Shift+F10 in setup to get a shell broke bitlocker.

The fix removes "reset my PC" -> "remove everything" from the list of options that are allowed to start with the osvolume unlocked and without entering a recovery key. (leaving only one in place: startup repair)

Because this is an issue with code running in winre usermode, this affects legacy integrity validation as well as secure boot integrity validation.

#infosec #CVE_2022_41099 #BitLocker

decided to put all public bitlocker attack research I know of (including mine and others) in one place https://github.com/Wack0/bitlocker-attacks

#BitLocker #infosec

lol, MS updated the winre bitlocker bug (note to self: bindiff at some point) FAQ to note that attacker has to use the installed winre, a downgrade attack isn't possible

which is true, but there are other bugs leading to bitlocker bypass where an attacker CAN perform a downgrade attack, so why even bother mentioning it?!

#windows #BitLocker #CVE_2022_41099

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

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

It's been a few months since patch, let's talk about a BitLocker bypass I found. Here's dangerous association, or #CVE_2022_22048

The underlying issue here is an incorrect patch for #CVE_2022_29127

The initial bug was: with legacy integrity validation, FvebpCalculateDataHashes attempts to iterate over all boot options and all associated boot options to hash them (where an authenticated hash is in on-disk BitLocker metadata). However, the list of associated options were walked through incorrectly: the structure uses an offset from the start of structure, whereas the incorrect code added the offset to a pointer in the middle of the structure.

The patch for #CVE_2022_29127 did fix this error, but there was another fail:

When looking for a boot option, the boot environment recursively walks associated options lists; FvebpCalculateDataHashes would only hash one level of associated options. This means that associated options on the second level or deeper are invisible to BitLocker legacy integrity validation (and when used will not force BitLocker into recovery mode).

Associated options are only used by device elements, and in Windows 8 and above, one device element (osdevice) is allowed without being hashed (because osdevice describes the partition with integrity validation being checked).

Therefore, attacker could create two device boot entries, configure the osdevice to use the first one as associated options, add the same osdevice there using the second one as associated options and set debug=on in the second one. The system would boot with kernel debugging enabled, attacker could then connect to the kernel debugger and dump the bitlocker keytable.

I'm assuming Secure Boot is disabled here, for which legacy integrity validation would be the default. If legacy integrity validation is used with Secure Boot enabled (not default, but what I recommend, Secure Boot integrity validation is broken), and PCR 7 is used when sealing the VMK (also not default, but again what I recommend), it should be possible to chain with baton drop if the system is also vulnerable to that.

No easy PoC today, but this is enough information you need to do it yourself.

When using BitLocker, do NOT use the default settings. Instead, use legacy integrity validation configured for PCRs 0,2,4,7,11. This ensures that an attacker needs to find an exploitable bug in the version of bootmgr, winload or winresume on your system, and can't just use a downgrade attack or find a bug in some other lesser known boot application to dump bitlocker keys.

"Automatic BitLocker" is security theatre. That there were reports of actual data loss after the last dbx update is inexcusable.

timeline:
2022-05-11: discovery, report to MSRC
2022-06-15: reproduced by MS
2022-06-23: initial fix in Windows Insider Preview build 25145
2022-07-12: wide release of fix
2022-12-01: disclosure

#1day #BitLocker #exploit #vulnerability #infosec

@volpeon ah, so you had a dream about #Microsoft #BitLocker... 😹

:dumpsterfire: :blobcat_thisisfine: :oh_no_bubble: