That's what this is about. Microsoft doing bad security practices while trying to get away with it, leading to this outcome.
The researcher also claims to have another version ready which allows to also bypass TPM+PIN via a similar backdoor, which I'm inclined to believe.
Why do I believe that? 5 ring 0 zero days within 3 months are so statistically unlikely to be found, by the same person, in such a short time. Whoever this person is really knows their exploits, and must be in the league of Juan Sacco.
so I call bullshit on the PIN bypass
https://post-cyberlabs.github.io/Offensive-security-publicat...
https://blog.scrt.ch/2024/10/28/privilege-escalation-through...
Yes, the PIN is entangled with the key material.
This means it's vulnerable to an offline bruteforce attack to derive the PIN.
So it's still doable, even in an automated fashion, just slower.
With today's multi-GPU cloud systems available to everyone with a credit card, you can probably crack the default-length 6-digit PIN the same day you extract the key protector.
> The article shows that the PIN-entangled key material can still be downloaded directly from the TPM.
Not exactly, the TPM has PolicyAuthValue(PIN), so the PIN also needs to be provided to the TPM to unseal the material, and the hardware anti-hammering should prevent brute forcing it this way. The blog post documents dumping the PIN-entangled key material by MITM-ing the TPM communication while a user enters the PIN; the entanglement is a belt-and-suspenders approach.
Where are you seeing that? I can't find it in the article.
It wouldn't make sense to me for that to be the case if the article details how the driver does it own unwrapping/decryption after the KP is extracted. Plus it would probably mean they're lying about TPM+PIN being defeatable.
> The blog post documents dumping the PIN-entangled key material by MITM-ing the TPM communication while a user enters the PIN
I really don't think so... the screenshot with the PIN entry I think was only for hooking his debugger up in order to reverse the driver's decryption process. I don't see where they mention how/when the KP is actually extracted. It looks to me like it's transmitted during boot _before_ the PIN entry, so that the software driver can decrypt it after the user enters the PIN.
They list the steps as:
1. Extract TPM data. The TPM data is encrypted Key Protector (aka KP).
2. Generate the decryption key of KP
3. Decrypt KP
4. Extracting encrypted VMK
5. Decrypt VMK using KP
I didn't see anything about needing to enter a PIN in order to get the TPM data.
If the TPM required a PIN to extract anything, I think there would be no need to manually decrypt anything in software as they show with the python code.
Of course I could be wrong... please feel free to provide more info.
Like I specifically pointed out, it's belt and suspenders.
> Of course I could be wrong... please feel free to provide more info.
From https://blog.scrt.ch/2024/10/28/privilege-escalation-through... :
> Indeed, by analysing the decryption process, 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.
> Secondly, no data is returned when the PIN is incorrect, which indicates that the PIN or a derivative is sent to the TPM for verification.
Now I have to wonder if the exploit author's definition of "it works with a PIN" is simply "it works if you enter the correct PIN" and just somehow left out that important detail... I don't know. Perhaps everyone is just guessing that they meant it's possible to exploit without knowing the PIN at all.
I suppose they could be lying too, but I would hope they would be smarter than that given their apparently successful track record /shrug
Belt and suspenders = the industry standard term for "you have one protection you rely on, you add a second that should help." Stuff like ASLR, for example. Or in this case, the stretched key material. The belt is the TPM PIN anti-hammering, the suspenders are the key stretch / entanglement.
> Perhaps everyone is just guessing that they meant it's possible to exploit without knowing the PIN at all. I suppose they could be lying too, but I would hope they would be smarter than that given their apparently successful track record /shrug
Trusting the word of exploit developers, especially random anime avatars on GitHub, is always a bad idea no matter the recent track record. Self promotion is very powerful in the security industry and every claim deserves independent research; that's at least half of the original point I was trying to make about conspiracy theories.
Personally, I suspect the exploit author had a disk with multiple enrollments in addition to the TPM + PIN one, and broke a parallel strategy.
So true.
I don't remember which updates triggered it, but that was September 2015.
From the perspective of the TPM, I have now learned that it is required for it to release the key.
Perhaps those updates didn't really reboot in the traditional sense. If you turn the machine fully off and then back on, and it still doesn't ask for a PIN... now you have my attention.
A USB stick containing a masterkey to decrypt a bitlocker volume is literally the definition of a backdoor.
Go on, try it out. It works.
thats an LPE, not an encryption backdoor
the USB stick doesnt decrypt bitlocker, it just gives you root after bitlocker was AUTOMATICALLY decrypted
Someone else claimed this doesn't affect people who actually care about security and enable boot-time password protection.
> thats an LPE, not an encryption backdoor
No. RedSun and Bluehammer were LPEs
> the USB stick doesnt decrypt bitlocker, it just gives you root after bitlocker was AUTOMATICALLY decrypted
No, that's not what the bypass does. Maybe go try it out and verify it before you come to your quickly made conclusions?
It's not tied to "automatically decrypted" volumes, whatever that would imply for your setup requiring a pretty pointless TPM keystore for that.
If your case were true, it would also imply that any bitlocker cryptography never really worked because it was automatically decryptable without the need for a password/hash/whatever to get your keys from the keystore, which actually makes it so much worse. Even worse than the previously known coldboot attacks.
How could anybody besides a Microsoft employee, given the appearance of this bypass technique?
In the default BitLocker configuration, Windows puts all the key material in the TPM, locked behind the usual trusted-boot stuff: known-good BIOS hashes the bootloader and tells the TPM, bootloader hashes the kernel and tells the TPM, kernel hashes the initial process and tells the TPM, (I’m not sure how far it goes in this specific application,) and at the end of it the TPM won’t release the keys unless the entire chain was correct. This process does (modulo TPM flaws) ensure the disk will only be decryptable when in the original computer running the original OS. It does not ensure that the original OS will not subsequently give a root shell to anyone who walks up to the keyboard and types in a cheat code, and that’s essentially what’s happening here.
Celebrite et al. take a similar approach: after your Android phone boots and you first enter your PIN (which, unlike with BitLocker defaults, is required to unlock the TPM, thus the distinguished status of “before first unlock” aka BFU vs “after first unlock” aka AFU), the key material is already in RAM and breaking dm-crypt is not necessary; all that’s needed is find a USB stack vulnerability or a Bluetooth stack vulnerability or whatnot that can be leveraged into a root shell.
Agreed that the default Bitlocker config is much less secure than having a PIN at boot time due to the amount of code that gets run.
Back in the windows 7 days you could stick a windows installer CD in and press Shift+F7 or something and get a system command prompt with the drive unlocked.
Surely when someone said 'we're gonna let the installer unlock bitlocker' they immediately thought 'That means the whole installer needs to be as secure as the login screen' right? Seemingly not.
On my birthday iirc once long time ago I think in 5-6th class not sure, my brother gave me his laptop, I wanted to do python but python wanted admin password on windows to install properly. So what I did was I dont even remember how, but download one operating system which could then crack the windows password so that I can set new and I used that to then set a new password to then install python. to then only print hello world :D (I think only because one of the cousins I really admire mentioned that he made 2k loc of python once and I thought during that time, python is the endgame). We are talking about windows 7 but I think that windows 10 security must've gotten better. So these are some things that I have done, I wouldn't call it coding as much as tinkering but I love doing these things from as long as I can remember :D
I just remembered this paragraph from one of the comments that I had written sometime ago, source: https://news.ycombinator.com/item?id=47663383
Which really annoyed me. Desktops don't need encrypted drives.
- The feds show up
- A bugular breaks in and grabs your computer
- You're selling your house and host an open house
- You have curious children and want to keep them from live booting and reading your tax returns
What? Most Linux distributions don't even enable FDE by default, and even when they do, they frequently use the exact same system as BitLocker (automated unlock sealed to TPM PCRs) with the exact same vulnerabilities (any signed OS image with a postboot authentication bypass gets you the disk content, as does any method for inspecting the state of system memory). This is an architectural tradeoff you can make on any platform and has nothing to do with "lock in."
It's straightforward to configure BitLocker disk encryption to be more secure, but it creates enormous headaches for admins, so they don't do it.
I do think that Apple have some better security defaults for FileVault ("enabling" FileVault basically consists of wrapping the existing hardware UID entangled key with the user's password as well) but this strategy does create big issues with remote password rotation or delegated authentication (ie, Active Directory), which is probably why Microsoft don't choose it as a default.
Do they? Any time I've done FDE it's always been luks with a password, I've never seen one go for TPM by default!
I've only recently implemented luks+TPM on a personal laptop (and that was a PITA to do).
I didn’t find it too difficult to set up TPM backed encryption on Arch using systemd-cryptenroll for my home server, although for anything I use interactively I just use a passphrase instead.
If this is a fed mandated backdoor, I guarantee Microsoft/Windows isn't the only one either, they are just the only/first ones to get caught. I'd be suspicious about every single commercial, closed source operating system or encryption product in the US right now.
It also doesn't help this comes from a person who likely was close to the development at Microsoft (one way or another) as their recent disclosures are quite alarming.
Of course, this could technically be the stars aligning type bug, but it seems like a purposefully planted backdoor to me.
Which leaves an enormous attack surface. If you can break Windows before logging in, you can effectively bypass bitlocker.
"Windows loads some file in System Volume Information automatically" is not evidence of a backdoor. And you have to put specific exploit files in there to turn this into an attack. You don't just make the folder.
It's still possible this is a backdoor, I guess, but there's nothing as blatant as you're implying.