The last year and change:
Linux - We’ve made a range of free to use operating systems more streamlined and user friendly across the board and gotten over hurdles so that you can have a ready to go open source gaming PC that runs everything other than trash ass games better than windows, with minimal hardware requirements, with no extra steps after install other than some updates, including being able to play old games designed specifically for windows that can’t be played on their modern OS. This is all completely free and you have complete ownership over your operating system.
Microsoft - Give us money for this spreading cascade of dumpster fires or you can’t touch our things. We can also do whatever the fuck we want with OUR operating system at any time and if you do something we don’t like we will delete everything and take away your ability to use your PC. That might also just happen even if you follow all of our demands. We are actively collecting your data and activity for government entities. Every menu also has ads and spying software. And if your computer isn’t new then you can go fuck yourself altogether. Fuck you.
I really could not have chosen a better time to change my OS.
Install Linux, Problem Solved.
This is not a fix for this backdoor. This is a band aid to keep normals out, nothing more.
TPM only keys was always stupid. If you don’t type a password to decrypt on boot, you don’t have security.
This exploit does not affect you if you decrypt with a password.
Problem is that it’s not only on boot. It’s any time the TPM is read. So also sleep and hibernation. Also dude is claiming he broke that too.
Slut !
lol
Microsoft:
In the meantime, Microsoft recommends changing BitLocker’s configuration on encrypted devices from TPM-only mode to TPM+PIN mode using PowerShell, the command line, or the Control Panel. This adjustment requires a pre-boot PIN to decrypt the drive at startup and is expected to block YellowKey attacks.
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.
And as response to this:
“Microsoft is aware of a security feature bypass vulnerability in Windows publicly referred to as “YellowKey”. The proof of concept for this vulnerability has been made public violating coordinated vulnerability best practices.”
They posted:
Saying that I violated CVD best practices is a defamation of my personal reputation, you already told me you will defaming me and doing it in public will not help dissolve this conflict. You intentionally revoked my access to my MSRC account that I used to report vulnerabilities to you, when I asked you, you went ahead and completely wiped the account from existance despite multiple attempts from asking for an explanation. All of those requests went unanswered by the MSRC leadership.
I’m taking your statement very personally.
I have to say, i’m a fan.
Edit: The story so far would probably be well suited for an anime adaption. I hope we learn someday what shit MS pulled to make our friendly neighborhood security researcher so pissed that they started a one-person-crusade against one of the largest IT companies in the world.
Even better, they posted this last week:
After re-investigating the technique used in GreenPlasma (specifically SetPolicyVal), it turns out cldflt!HsmOsBlockPlaceholderAccess is still vulnerable to the exact same issue that was reported to Microsoft 6 years ago. I’m not taking full credit for this, James Forshaw from google project zero found the vulnerability and reported it to Microsoft and was supposedly fixed as CVE-2020-17103.
However, a research who’s a friend of mine pointed out that the routine might still have a vulnerability, which is something I considered but brushed off because I thought it was impossible for Microsoft to just not patch this or rollback the patch.
After investigating, it turns out the exact same issue that was reported to Microsoft by Google project zero is actually still present, unpatched. I’m unsure if Microsoft just never patched the issue or the patch was silently rolled back at some point for unknown reasons. The original PoC by Google worked without any changes.
https://gitlab.com/nightmare-eclipse
https://deadeclipse666.blogspot.com/
Edit: Microsoft deleted the github, updated link to new gitlab repo
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.
That clarification of yours is massively important
I think my mistake was assuming I was on a security related community, where this would be understood, instead of PC masterrace.
Your initial comment sounds as if there is a PoC from Canada on how to circumvent the PIN for the Bitlocker keys.
It’s a meme joke, referencing this: https://knowyourmeme.com/memes/she-goes-to-another-school
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.
Seems unlikely.
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.
Pray they don’t backdoor it again.
Of course they will. That’s why the actual “fix” will be in the next update. They first have to build a new backdoor before the old one is really closed.
Corpo software will ALWAYS have backdoors.
Can’t have those disgusting, smelly peasants locking their betters out of their home computer now, can we?
Bet the fix will push down an obfuscated binary that includes the new backdoor
That’s not fair this could just be vibe coding there’s no way to know you know ms dogfoods copilot requires everyone code
The exploit has existed in Windows systems since before vibe coding was a thing. So it’s 100% an intentional backdoor in BitLocker that someone found.
This is what it looks like if lawmakers are allowed to pass legislation forcing back doors in encryption…but worse because it wouldn’t be just Windows.
Vibe coded operating system what could go wrong
Vibe coding did not exist when this was put it in.
Oh then yes back door no other explanation plus them being very sus
I think this is pretty straightforward, they put in a backdoor and someone found it.
And they either put it back or said they removed it and didn’t why does anyone still use windows
Most business software is made for Windows only. Pretty much every single person uses a Windows PC at work. My fucking workstation is a Windows PC, it is unavoidable.
Its very avoidable lots of stuff is made for windows works on Linux or has functional alternatives
Lots of stuff does, but not everything. You need to move 100% of your tech stack over, not 95%.
Someone with tokens to burn at work try and vibe code the PIN version. It’s not that complicated. Fight slop with slop.
