[JeremyNT]

I'm not a Windows expert but based on my understanding of how MS does this, something doesn't add up here.

If you use bitlocker in the default, insecure way, where the TPM is configured to hand the decryption keys over to the enrolled Windows environment automatically, you can just get an LPE to access the running Windows environment after it boots. That's what I think the published exploit does. It really isn't even related to bitlocker itself, right?

AIUI, TPM+PIN should actually mean the TPM itself cannot release the keys because the PIN hash is actually part of the key material.

So what would a TPM+PIN exploit even look like?

[ranger_danger]

> you can just get an LPE to access the running Windows environment after it boots

Or if you have physical access, you can probe the TPM chip with a SPI decoder to get the key directly: https://post-cyberlabs.github.io/Offensive-security-publicat...

Another method is via PXE (still not patched on most systems apparently): https://github.com/andigandhi/bitpixie

> TPM+PIN should actually mean the TPM itself cannot release the keys

It does release the (wrapped) key actually (the above cyberlabs link explains it), it's just that the KP data this time has additional layers of encryption that are based on the PIN, which is decrypted in software after the fact. This means you can crack it offline. With the default minimum of 6 digits you can probably bruteforce it within a day.

If you're paranoid I might suggest switching to a full password-based pre-boot auth option instead of the PIN.

[HHad3]

This article is probably not correct. The actual behavior is documented [1]:

> BitLocker hashes the user-specified personal identification number (PIN) by using SHA-256, and the first 160 bits of the hash are used as authorization data sent to the TPM to seal the volume master key.

So what's actually happening is that the PIN is used to derive an authValue passed to the TPM, which compares it to the expected value, and can trigger lockout on too many mismatches.

I can't find specifics to how Windows configures the TPM wrt. lockout, but the mechanism described in the article appeared fishy to me, and contradicts official docs. It also would not make sense that TPM+PIN was known to be safe against bus sniffing attacks if it would still reveal all data required to brute-force the PIN.

[1] https://learn.microsoft.com/en-us/windows/security/operating...

[ranger_danger]

I was given this article after posting the previous one elsewhere:

https://blog.scrt.ch/2024/10/28/privilege-escalation-through...

This one does say "it appears that the user’s PIN is sent to the TPM which releases the intermediate key only if the provided secret is correct, thus effectively preventing offline bruteforce attacks."

Given this, I can't see how it would be possible for anything like YellowKey to work on a cold booted TPM+PIN system without someone already knowing the PIN.

Perhaps when the exploit author said "it works with PIN" they meant "it works if you enter the correct PIN"... or they are just lying. I'm not sure.

[JeremyNT]

Thanks, that fills some gaps I had in understanding.

So this person's claim to have a TPM+PIN attack might imply they are able to use the same LPE to get a (PIN-encrypted) key from the TPM then they can simply brute force?

[panflute]

The usual attack is in a usability feature to prevent lock out. Looking at the instructions for setup I see Bitlocker recovery code if you forget your pin.. (How does that alternative work, what are other alternative unlocks if firmware hash changes, etc, etc..)