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?
londons_explore 10 hours ago [-]
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.
Imustaskforhelp 8 hours ago [-]
> 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
Which really annoyed me. Desktops don't need encrypted drives.
hellojesus 6 hours ago [-]
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
bri3d 4 hours ago [-]
> 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.
cookiengineer 14 hours ago [-]
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.
aiscoming 14 hours ago [-]
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
ranger_danger 8 hours ago [-]
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.
bri3d 5 hours ago [-]
We can just do research to figure that out? The recent trend towards conspiracy theories against things that are trivially discoverable is so frustrating.
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.
bri3d 2 hours ago [-]
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.
pregnenolone 4 hours ago [-]
> The recent trend towards conspiracy theories against things that are trivially discoverable is so frustrating.
So true.
cookiengineer 14 hours ago [-]
> 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.
aiscoming 14 hours ago [-]
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
stephbook 14 hours ago [-]
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.
cookiengineer 14 hours ago [-]
> 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.
aiscoming 13 hours ago [-]
its pretty obvious you have no idea how bitlocker works, and its various modes - TPM only, TPM+PIN, PIN only
cookiengineer 13 hours ago [-]
> its pretty obvious you have no idea how bitlocker works, and its various modes - TPM only, TPM+PIN, PIN only
How could anybody besides a Microsoft employee, given the appearance of this bypass technique?
mananaysiempre 10 hours ago [-]
Linux can decrypt BitLocker-encrypted drives. The cryptography is known and solid. The issue is that, as 'aiscoming says, its surroundings in Windows make the quality of the cryptography irrelevant.
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.
ndiddy 7 hours ago [-]
Note that Microsoft did take the “Linux can decrypt drives in TPM-only” scenario into account. If any UEFI settings are changed related to stuff like boot order, the computer is supposed to see that the settings have changed and require the recovery password to unlock the volume. Knowing the quality of vendor firmware implementation, I’m not sure how well this works in practice.
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.
ranger_danger 16 hours ago [-]
How does a bug equate to "not serious about security"?
navigate8310 16 hours ago [-]
There's no way this is not a backdoor
Terr_ 14 hours ago [-]
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?
ranger_danger 5 hours ago [-]
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.
JeremyNT 8 hours ago [-]
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.
forestry 16 hours ago [-]
The blog author calls it that but given there’s no root cause yet it’s foolish to jump to conclusions.
Our_Benefactors 16 hours ago [-]
[flagged]
HDBaseT 15 hours ago [-]
It seems undeniably a backdoor, why on earth would a very specific folder/file name and a specific boot combination just "magically" open up an encrypted drive.
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.
Dylan16807 14 hours ago [-]
Just booting opens up the encrypted drive. Windows gets the key out of the TPM.
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.
forestry 16 hours ago [-]
*in your opinion.
1 hours ago [-]
Our_Benefactors 6 hours ago [-]
This is a bad faith comment. Both positions are an opinion.
stogot 7 hours ago [-]
Third paragraph of the article does make it sound like a simple backdoor planted there
rustyhancock 11 hours ago [-]
Crikey, it seems that the big news - a backdoor is somewhat burried.
It also strikes me that these are several very high value (all but one complete) exploits.
Surely the value of these on the market would be astronomical and best suited to law enforcement agencies using unlock as a service businesses.
So I have to say I applaud the open disclosure
mylastattempt 11 hours ago [-]
Though I am convinced this is intentional, i.e. a backdoor and not a bug, it should be noted that for goverment agencies there was already access anyway:
Access for those who used a Microsoft account and upload their encryption keys there. While I’m unhappy that most of the users end up using this (bad) mode, previously I was under the impression that there was a meaningful choice involved.
manwe150 8 hours ago [-]
Microsoft has ensured the alternative is nearly impossible, constantly working to block any workarounds that users discover to use a local-only account. And it will even going so far as to silently reset the master recovery key if the original key couldn’t be uploaded (my coworker discovered this to his horror when finding out that not only had it changed his failsafe recovery key again, but also uploaded the wrong key to MDM—all data simply lost)
ac29 5 hours ago [-]
> Microsoft has ensured the alternative is nearly impossible, constantly working to block any workarounds that users discover to use a local-only account.
Local accounts still work fine for Win 11 Pro, I installed it a few days ago using a clean ISO directly from Microsoft. No special patching or command line stuff needed, making a local account is part of the official install process.
manwe150 2 hours ago [-]
Did they make it better recently? There's plenty of blogs explaining why Microsoft wanted this to be increasingly difficult last year. Just from quick google:
Yes it does seem prudent to encrypt those keys some other way on the cloud and not add them to the clouds accessible keys.
They also seem suitable for using a secret sharing scheme.
I have Microsoft authenticator requests all day every day. Using aliases has helped but somehow they continue. It's only a matter of time before somehow accidentally I approve.
Which has simply led to me not putting anything of high value in my Microsoft account and not using it for my email.
willis936 10 hours ago [-]
This happened to me too. The only solution I found was to disable authenticator on the account. Their implementation actively makes accounts less secure.
himata4113 13 hours ago [-]
bitlocker is generally useless unless the hardware is secure to begin with and while we have tons of 'boot guard' implementations which fuse the certificate into hardware meaning that only the OEM can create firmware that will boot there have been at least 2 instances of these certificates leaking exposing all hardware with that signature and other bypass methods (some boot guards are 'flash' guards were you can only flash signed firmware, but doesn't stop you from directly flashing the spi bios chip).
I had someone demo me preserving PCR values by patching SMM module in firmware without triggering any bitlocker lockout, this also means that you can externally write bios with the smm module as long as you have ~2 minutes to disassemble the laptop or desktop and flash firmware.
This hurts the most when you don't have PIN authentication which means you just need to steal the laptop to exfiltrate data, if you do then you have to have the user boot which then drops a payload exfiltrating data over network or just stealing the laptop again as you can write back decryption keys into non encrypted partition or corrupt some sectors at the end of the disk and write them there.
* modifying smm allows you to patch the boot process loading a malicious payload into hypervisor/kernel.
mr_mitm 11 hours ago [-]
It's only useless if you assume a perfectly capable attacker. That's not every attacker, though. We're not always up against a nation state actor, in fact, some attackers are quite dilettante. I believe the assumption that if something doesn't defend against the most capable attacker it's useless and we might as well not bother is not helpful.
I know my bike lock can be cut within seconds by someone who is sufficiently skilled and determined. I'm still going to lock my bike.
himata4113 9 hours ago [-]
law enforcement? stolen bags? state sponsored agents? that's the only times you should be worred and it fails horribly at those.
mr_mitm 8 hours ago [-]
What about employees smart enough to boot a laptop from a thumb drive but not smart enough to disassemble it who just want admin to install some game from a dubious source? What about other scenarios neither you or I can think of right now? The cost of activating bitlocker is so low, I'd do it just in case.
Also, I'd argue the stolen bag scenario usually features dilletante attackers.
HackerThemAll 13 hours ago [-]
> unless the hardware is secure to begin
Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
pregnenolone 9 hours ago [-]
> Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
Oversimplified and not accurate. Some manufacturers had flawed implementations, others did not. Also, that was a long time ago. There are advantages to hardware encryption. It preserves performance and mitigates other vectors like cold-boot attacks without having to encrypt RAM, which also comes with a performance penalty. By the way, both software and hardware-based encryption can be combined. Cryptsetup on Linux actually offers this, and before you ask, the keys are split. If one is compromised, the other remains secure.
izacus 11 hours ago [-]
Do you have any citation about that on SSDs built after 2020?
mananaysiempre 11 hours ago [-]
I don’t think manufacturers with deliberately undocumented, nigh-impossible-to-inspect crypto get to claim their bugs are shallow and thus that the absence of evidence for bugs implies the absence of bugs.
Less emotionally but mostly equivalently, the expense and non-cryptographic skill requirements of breaking mass-storage crypto are quite high while the rewards are comparable to those from breaking much softer targets, so the absence of results since that one paper only changes my mind very slightly. Besides, we know plenty of examples of what these kinds of opaque, serious-business, pay-to-play environments produce: cellular crypto is an uninterrupted series of disasters, so is Wi-Fi, and the things that we do know about storage devices don’t point to an outstanding culture of cryptographic competence there either. Once you’ve done enough to slap an “OPAL” label on it (which says nothing about the internals), there’s just no competitive pressure to improve.
There is a right way to do all this, and it’s essentially what NICs do: allow the host to offload symmetric crypto to the device, but keep the results of said crypto accessible at any moment. And it’s not like there are even that many modes used in full-disk encryption, let alone ciphers.
izacus 10 hours ago [-]
So that's a long way of saying "no, I have no basis for my claims outside deciding that people I know nothing about are not competent", right?
mananaysiempre 10 hours ago [-]
It’s a way of saying that I consider the demand for post-2020 evidence to be cherry picking when there’s evidence from 2018 and little objective (cultural or economic) reason for things to have improved since then. A competent modern businessman will not pay for a competent worker in a very specific narrow field until there are consequences to not doing so (creating such consequences is the purpose of every compliance regime, for instance).
It’s also a way of saying that the entire approach taken by hardware disk encryption (unspecified crypto done inside the device in an unverifiable manner) has, with the benefit of hindsight, proven fundamentally flawed despite its reasonable appearance (in every system which had used it, not just storage), and I wish there was a way to pressure (consumer) storage vendors into going in a different direction. It is simply never a wise choice to trust people’s opaque crypto, however competent they are.
himata4113 13 hours ago [-]
we're not talking about the hdd/ssd here, those are not really encryption but data packing and compression algorithms, they added encryption because it's a single instruction for extra talking points.
you use veracrypt which doesn't have any hardware attestation (convenience) features, but it does still leave you vulnerable to the same surface PIN+TPM is vulnerable to. the real defense is making it so opening your laptop/desktop physically fuses something via latch and wipes the key off your system requiring re-entry.
of course, who wants to own a laptop/desktop that you can't open we have enough of that with our phones.
luke-stanley 3 hours ago [-]
I'm not sure that copying a key after unlocking the system counts as a backdoor? If the OS promises to lock access to the key and fails to do so then I can see the logic that people might then call that a backdoor. But it's different from there being a key bypass, or a pre-shared key (or such), which it seems like the article suggests? For the record, I don't use Windows (so glad).
bri3d 2 hours ago [-]
Right, this is a Windows auth bypass that works with Bitlocker enabled; using TPM-only Bitlocker you are vulnerable to _any_ postboot authentication bypass or memory content extraction technique, this is just a particularly stupid / weird auth bypass technique that has been spun really hard by the author and press.
For what it's worth, any OS using only hardware identity to unseal disk encryption is vulnerable to the same class of attack; there are all sorts of ways to misconfigure or exploit Linux FDE setups to enter a recovery shell as well. It's still a huge step above "no disk protection" (especially since it protects against every scenario where the disk is separated from the hardware), but the postboot surface area is enormous and nobody should be considering this class of protection as much more than a speed bump for a serious attacker.
> (Note: The YellowKey author disagrees that PIN is a protection
jackjeff 14 hours ago [-]
That’s the most puzzling part to me. What’s the point of the PIN then? I was assuming it was mixed with the TPM secret somehow but if it can be bypassed then it shows it just an IF statement somewhere. Dang…
God I hate this stupid design of burying the decryption key in the TPM and hoping the software does not get fooled to reveal it.
Microsoft always sucks. Why don’t you ask for the password at boot time and derive the key from it. So much simpler and makes this kind of attacks impossible. Nobody is going to bypass LUKS or FileVault like this.
solenoid0937 14 hours ago [-]
The amount of trust put into buggy TPM implementations chock full of vulnerabilities has always confused me.
Does anyone really trust these shitty Windows laptop/desktop manufacturers to get these things right? These guys couldn't even get basic hardware features like trackpad drivers right.
ronsor 14 hours ago [-]
Usually the TPM is part of the CPU itself nowadays, so you're mostly trusting Intel or AMD.
Gigachad 14 hours ago [-]
An upgrade from terrible to bad.
DANmode 14 hours ago [-]
They got it right - just not for us.
Borealid 13 hours ago [-]
There are two ways to "use a PIN".
Since there's a ton of misunderstanding in this thread, I'm going to go into how disk encryption works conceptually.
First, there's a symmetric key to encrypt blocks on the disk. Since you want to be able to change your unlocking password/mechanism without re-encrypting everything on the disk, this has nothing to do with unlocking the disk. This is what you want to get BY unlocking the disk. Let's call this the "data encryption key".
Then, there's something you use to encrypt the data encryption key. Let's call this the "key encryption key" (abbreviated KEK from here on in).
When you use a TPM, the KEK is stored inside the TPM. When you use a TPM PIN, the TPM refuses to release the KEK for use by the OS unless that PIN is provided.
You could say "why not make the KEK be a hash-mixed combination of a PIN and something inside the TPM?". One could do that! But that's not how Bitlocker works. There is a reason it doesn't work that way: the TPM is supposed to let company admins in charge of the device access it even if the original PIN is forgotten, by using other policies letting them get at the KEK. I personally set my own devices up such that the passphrase IS part of the KEK itself.
Interestingly, LUKS does not have a composite key mode natively that lets you combine a password with TPM material, but there are some good reasons not to use JUST a password:
1. The strength of your disk encryption reduces to the strength of the password, where a TPM can have a 256-bit truly random key
2. If someone keylogs the password, or tricks you into disclosing it, they can later decrypt your drive from anywhere, where a TPM binds the attack to those with posession of the TPM
3. There is no protection against brute force attacks (rate limiting), where a TPM does - or tries to - impose a rate limit
Now, let's go on to what YellowKey attacks.
A TPM can have inside itself "registers", called PCRs. These PCRs can be updated but not reset - think of it like you can add numbers to them but not subtract, and they only go back to zero when you reboot.
Using a passwordless encrypted boot, the TPM is configured to only release the key when the PCRs are in the exact correct state. As the OS boots it adds numbers to those PCRs. If you boot "the wrong" software, the numbers in those registers won't match the expectations, and you cannot unlock the disk.
Speculation on my part: the reason there's an exploit here is that the Windows Recovery Environment apparently can match the PCR values for the booted OS, causing the TPM to release the key, but WinRE doesn't require you to get your password right before it gives you access to the data. So far as I know, protecting the TPM key with a PIN would mitigate this issue, but it's still bad.
Or maybe the exploit actually does something inside the TPM itself, causing it to unconditionally release the key even when protected by a PIN: that would be even worse, but **NOT*** a problem with Windows. That would be a problem with the TPM.
pregnenolone 10 hours ago [-]
> Since there's a ton of misunderstanding in this thread
True. It's unfortunate, amd a lot of false information being spread there.
> the KEK is stored inside the TPM
That's not how it works. The KEK is not stored inside the TPM, but encrypted/decrypted by the TPM.
> You could say "why not make the KEK be a hash-mixed combination of a PIN and something inside the TPM?".
TPMs are a nice idea, but there are a few problems:
- The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.
- There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.
I seriously doubt the author found a way to bypass PIN protected setups in general. This should only be possible in combination with a vendor/model specific vulnerability. Maybe an fTPM?
As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.
Borealid 7 hours ago [-]
> That's not how it works. The KEK is not stored inside the TPM, but encrypted/decrypted by the TPM.
No, the KEK is stored inside the TPM, and the DEK is decrypted by it. If you have three layers (two KEKs, one encrypted with the other) then sure. But at the end of the day one private key is actually stored inside the TPM, taking up as much space as the length of the key.
To be specific, Bitlocker uses a stored key, not a derived key.
I don't think Bitlocker does that, because it's possible to set up admin PIN recovery techniques. That would be impossible if the PIN were part of the KEK.
> - The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.
I agree.
> There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.
I agree. Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too. There are even open-source implementations of FIDO2 where the key is in fact derived from the user's PIN (plus a stored secret). If you did that, you get the proper security properties even without cryptsetup mixing the two methods.
> I seriously doubt the author found a way to bypass PIN protected setups in general.
I agree - I think the author probably just found a flaw in the windows recovery environment and is talking up how a PIN only helps you if the attacker does not know your PIN (in other words, acting as if the PIN provides no threat resistance when really it provides an additional layer).
> As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.
I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.
pregnenolone 4 hours ago [-]
> No, the KEK is stored inside the TPM
No. Technically, TPMs can store secrets (limited due to little nvram), but no FDE implementation as far as I'm aware does this. TPMs wrap/encrypt the key and return an encrypted blob which will be stored in the header which will be decrypted upon request. The actual KEK is never stored on the TPM.
> Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too.
Not only do they do the same thing, they often use the same cheap chips. I don't see the benefit in using a separate device when you can have one SoC because there are too many downsides. Not only are dedicated devices vulnerable to sniffing and fault injection attacks, the extraction of secrets is actually feasible with the right kind of equipment. SoC solutions make this impossible (manufacturing levels are simply too small). Apple, Google, and Intel (Panther Lake) have solved this the right way. Open Source security can and should be shifted to PIN dependent key enrollment to protect against backdoored or flawed secure elements.
Yes, the PIN is entangled with the key material. The admin PIN recovery techniques all involve enrolling additional unlocking methods.
Besides this, I completely agree with this post, especially:
> I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.
I've always found it silly that Microsoft's default BitLocker implementation doesn't make it easy to do the obvious thing that FileVault does and use the user's password as an additional wrapper to encrypt the KEK. Yes, then there's trouble when the user forgets their password and password-change rotation is a little annoying, but if you're in an enterprise scenario you need backup keys anyway, and your users are still as likely to get BitLocker'd by PCRs changing (ie due to EFI updates) than forgetting a password anyway.
pinum 11 hours ago [-]
Thanks, I was familiar with encryption but not with bitlocker.
So this only affects a particular mode of bitlocker in which the drive is automatically decrypted on boot without the user providing any secret. Meaning the key is basically stored in plaintext on-device, albeit in a convoluted way.
To me it seems intuitive that such a mode isn't secure. It's a bit like protecting your door with an unpickable unbreakable lock, but then putting the key in a lockbox on the wall with a flimsy padlock that can be raked or cut off in seconds.
It seems roughly equivalent to not encrypting the drive at all so it doesn't seem surprising that there's a way to bypass it.
GTP 10 hours ago [-]
The point is that the lockbox is the TPM that, on paper, is supposed to be unbreakable. In practice, sometimes it can still be broken with physical attacks (like side channel analysis or fault injection, or even simply snooping the communication between the TPM and the rest of the system with a logic level analyzer), despite that it should be designed to be hard to break even with such attacks.
If the TPM is properly designed and manufactured, and the software relying on it is again properly designed and implemented, then it would be perfectly secure. The problem is more the difference between the theory and the real world; the flimsy lockbox analogy doesn't hold.
Borealid 7 hours ago [-]
I don't think any of the attacks being discussed are actually attacks on the TPM's own threat model.
I think they're attacks on Windows' measured boot approach.
aiscoming 7 hours ago [-]
the vast majority of TPMs today live inside the CPU (fTPM). you can't physically attack them
Borealid 10 hours ago [-]
I gave three ways in which encrypting a disk using a TPM provides advantages over encrypting the disk using a secret password.
Encrypting the disk using a secret password provides advantages over encrypting the disk using a public password.
Encrypting the disk using a public password again provides advantages over not encrypting the disk (such as being able to securely "delete" data by removing the data encryption key).
I agree with your core point that attempting to use measured boot and secure boot to control whether the disk can be decrypted is full of holes. But if you want the computer to have an encrypted drive and to be able to boot up without a network or human intervention, what are your options really?
Terr_ 13 hours ago [-]
If we assume malicious software was already present from the beginning, that opens up some possibilities where the TPM is bypassed.
For example, storing a second, hidden copy of the master data encryption key, in an obfuscated form on a region of the disk that is unused or somehow reserved for the OS.
Borealid 13 hours ago [-]
That does not match up with the way this exploit works.
An un-exploited system is booted with a modified version of the Windows Recovery Environment.
Like I said, I think the not-well-described problem here is that (effectively) the lock screen on Windows RE is not secure, so you can have a PCR match in the TPM, but then access the disk as an administrator without typing the admin's user account password. That's not a vulnerability of the TPM itself, and it's not some kind of persistent exploit. It's a flaw in the Windows RE.
I'll also point out it grants access to do only what Microsoft themselves could do at any point. Anyone who has the ability to make a validly-signed copy of Windows could break into a TPM-locked Bitlocker setup exactly this way. People who use Bitlocker without a PIN are implicitly accepting that risk.
Dylan16807 14 hours ago [-]
You can have a boot-time password for bitlocker. But that mode doesn't seem to get much use.
aiscoming 14 hours ago [-]
how about we wait for proof for such grandiose claims
author could become famous by being the first to proove an actual backdoor in an OS disk encryption
solenoid0937 14 hours ago [-]
> We tested this ourselves, and sure enough, not only does it work, it bears all the hallmarks of a backdoor, down to the exploit's files disappearing from the USB stick after it's used once.
That's enough proof.
ungreased0675 17 hours ago [-]
Remarkable. Does MS take a huge reputational hit for having a backdoor, or are they so essential to most places this won’t matter?
peroids 17 hours ago [-]
I’m assuming the EU speeds up the uncoupling cause of some of this.
avazhi 14 hours ago [-]
I think anybody who has been paying attention has assumed for at least 20 years that all of Microsoft’s shit is backdoored anyway. I mean, the original Snowden revelations made that abundantly clear if it wasn’t before then.
Businesses use Microsoft because they figure if it’s backdoored it doesn’t matter and won’t affect them (because they aren’t terrorists or child pornographers or whatever, and they’d comply with a subpoena regardless of if Bitlocker is backdoored or not) and individuals who care about security and privacy put their shit on a Veracrypt drive somewhere else.
anal_reactor 14 hours ago [-]
I guess that most people who use security features of Microsoft products only do so to tick compliance checkboxes and they really don't give a fuck about actual security.
Which makes me think, it's becoming more and more urgent to make an open source mobile OS happen.
ranger_danger 16 hours ago [-]
As far as I can tell, there's no concrete evidence that it is actually an intentional "backdoor."
3eb7988a1663 15 hours ago [-]
What would you require to feel confident it is a backdoor?
Nadella gives a press release, "Alright guys, you got us fair and square. Backdoor on Bootlocker. Various versions of it for years on behalf of the spooks."
You are unlikely to ever get a confirmation of wrong doing. That being said, for a first line security posture, there is no way external media should have anything to do with the encryption process. Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.
It could always be plain old incompetence, but that is a damning level of technical ineptitude assigned to such critical infrastructure. This is not a project you assign to the intern, but paranoid security experts. Multiple levels of code review and red-teaming.
Dylan16807 14 hours ago [-]
> there is no way external media should have anything to do with the encryption process.
Does this exploit have external media having anything to do with the encryption process? If yes, how do we know that? Remember that the OS normally unlocks the drive on boot, when no exploits are happening.
> Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.
It's files in System Volume Information describing a transaction or something. It makes sense for it to resolve that transaction when mounting the external drive, and to then delete the files. And that's if it's even windows itself triggering the deletion.
skeptic_ai 16 hours ago [-]
[flagged]
majorchord 15 hours ago [-]
> lol it's an obvious backdoor
in your opinion
charcircuit 16 hours ago [-]
It's not an actual backdoor. An attacker found a way to exploit Windows after booting it up in this recovery mode. The security of files on the device depends on it being impossible for Windows to be pwned by an attacker on any surface exposed before the user is unlocked.
This is why operating systems like GrapheneOS disable the USB port on the initial boot to limit the attack surface that an attacker has.
tsimionescu 15 hours ago [-]
Having a specific file name trigger the decryption to happen automatically, while also removing said files after this is achieved, is an extremely unlikely bug. I think for most people evaluating this, the onus is now on anyone thinking this is not a backdoor to prove how a mistake in the code can trigger this very specific scenario.
This is like finding out that an OS accepts an SSH private key circulating online that the sysadmin for those OS boxes never authorized, and saying "wait, we don't know that this is a backdoor into that system, the attackers just found a bug".
charcircuit 14 hours ago [-]
>Having a specific file name trigger the decryption
That is not what happens. There is nothing wrong with decrypting the drive. If you just powered on the computer normally, it will "trigger the decryption." There just isn't way to read a file from the lock screen. This exploit is getting you to a state where the drive is unlocked but the user has access to a command prompt. A command prompt, unlike a basic login screen gives the user the ability to actually see the contents of arbitrary files.
>specific file name
It's a specific file name because Windows stores transaction logs under that name. If it was a random name it wouldn't be able to exercise this vulnerable code.
>also removing said files after this is achieved
It doesn't seem farfetched for a transaction log to be deleted after it is successfully replayed.
solenoid0937 14 hours ago [-]
This is 1000% a backdoor if you understand how the BitLocker process works.
charcircuit 14 hours ago [-]
I would appreciate for you to share an explanation with everyone else here as I am not intimate with Windows internals.
AndroTux 14 hours ago [-]
I don’t think anyone is using Windows for privacy, so I’d say nobody will care.
danpalmer 13 hours ago [-]
But almost every business is using Windows and depending on its security.
mystifyingpoi 13 hours ago [-]
Business side is different. I have a company provided Windows laptop and I could not care less about it's privacy or security - it's my employer problem, or at most my employer's IT/secops department.
But Windows for personal private use? No.
realusername 13 hours ago [-]
Nothing has changed since the old days, Windows still isn't appropriate for sensitive or secure operations.
(I'm aware that there's going to be a significant gap between the theory and what happens in practice though)
12 minutes ago [-]
esseph 12 hours ago [-]
It's used at every bank, every government institution, even carriers and nuclear submarines.
LelouBil 8 hours ago [-]
I saw someone on Reddit ask if it would be possible to write a known vulnerable WinRE version on the drive (or another drive ?) if this got patched?
I do not know bitlocker/TPMs a lot, do they also prevent this sort of thing ?
iscoelho 15 hours ago [-]
What's with all the replies on these threads downplaying this? Why is it mainly brand new accounts? What's going on here?
I've seen every variant of:
1) "this is an authentication/privilege escalation bug, not a bitlocker exploit" (? what are you even trying to say)
2) "even though the attacker explicitly warns that this is capable of bypassing TPM+PIN, that isn't actually true or what he meant"
3) "we shouldn't jump to conclusions that this is a backdoor"
4) "we already knew BitLocker with just TPM isn't secure" (? except many organizations depend on it to be)
Dylan16807 14 hours ago [-]
1) These systems are set up for automatic decryption. It's super obvious that if you can successfully attack windows between unlock and user login, you can get to the files. If this is such an attack, it's not a flaw with bitlocker itself.
2) Is it unreasonable to say "show it"?
3) Correct, we shouldn't jump to conclusions.
4) It's not known-insecure but it is known-enormous-attack-surface.
iscoelho 13 hours ago [-]
1) Except that the entire premise behind BitLocker TPM's security relies on the login screen as a hard security boundary, and thus any attack on the login screen is an attack on BitLocker. It is semantics to dispute this and certainly fits "downplaying."
2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.
3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.
4) Yes, this also fits the definition of downplaying.
Borealid 7 hours ago [-]
If Microsoft wanted a backdoor, there is no need to hide it in the official Windows Recovery Environment image.
Just sign an alternate version of the recovery environment that doesn't bother displaying a login screen. Done - you can access any TPM-only Bitlocker setup freely. This is actually LESS risky than keeping the exploit in the publicly-available version of WinRE, because you don't have the risk of pesky security researchers finding your backdoor.
Hanlon's Razor and Occam's Razor both say this is probably a bug that lets you use some kind of early-boot filesystem-corruption-fixing code on the recovery image to break the login screen and leave the disk unlocked by accident. It deletes itself because it's, well, intended to be a filesystem fix log, and the log gets deleted when it's done being replayed so it doesn't happen a second time!
Dylan16807 13 hours ago [-]
1) It is semantics to dispute this and certainly fits "downplaying."
It's not semantics. A true bitlocker backdoor would let you in even if it's passworded.
And is it really downplaying? The ability to shove in a USB stick and get control over the drive is mostly equivalent to a bitlocker exploit when it comes to laptop theft. But for quick access to a desktop without bitlocker, and without the ability to open it and pull the drive, it's actually more damaging than a bitlocker exploit.
2) I am not personally being dismissive of the claim. I'm saying it's fine to hold off, and even if we assume the PIN version is real we shouldn't assume we know exactly what it looks like.
3) Saying it's not a backdoor distracts from the point? Can't agree with you there at all. The comments saying it's definitely a backdoor are the ones I point to as distracted.
4) Maybe it's downplaying but it's true. Replying on TPM-based bitlocker is a lot more dangerous than having a secure password. It's chosen because it's easier to enforce.
iscoelho 13 hours ago [-]
If the device doesn't have BitLocker, this exploit is pointless because you can already boot any OS USB and immediately have full access to the unencrypted disk.
This exploit is only ever relevant with BitLocker enabled (as a method to "bypass" BitLocker's security premise [categorically classifying this as, dare I say, a "BitLocker bypass"]).
To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.
Dylan16807 13 hours ago [-]
> If the device doesn't have BitLocker, this exploit is pointless because you can already boot any OS USB
For this hypothetical, assume the owner took basic precautions to lock booting to the hard drive and password protect the BIOS.
But I'm not 100% familiar with how recovery mode normally works, so maybe it doesn't matter.
> To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.
I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.
iscoelho 13 hours ago [-]
If the device does not have BitLocker, WinRE already by default provides full Administrator access to the unencrypted disk via Command Prompt.
> I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.
If you look in the other threads about this, it's much more obvious. Look for brand new users. There's comparatively few in this thread, but the pattern is there: if the user's name is green, they're downplaying this.
14 hours ago [-]
gib444 14 hours ago [-]
Most submissions involving criticism of big tech gets those kind of replies. Par for the course here.
You just have to skip reading them because it seems there's no stopping those 100% genuine replies
Nition 15 hours ago [-]
This looking so much like an intentional backdoor just makes me wonder even more about TrueCrypt's sudden recommendation in 2014 that everyone switch to BitLocker. This particular backdoor didn't exist then (it's only Win11 apparently) but this sure makes it seem more plausible that another one might have.
Though if TrueCrypt was killed to try and get people to switch to encryption that could be backdoored, then why allow its successor VeraCrypt to exist? It's open source and independently audited, so it really shouldn't be backdoored.
My only doubt about YellowKey is, does it require having access to an already unlocked machine (i.e., the user is logged in) to copy the required files?
Borealid 7 hours ago [-]
It does not. The files are copied to the recovery image, not the machine's encrypted drives.
red_admiral 12 hours ago [-]
Properly secure symmetric encryption needs a key with at least 128 bits of entropy. In the "device lost/stolen" scenario, that key must not be on the device. Key inside a TPM on the device itself is DRM, nothing more. There's better and worse DRM, I think the iPhone bootloader one is one of the better ones, but it's still just DRM.
You either need to enter a 128-bit entropy password on every boot (good luck with that) or you need to hold it on some external device, with some variant of USB / smartcard / NFC / Bluetooth to transmit it. NB. this is one of the cases where the usual "key for signing only, never leaves device, ephemeral DH and ZK protocols" like for SSH will not work on its own; you need the high-entropy key physically separate from the device.
Linux/LUKS etc. doesn't change any of this, by the way.
P.S. If Eclipse really has beef with Microsoft, he could always make an exploit that lets you set up a PC without making a Microsoft account.
perching_aix 11 hours ago [-]
So much this. Security information should simply never reside on-device in the first place.
That said, I think this is a thing with BitLocker? I remember coming across YubiKeys being able to do this via something called PIV (Personal Identity Verification). Found this guide now after giving it a quick search: https://gist.github.com/daemonhorn/03301a66da7d1f4de6cdc8c8b...
Not sure how sound of a design it is though, didn't dig into it much at all.
Borealid 7 hours ago [-]
With PIV, the private keys are stored inside the smartcard (a Yubikey is just one type of smartcard) and don't leave it. They're used for encryption/decryption by the host.
Yes, it's generally sound, and is the primary means of authentication and encryption used by the US military for classified systems.
kristjank 11 hours ago [-]
Linux+LUKS enables FIDO2, which uses sha256, meets the requirements of "never leaves the device" and keeps it on a separate device, on a separate secure element.
bombcar 16 hours ago [-]
How is this even possible, backdoor or no? Isn't the whole point of this type of encryption that even a compromised machine can't decrypt without the passphrase? If this works it means that the key is stored unencrypted somewhere?
majorchord 16 hours ago [-]
Most setups only have the key stored in the TPM, so all you need to get it back is a signed/trusted bootloader.
Ideally you'd want that key to be further protected with a password or some other mechanism because it's not impossible to extract TPM keys.
andrecarini 16 hours ago [-]
Presumably the key is stored in the TPM
felooboolooomba 12 hours ago [-]
When I see a bug that walks like a backdoor and swims like a backdoor and quacks like a backdoor I call that bug a backdoor.
For those who use password (not PIN) based pre-boot authentication with BitLocker... do we know if that setup is safe?
I can't imagine there would be a way to bypass that if a password is required, unless it was a situation where like, there was originally some secret secondary key made that needs no password... or the password was never tied to the key in the first place.
andrecarini 16 hours ago [-]
The exploit developer themselves say [1] TPM+PIN is vulnerable, though no public PoC.
I’m skeptical of that claim. The key material presumably is inaccessible even to the OS without the passcode.
ranger_danger 16 hours ago [-]
> presumably
That's the thing, we don't actually know how involved the PIN is in relation to the key... it might be completely separate (and hence bypassable).
Similarly I also wonder if password-based pre-boot auth is affected.
cookiengineer 14 hours ago [-]
If someone drops 5 confirmed ring 0 exploits/bypasses within 3 months and claims that they got a 6th one... why on earth would you doubt that the 6th one suddenly is fake?
Do you know how hard discovering even one of those is? And how many months of work it takes?
aiscoming 14 hours ago [-]
this claim is in another galaxy, not your average 0-day
anonymars 4 hours ago [-]
One possibility is that in their test, TPM+Pin was added as an additional Key Protector, rather than replacing the TPM Key Protector
14 hours ago [-]
stackghost 13 hours ago [-]
What's with these two new accounts, `aiscoming` and `forestry`, being weirdly aggressive in their defense of bitlocker?
aiscoming 13 hours ago [-]
I get paid to defend AI and MSFT online. quite lucrative business. DM me if you are interested
Other links:
https://github.com/Nightmare-Eclipse/YellowKey
https://github.com/Nightmare-Eclipse/GreenPlasma
What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?
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.
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.
So true.
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.
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.
It also strikes me that these are several very high value (all but one complete) exploits.
Surely the value of these on the market would be astronomical and best suited to law enforcement agencies using unlock as a service businesses.
So I have to say I applaud the open disclosure
https://news.ycombinator.com/item?id=46735545
Local accounts still work fine for Win 11 Pro, I installed it a few days ago using a clean ISO directly from Microsoft. No special patching or command line stuff needed, making a local account is part of the official install process.
https://www.xda-developers.com/microsoft-cracking-down-on-lo...
https://medium.com/@michaelswengel/microsoft-blocking-local-...
They also seem suitable for using a secret sharing scheme.
I have Microsoft authenticator requests all day every day. Using aliases has helped but somehow they continue. It's only a matter of time before somehow accidentally I approve.
Which has simply led to me not putting anything of high value in my Microsoft account and not using it for my email.
I had someone demo me preserving PCR values by patching SMM module in firmware without triggering any bitlocker lockout, this also means that you can externally write bios with the smm module as long as you have ~2 minutes to disassemble the laptop or desktop and flash firmware.
This hurts the most when you don't have PIN authentication which means you just need to steal the laptop to exfiltrate data, if you do then you have to have the user boot which then drops a payload exfiltrating data over network or just stealing the laptop again as you can write back decryption keys into non encrypted partition or corrupt some sectors at the end of the disk and write them there.
* modifying smm allows you to patch the boot process loading a malicious payload into hypervisor/kernel.
I know my bike lock can be cut within seconds by someone who is sufficiently skilled and determined. I'm still going to lock my bike.
Also, I'd argue the stolen bag scenario usually features dilletante attackers.
Majority of hard disk encryption done in the HDD/SSD controller is 100 times more crap than BitLocker itself. It's littered with bugs and security vulns. Anybody using it is insane.
Oversimplified and not accurate. Some manufacturers had flawed implementations, others did not. Also, that was a long time ago. There are advantages to hardware encryption. It preserves performance and mitigates other vectors like cold-boot attacks without having to encrypt RAM, which also comes with a performance penalty. By the way, both software and hardware-based encryption can be combined. Cryptsetup on Linux actually offers this, and before you ask, the keys are split. If one is compromised, the other remains secure.
Less emotionally but mostly equivalently, the expense and non-cryptographic skill requirements of breaking mass-storage crypto are quite high while the rewards are comparable to those from breaking much softer targets, so the absence of results since that one paper only changes my mind very slightly. Besides, we know plenty of examples of what these kinds of opaque, serious-business, pay-to-play environments produce: cellular crypto is an uninterrupted series of disasters, so is Wi-Fi, and the things that we do know about storage devices don’t point to an outstanding culture of cryptographic competence there either. Once you’ve done enough to slap an “OPAL” label on it (which says nothing about the internals), there’s just no competitive pressure to improve.
There is a right way to do all this, and it’s essentially what NICs do: allow the host to offload symmetric crypto to the device, but keep the results of said crypto accessible at any moment. And it’s not like there are even that many modes used in full-disk encryption, let alone ciphers.
It’s also a way of saying that the entire approach taken by hardware disk encryption (unspecified crypto done inside the device in an unverifiable manner) has, with the benefit of hindsight, proven fundamentally flawed despite its reasonable appearance (in every system which had used it, not just storage), and I wish there was a way to pressure (consumer) storage vendors into going in a different direction. It is simply never a wise choice to trust people’s opaque crypto, however competent they are.
you use veracrypt which doesn't have any hardware attestation (convenience) features, but it does still leave you vulnerable to the same surface PIN+TPM is vulnerable to. the real defense is making it so opening your laptop/desktop physically fuses something via latch and wipes the key off your system requiring re-entry.
of course, who wants to own a laptop/desktop that you can't open we have enough of that with our phones.
For what it's worth, any OS using only hardware identity to unseal disk encryption is vulnerable to the same class of attack; there are all sorts of ways to misconfigure or exploit Linux FDE setups to enter a recovery shell as well. It's still a huge step above "no disk protection" (especially since it protects against every scenario where the disk is separated from the hardware), but the postboot surface area is enormous and nobody should be considering this class of protection as much more than a speed bump for a serious attacker.
> (Note: The YellowKey author disagrees that PIN is a protection
God I hate this stupid design of burying the decryption key in the TPM and hoping the software does not get fooled to reveal it.
Microsoft always sucks. Why don’t you ask for the password at boot time and derive the key from it. So much simpler and makes this kind of attacks impossible. Nobody is going to bypass LUKS or FileVault like this.
Does anyone really trust these shitty Windows laptop/desktop manufacturers to get these things right? These guys couldn't even get basic hardware features like trackpad drivers right.
Since there's a ton of misunderstanding in this thread, I'm going to go into how disk encryption works conceptually.
First, there's a symmetric key to encrypt blocks on the disk. Since you want to be able to change your unlocking password/mechanism without re-encrypting everything on the disk, this has nothing to do with unlocking the disk. This is what you want to get BY unlocking the disk. Let's call this the "data encryption key".
Then, there's something you use to encrypt the data encryption key. Let's call this the "key encryption key" (abbreviated KEK from here on in).
When you use a TPM, the KEK is stored inside the TPM. When you use a TPM PIN, the TPM refuses to release the KEK for use by the OS unless that PIN is provided.
You could say "why not make the KEK be a hash-mixed combination of a PIN and something inside the TPM?". One could do that! But that's not how Bitlocker works. There is a reason it doesn't work that way: the TPM is supposed to let company admins in charge of the device access it even if the original PIN is forgotten, by using other policies letting them get at the KEK. I personally set my own devices up such that the passphrase IS part of the KEK itself.
Interestingly, LUKS does not have a composite key mode natively that lets you combine a password with TPM material, but there are some good reasons not to use JUST a password:
1. The strength of your disk encryption reduces to the strength of the password, where a TPM can have a 256-bit truly random key
2. If someone keylogs the password, or tricks you into disclosing it, they can later decrypt your drive from anywhere, where a TPM binds the attack to those with posession of the TPM
3. There is no protection against brute force attacks (rate limiting), where a TPM does - or tries to - impose a rate limit
Now, let's go on to what YellowKey attacks.
A TPM can have inside itself "registers", called PCRs. These PCRs can be updated but not reset - think of it like you can add numbers to them but not subtract, and they only go back to zero when you reboot.
Using a passwordless encrypted boot, the TPM is configured to only release the key when the PCRs are in the exact correct state. As the OS boots it adds numbers to those PCRs. If you boot "the wrong" software, the numbers in those registers won't match the expectations, and you cannot unlock the disk.
Speculation on my part: the reason there's an exploit here is that the Windows Recovery Environment apparently can match the PCR values for the booted OS, causing the TPM to release the key, but WinRE doesn't require you to get your password right before it gives you access to the data. So far as I know, protecting the TPM key with a PIN would mitigate this issue, but it's still bad.
Or maybe the exploit actually does something inside the TPM itself, causing it to unconditionally release the key even when protected by a PIN: that would be even worse, but **NOT*** a problem with Windows. That would be a problem with the TPM.
True. It's unfortunate, amd a lot of false information being spread there.
> the KEK is stored inside the TPM
That's not how it works. The KEK is not stored inside the TPM, but encrypted/decrypted by the TPM.
> You could say "why not make the KEK be a hash-mixed combination of a PIN and something inside the TPM?".
Bitlocker does that. Cryptenroll doesn't (https://github.com/systemd/systemd/pull/27502), which is bad but has not been fixed.
TPMs are a nice idea, but there are a few problems:
- The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.
- There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.
I seriously doubt the author found a way to bypass PIN protected setups in general. This should only be possible in combination with a vendor/model specific vulnerability. Maybe an fTPM?
As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.
No, the KEK is stored inside the TPM, and the DEK is decrypted by it. If you have three layers (two KEKs, one encrypted with the other) then sure. But at the end of the day one private key is actually stored inside the TPM, taking up as much space as the length of the key.
To be specific, Bitlocker uses a stored key, not a derived key.
> Bitlocker does that. Cryptenroll doesn't (https://github.com/systemd/systemd/pull/27502), which is bad but has not been fixed.
I don't think Bitlocker does that, because it's possible to set up admin PIN recovery techniques. That would be impossible if the PIN were part of the KEK.
> - The KEK should also depend on the PIN. Cryptpentroll does not do this at all and Bitlocker limits the PIN to 20 characters.
I agree.
> There are various manufacturers of TPMs and all of them have different implementations. Some of them had been broken in the past, which is why it's important to make secrets PIN-dependent.
I agree. Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too. There are even open-source implementations of FIDO2 where the key is in fact derived from the user's PIN (plus a stored secret). If you did that, you get the proper security properties even without cryptsetup mixing the two methods.
> I seriously doubt the author found a way to bypass PIN protected setups in general.
I agree - I think the author probably just found a flaw in the windows recovery environment and is talking up how a PIN only helps you if the attacker does not know your PIN (in other words, acting as if the PIN provides no threat resistance when really it provides an additional layer).
> As of this moment, I would rather look at it as a convenience feature. A high entropy password + a proper KDF (not possible on Windows) like scrypt or argon2 is the better choice. Encryption should be handled by SoC engines like on Macs, iPhones or some Android phones to mitigate other attacks and preserve performance anyway. Panther Lake CPUs with vPro support do on Windows.
I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.
No. Technically, TPMs can store secrets (limited due to little nvram), but no FDE implementation as far as I'm aware does this. TPMs wrap/encrypt the key and return an encrypted blob which will be stored in the header which will be decrypted upon request. The actual KEK is never stored on the TPM.
> I don't think Bitlocker does that
It does, which is why cryptsetup was much more affected by the faulTPM exploit: https://arxiv.org/abs/2304.14717
> Perhaps consider using a FIDO2 token (supported by cryptsetup) instead of a TPM. There are open-source implementations of FIDO2 and open-hardware ones too.
Not only do they do the same thing, they often use the same cheap chips. I don't see the benefit in using a separate device when you can have one SoC because there are too many downsides. Not only are dedicated devices vulnerable to sniffing and fault injection attacks, the extraction of secrets is actually feasible with the right kind of equipment. SoC solutions make this impossible (manufacturing levels are simply too small). Apple, Google, and Intel (Panther Lake) have solved this the right way. Open Source security can and should be shifted to PIN dependent key enrollment to protect against backdoored or flawed secure elements.
https://post-cyberlabs.github.io/Offensive-security-publicat...
Yes, the PIN is entangled with the key material. The admin PIN recovery techniques all involve enrolling additional unlocking methods.
Besides this, I completely agree with this post, especially:
> I think the best you can do right now is to layer a password with a hardware device. I don't think saying that the hardware devices are flawed means they are not useful as PART OF the security setup. It would certainly be nice if the software did this automatically/easily and it's unclear to me why it does not.
I've always found it silly that Microsoft's default BitLocker implementation doesn't make it easy to do the obvious thing that FileVault does and use the user's password as an additional wrapper to encrypt the KEK. Yes, then there's trouble when the user forgets their password and password-change rotation is a little annoying, but if you're in an enterprise scenario you need backup keys anyway, and your users are still as likely to get BitLocker'd by PCRs changing (ie due to EFI updates) than forgetting a password anyway.
So this only affects a particular mode of bitlocker in which the drive is automatically decrypted on boot without the user providing any secret. Meaning the key is basically stored in plaintext on-device, albeit in a convoluted way.
To me it seems intuitive that such a mode isn't secure. It's a bit like protecting your door with an unpickable unbreakable lock, but then putting the key in a lockbox on the wall with a flimsy padlock that can be raked or cut off in seconds.
It seems roughly equivalent to not encrypting the drive at all so it doesn't seem surprising that there's a way to bypass it.
If the TPM is properly designed and manufactured, and the software relying on it is again properly designed and implemented, then it would be perfectly secure. The problem is more the difference between the theory and the real world; the flimsy lockbox analogy doesn't hold.
I think they're attacks on Windows' measured boot approach.
Encrypting the disk using a secret password provides advantages over encrypting the disk using a public password.
Encrypting the disk using a public password again provides advantages over not encrypting the disk (such as being able to securely "delete" data by removing the data encryption key).
I agree with your core point that attempting to use measured boot and secure boot to control whether the disk can be decrypted is full of holes. But if you want the computer to have an encrypted drive and to be able to boot up without a network or human intervention, what are your options really?
For example, storing a second, hidden copy of the master data encryption key, in an obfuscated form on a region of the disk that is unused or somehow reserved for the OS.
An un-exploited system is booted with a modified version of the Windows Recovery Environment.
Like I said, I think the not-well-described problem here is that (effectively) the lock screen on Windows RE is not secure, so you can have a PCR match in the TPM, but then access the disk as an administrator without typing the admin's user account password. That's not a vulnerability of the TPM itself, and it's not some kind of persistent exploit. It's a flaw in the Windows RE.
I'll also point out it grants access to do only what Microsoft themselves could do at any point. Anyone who has the ability to make a validly-signed copy of Windows could break into a TPM-locked Bitlocker setup exactly this way. People who use Bitlocker without a PIN are implicitly accepting that risk.
author could become famous by being the first to proove an actual backdoor in an OS disk encryption
That's enough proof.
Businesses use Microsoft because they figure if it’s backdoored it doesn’t matter and won’t affect them (because they aren’t terrorists or child pornographers or whatever, and they’d comply with a subpoena regardless of if Bitlocker is backdoored or not) and individuals who care about security and privacy put their shit on a Veracrypt drive somewhere else.
Which makes me think, it's becoming more and more urgent to make an open source mobile OS happen.
Nadella gives a press release, "Alright guys, you got us fair and square. Backdoor on Bootlocker. Various versions of it for years on behalf of the spooks."
You are unlikely to ever get a confirmation of wrong doing. That being said, for a first line security posture, there is no way external media should have anything to do with the encryption process. Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.
It could always be plain old incompetence, but that is a damning level of technical ineptitude assigned to such critical infrastructure. This is not a project you assign to the intern, but paranoid security experts. Multiple levels of code review and red-teaming.
Does this exploit have external media having anything to do with the encryption process? If yes, how do we know that? Remember that the OS normally unlocks the drive on boot, when no exploits are happening.
> Even if the OS chose to read a USB drive, to also delete the magical files is ridiculously suspect.
It's files in System Volume Information describing a transaction or something. It makes sense for it to resolve that transaction when mounting the external drive, and to then delete the files. And that's if it's even windows itself triggering the deletion.
in your opinion
This is why operating systems like GrapheneOS disable the USB port on the initial boot to limit the attack surface that an attacker has.
This is like finding out that an OS accepts an SSH private key circulating online that the sysadmin for those OS boxes never authorized, and saying "wait, we don't know that this is a backdoor into that system, the attackers just found a bug".
That is not what happens. There is nothing wrong with decrypting the drive. If you just powered on the computer normally, it will "trigger the decryption." There just isn't way to read a file from the lock screen. This exploit is getting you to a state where the drive is unlocked but the user has access to a command prompt. A command prompt, unlike a basic login screen gives the user the ability to actually see the contents of arbitrary files.
>specific file name
It's a specific file name because Windows stores transaction logs under that name. If it was a random name it wouldn't be able to exercise this vulnerable code.
>also removing said files after this is achieved
It doesn't seem farfetched for a transaction log to be deleted after it is successfully replayed.
But Windows for personal private use? No.
(I'm aware that there's going to be a significant gap between the theory and what happens in practice though)
I do not know bitlocker/TPMs a lot, do they also prevent this sort of thing ?
I've seen every variant of:
1) "this is an authentication/privilege escalation bug, not a bitlocker exploit" (? what are you even trying to say)
2) "even though the attacker explicitly warns that this is capable of bypassing TPM+PIN, that isn't actually true or what he meant"
3) "we shouldn't jump to conclusions that this is a backdoor"
4) "we already knew BitLocker with just TPM isn't secure" (? except many organizations depend on it to be)
2) Is it unreasonable to say "show it"?
3) Correct, we shouldn't jump to conclusions.
4) It's not known-insecure but it is known-enormous-attack-surface.
2) I'm sure many organizations are thankful that the researcher has decided not to release that exploit chain at this time. I am hopeful that Microsoft will not be as dismissive and will resolve it before it is publicly released.
3) It distracts from the point. The point is that Microsoft's security record is so bad that many of the vulnerabilities appear deliberate and obvious enough to be backdoors.
4) Yes, this also fits the definition of downplaying.
Just sign an alternate version of the recovery environment that doesn't bother displaying a login screen. Done - you can access any TPM-only Bitlocker setup freely. This is actually LESS risky than keeping the exploit in the publicly-available version of WinRE, because you don't have the risk of pesky security researchers finding your backdoor.
Hanlon's Razor and Occam's Razor both say this is probably a bug that lets you use some kind of early-boot filesystem-corruption-fixing code on the recovery image to break the login screen and leave the disk unlocked by accident. It deletes itself because it's, well, intended to be a filesystem fix log, and the log gets deleted when it's done being replayed so it doesn't happen a second time!
It's not semantics. A true bitlocker backdoor would let you in even if it's passworded.
And is it really downplaying? The ability to shove in a USB stick and get control over the drive is mostly equivalent to a bitlocker exploit when it comes to laptop theft. But for quick access to a desktop without bitlocker, and without the ability to open it and pull the drive, it's actually more damaging than a bitlocker exploit.
2) I am not personally being dismissive of the claim. I'm saying it's fine to hold off, and even if we assume the PIN version is real we shouldn't assume we know exactly what it looks like.
3) Saying it's not a backdoor distracts from the point? Can't agree with you there at all. The comments saying it's definitely a backdoor are the ones I point to as distracted.
4) Maybe it's downplaying but it's true. Replying on TPM-based bitlocker is a lot more dangerous than having a secure password. It's chosen because it's easier to enforce.
This exploit is only ever relevant with BitLocker enabled (as a method to "bypass" BitLocker's security premise [categorically classifying this as, dare I say, a "BitLocker bypass"]).
To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.
For this hypothetical, assume the owner took basic precautions to lock booting to the hard drive and password protect the BIOS.
But I'm not 100% familiar with how recovery mode normally works, so maybe it doesn't matter.
> To avoid typing 1)2)3)4) a bunch of more times, I'll just say 2/3/4) all still fit the definition of downplaying the situation.
I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.
> I think that level of pushback against the claims is a valid (and small) amount of "downplaying". I haven't seen anyone claiming this isn't a serious issue.
If you look in the other threads about this, it's much more obvious. Look for brand new users. There's comparatively few in this thread, but the pattern is there: if the user's name is green, they're downplaying this.
You just have to skip reading them because it seems there's no stopping those 100% genuine replies
Though if TrueCrypt was killed to try and get people to switch to encryption that could be backdoored, then why allow its successor VeraCrypt to exist? It's open source and independently audited, so it really shouldn't be backdoored.
You either need to enter a 128-bit entropy password on every boot (good luck with that) or you need to hold it on some external device, with some variant of USB / smartcard / NFC / Bluetooth to transmit it. NB. this is one of the cases where the usual "key for signing only, never leaves device, ephemeral DH and ZK protocols" like for SSH will not work on its own; you need the high-entropy key physically separate from the device.
The NSA realised this a while ago: https://en.wikipedia.org/wiki/KSD-64
Linux/LUKS etc. doesn't change any of this, by the way.
P.S. If Eclipse really has beef with Microsoft, he could always make an exploit that lets you set up a PC without making a Microsoft account.
That said, I think this is a thing with BitLocker? I remember coming across YubiKeys being able to do this via something called PIV (Personal Identity Verification). Found this guide now after giving it a quick search: https://gist.github.com/daemonhorn/03301a66da7d1f4de6cdc8c8b...
Not sure how sound of a design it is though, didn't dig into it much at all.
Yes, it's generally sound, and is the primary means of authentication and encryption used by the US military for classified systems.
Ideally you'd want that key to be further protected with a password or some other mechanism because it's not impossible to extract TPM keys.
And earlier
https://news.ycombinator.com/item?id=48114997
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
I can't imagine there would be a way to bypass that if a password is required, unless it was a situation where like, there was originally some secret secondary key made that needs no password... or the password was never tied to the key in the first place.
[1]: https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
That's the thing, we don't actually know how involved the PIN is in relation to the key... it might be completely separate (and hence bypassable).
Similarly I also wonder if password-based pre-boot auth is affected.
Do you know how hard discovering even one of those is? And how many months of work it takes?