3 ms·

From: https://infosec.exchange/@wdormann/116565129854382214 https://infosec.exchange/@wdormann/116565129854382214 >In a normal WinRE session, you have a X:\Win

From: https://infosec.exchange/@wdormann/116565129854382214 https://infosec.exchange/@wdormann/116565129854382214 >In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it >However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE Interesting. I dont know about this environment - some kind of naive file handle contructing/passing? But then, why require a key press during winre reboot? I wonder how patachable this is. The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc? Seems like lots more to follow

gruez 4mo ago
>The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc? The part that isn't mentioned is that the win re is privileged because windows stores a decryption key in the TPM that allows win re to decrypt the disk even without the recovery key. That's why the attack requires win re in the first place, rather than booting into an ubuntu live cd or whatever. This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks.
- steve1977 4mo ago
  Then I guess it is fair to call this a backdoor indeed.
- bri3d 4mo ago
  > This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks. WinRE runs internally, not from a thumb drive, which is why the bootloader will unseal the disk for it (just like if you have a systemd recovery set up on a Linux distribution). It doesn't have a separate key or anything, it's just allowed to use the "main" one, by design. Microsoft just need to patch the WinRE partition in a normal Windows Update to fix the NTFS transaction log driver; no Secure Boot revocation or TPM-related changes are necessary (which is good for them, because _that_ would be a disaster). By and large this whole thing is orthogonal to BitLocker overall; boot-time unsealed BitLocker is vulnerable to any post-bootloader auth bypass by design, and this is a goofy post-bootloader auth bypass bug.

gruez 4mo ago

>The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc? The part that isn't mentioned is that the win re is privileged because windows stores a decryption key in the TPM that allows win re to decrypt the disk even without the recovery key. That's why the attack requires win re in the first place, rather than booting into an ubuntu live cd or whatever. This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks.

steve1977 4mo ago
Then I guess it is fair to call this a backdoor indeed.
bri3d 4mo ago
> This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks. WinRE runs internally, not from a thumb drive, which is why the bootloader will unseal the disk for it (just like if you have a systemd recovery set up on a Linux distribution). It doesn't have a separate key or anything, it's just allowed to use the "main" one, by design. Microsoft just need to patch the WinRE partition in a normal Windows Update to fix the NTFS transaction log driver; no Secure Boot revocation or TPM-related changes are necessary (which is good for them, because _that_ would be a disaster). By and large this whole thing is orthogonal to BitLocker overall; boot-time unsealed BitLocker is vulnerable to any post-bootloader auth bypass by design, and this is a goofy post-bootloader auth bypass bug.