Chaotic Eclipse posted the following with the disclosure of Yellowkey:
Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I’m just not publishing the PoC, I think what’s out there is already bad enough.
Additional info:
The YellowKey is caused by the binary “autofstx.exe” which propagates all present volumes for transaction files, a researcher (unsure if they want to be named) told me that this binary is also present in windows update WinRE images and I think they will definitely have the same vulnerability as well. However, I’m unsure if it’s possible to trigger the controlled file deletion when windows is updating. If it’s true, then it means disabling WinRE is not a solution for the problem, which also means it’s a good thing that I kept the PIN+TPM PoC a secret.
Would you happen to have a source link for those claims? I’d like to forward them to a few organisations I work with, warning them that devices currently lost/stolen/left unsupervised despite having TPM+PIN configured will have to be considered compromised even if a future patch comes out.
Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I’m just not publishing the PoC, I think what’s out there is already bad enough.
The PoC for that goes to another school, in Canada.
Edit:
Downvoters don’t understand the nature of this exploit.
Without PIN, the windows recovery software has full access to the encryption keys in the pre-boot environment. So to crack bitlocker in this case, a hacker only needs to find a bug in the WRE to get at the keys. => That’s the Yellowkey exploit.
With a PIN, no Windows or Microsoft program has access to the bitlocker encryption keys until the PIN is provided, and it can’t be brute forced because the TPM protects against that. To exploit that, would require a attack on the TPM hardware itself, which would be absolutely massive if he could pull this off through software only and of a completely different nature than the Yellowkey exploit. It also wouldn’t have anything to do with Microsoft software, because it wouldn’t be in the loop for this.
To use an analogy: Yellowkey is like beating a bank employee (the WRE) who knows the combination to the safe with a wrench until he gives you the combination. In an attack with a PIN, the bank employee doesn’t know the combination himself, so you can beat him with a wrench as much as you like, he’s not going to give you anything useful.
Extraordinary claims require extraordinary evidence, and he has provided none. Furthermore, he has a bone to pick with Microsoft over a denied bug bounty, so he clearly has a motif to undermine trust in Microsoft products like bitlocker. All this, and knowing the typical hacker personality, leads me to believe that this is pure bluff. If he had something, he would show it.
That clarification of yours is massively important. Your initial comment sounds as if there is a PoC from Canada on how to circumvent the PIN for the Bitlocker keys.
Maybe that’s why you got downvoted?
I agree the “security researcher” sounds bitter, but also they found a proven critical backdoor, so it’d be negligent to just ignore their comment about circumventing the PIN. And the only way they could put microSLOP at fault for that would be if they could find that microSLOP was backing up encryption keys in the recovery environment / boot files somewhere.
the only way they could put microSLOP at fault for that would be if they could find that microSLOP was backing up encryption keys in the recovery environment / boot files somewhere
Seems unlikely. The WRE is like 32MiB in size, and most of that consists of static binaries. Not much info is saved there, except for some log files. If the bitlocker keys were there, they would have already been found by someone else.
it’s the second link, https://deadeclipse666.blogspot.com/ - The entry is from May 13, titled “We’re doing silent patches now huh, also a quick note about YellowKey”, the second part is from May 14, titled “Important updates regarding YellowKey and GreenPlasma”. They are the one who found the vulnerabilities, PoC for RedSun, BlueHammer, YellowKey, GreenPlasma and MiniPlasma are on Gitlab @ https://gitlab.com/nightmare-eclipse
Thank you - it appears I stopped reading just one comment short of that, assuming that the “TPM+PIN is insecure” was a new comment, and not expecting it deeper down in the past.
Would you happen to have a source link for those claims? I’d like to forward them to a few organisations I work with, warning them that devices currently lost/stolen/left unsupervised despite having TPM+PIN configured will have to be considered compromised even if a future patch comes out.
The PoC for that goes to another school, in Canada.
Edit:
Downvoters don’t understand the nature of this exploit.
Without PIN, the windows recovery software has full access to the encryption keys in the pre-boot environment. So to crack bitlocker in this case, a hacker only needs to find a bug in the WRE to get at the keys. => That’s the Yellowkey exploit.
With a PIN, no Windows or Microsoft program has access to the bitlocker encryption keys until the PIN is provided, and it can’t be brute forced because the TPM protects against that. To exploit that, would require a attack on the TPM hardware itself, which would be absolutely massive if he could pull this off through software only and of a completely different nature than the Yellowkey exploit. It also wouldn’t have anything to do with Microsoft software, because it wouldn’t be in the loop for this.
To use an analogy: Yellowkey is like beating a bank employee (the WRE) who knows the combination to the safe with a wrench until he gives you the combination. In an attack with a PIN, the bank employee doesn’t know the combination himself, so you can beat him with a wrench as much as you like, he’s not going to give you anything useful.
Extraordinary claims require extraordinary evidence, and he has provided none. Furthermore, he has a bone to pick with Microsoft over a denied bug bounty, so he clearly has a motif to undermine trust in Microsoft products like bitlocker. All this, and knowing the typical hacker personality, leads me to believe that this is pure bluff. If he had something, he would show it.
That clarification of yours is massively important. Your initial comment sounds as if there is a PoC from Canada on how to circumvent the PIN for the Bitlocker keys.
Maybe that’s why you got downvoted?
I agree the “security researcher” sounds bitter, but also they found a proven critical backdoor, so it’d be negligent to just ignore their comment about circumventing the PIN. And the only way they could put microSLOP at fault for that would be if they could find that microSLOP was backing up encryption keys in the recovery environment / boot files somewhere.
I think my mistake was assuming I was on a security related community, where this would be understood, instead of PC masterrace.
It’s a meme joke, referencing this: https://knowyourmeme.com/memes/she-goes-to-another-school
Seems unlikely. The WRE is like 32MiB in size, and most of that consists of static binaries. Not much info is saved there, except for some log files. If the bitlocker keys were there, they would have already been found by someone else.
That’s what I’m saying. Not impossible though to hide key weakening info somewhere.
it’s the second link, https://deadeclipse666.blogspot.com/ - The entry is from May 13, titled “We’re doing silent patches now huh, also a quick note about YellowKey”, the second part is from May 14, titled “Important updates regarding YellowKey and GreenPlasma”. They are the one who found the vulnerabilities, PoC for RedSun, BlueHammer, YellowKey, GreenPlasma and MiniPlasma are on Gitlab @ https://gitlab.com/nightmare-eclipse
Thank you - it appears I stopped reading just one comment short of that, assuming that the “TPM+PIN is insecure” was a new comment, and not expecting it deeper down in the past.