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

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