Hacker News new | ask | show | jobs
by AnonC 33 days ago
The BitLocker exploit seems simple and very dangerous. Companies and individuals have been relying on BitLocker to protect information if the device is lost. Despite promises, Microsoft doesn’t seem to be serious about security.

What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?

5 comments

Note that RedSun and Bluehammer were silently patched, with no response to the CVEs by Microsoft, and not accrediting the researcher's work.

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.

the only way to bypass PIN would be an actual backdoor in Bitlocker. no way around that. an actual backdoor in microsoft encryption was never documented, and there are Snowden documents showing FBI pressing Microsoft into introducing one and Microsoft refusing

so I call bullshit on the PIN bypass

You're assuming the PIN was ever connected to the key itself in the first place. We don't know how that mechanism works, it could just be a totally separate gate that IS bypassable.
We can just do research to figure that out? The recent trend towards conspiracy theories against things that are trivially discoverable is so frustrating.

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.

The article shows that the PIN-entangled key material can still be downloaded directly from the TPM.

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.

I'm glad we were able to move past "We don't know how that mechanism works, it could just be a totally separate gate that IS bypassable" and into the actual way the mechanism works!

> 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.

> The recent trend towards conspiracy theories against things that are trivially discoverable is so frustrating.

So true.

I've watched my work laptop reboot in the middle of installing Windows Updates without prompting me for a Bitlocker key. It seems obvious to even the casual observer that the pin isn't always required.

I don't remember which updates triggered it, but that was September 2015.

> the pin isn't always required.

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.

Bitlocker can be "paused", which really means the key is written unprotected to disk. This can be done by the user, but also happens temporarily during updates that would change bootchain measurements, because those measurements are used by the TPM to decrypt the key (hence changing them would make the key undecipherable).
> the only way to bypass PIN would be an actual backdoor in Bitlocker. no way around that. an actual backdoor in microsoft encryption was never documented, and there are Snowden documents showing FBI pressing Microsoft into introducing one and Microsoft refusing

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.

no, to access a bitlocker volume which automatically decrypts

thats an LPE, not an encryption backdoor

the USB stick doesnt decrypt bitlocker, it just gives you root after bitlocker was AUTOMATICALLY decrypted

Smells like a compromise. Microsoft enables BitLocker by default, thus protecting companies and users at scale. But the price is a backdoor they hope noone finds.

Someone else claimed this doesn't affect people who actually care about security and enable boot-time password protection.

> no, to access a bitlocker volume which automatically decrypts

> 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.

its pretty obvious you have no idea how bitlocker works, and its various modes - TPM only, TPM+PIN, PIN only
Microsoft has never seemed to treat bitlocker seriously.

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.

> 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.

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

Seriously enough to make it turned on by default.

Which really annoyed me. Desktops don't need encrypted drives.

Why not? Here are some scenarios where you may want protection:

- 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 will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?

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.

>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)

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).

Ubuntu does this with Hardware Backed Encryption option in the installer, which I think they’re trying to move up the list (it’s already the default in Ubuntu Core, which makes sense for that application).

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.

I've not seen a Linux system using a TPM to unlock encrypted drive(s). When I enable it on laptops etc, I have to manually enter the passphrase.
How does a bug equate to "not serious about security"?
There's no way this is not a backdoor
Given that the other two vulns were silently patched, no CVE, basically screams this is a backdoor.

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.

Along with other facets of this, what are the odds a "bug" would also automatically erase evidence of itself from the bootable USB stick when it activates?
If it's replaying a filesystem transaction like others have said, I can see where it makes sense to erase the files afterwards. You don't want the same transaction replayed twice.
The blog author calls it that but given there’s no root cause yet it’s foolish to jump to conclusions.
The basic design of the most common mode of operation for bitlocker, where the TPM hands over the deception keys to the drive when Windows boots without requiring a PIN or anything, indicates how unserious they are.
Third paragraph of the article does make it sound like a simple backdoor planted there