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.
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.
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.
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?
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
> 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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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".
>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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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?
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.
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?
Other links:
https://github.com/Nightmare-Eclipse/YellowKey
https://github.com/Nightmare-Eclipse/GreenPlasma
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.
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.
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.
What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?
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
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?
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.
> (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.
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.
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)
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.
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.
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
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.
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.
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
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
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...
Do you know how hard discovering even one of those is? And how many months of work it takes?
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.