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