This exploit requires physical access, and if you have physical access, anything is possible. Secure your shit better.
Bitlocker is designed to aid against phyiscal attacks, so physical access is a given.
the best you can ever do is make physical attacks more inconvenient, and it succeeds at that.
Here's another "critical vulnerability": the attacker can insert a physical device to intercept all keystrokes, and steal the key whenever the user enters it. A hidden camera can also accomplish this
Physical access to a running device, for clarity.
Edit: Unless you use a TPM with no pin/password, which is dumb.
It doesn't already have to be running. BitLocker retrieves its keys from TPM by default, so just booting a device will place the keys in memory.
To minimize downtime, abruptly restart the target system during the Windows boot process, specifically before the login screen appears, as this approach has proven effective in scenarios involving the retrieval of Full Volume Encryption Keys (FVEKs).
By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.
You're misreading that, I'm afraid. Direct from the researcher:
This can be done in a variety of ways but the goal is to minimize how much time the computer is completely powered off. In my experience I have had the most success restarting the system while Windows is loading but before the login screen has appeared, at least in the case of finding FVEK keys.
"While Windows is loading" ... You must restart after the BitLocker password has been entered and the key is stored in RAM, that's how this exploit works. He had the best luck at that point durong boot, but it could be attempted at any time when RAM is powered and BitLocker is already unlocked. A shutdown or hibernated system is not vulnerable.
A lot of BitLocker setups unlock using just TPM though, which was my point. No password/PIN needs to be entered at boot time to unlock it, it uses the TPM to unlock. This is the default setup that many companies use. Password/PIN unlock is completely optional.
I'm not misreading that.
Not the default at any company I've been at. What's the point of encryption if it's unlocked right away? Whoever's doing that deserves this exploit. However, since that's factually correct I'll edit my original comment to add in:
unless you use a TPM with no pin/password, which is dumb
Exactly.
I don't use BitLocker, but I do use FDE on Linux, and I use a password at the bootloader level. Why would I bother with all the downsides of FDE if it isn't actually secured by a password?
If the computer doesn't password protection and the attacker has physical access... They can just copy the data, why care about the keys?
I think that's already a worst case scenario.
The user still has to login to their user account. The assumption is that the Windows login is secure so BitLocker can decrypt using TPM and an attacker still won't have access to the data without being able to log in.
This article obviously shows a method how an attacker can potentially still get access to the data without logging in.
A "cold boot" attack. These have been around for a while.
The degredation is not a huge barrier. Spraying inverted canned air can cool the DRAM enough to preserve it for a little while, even long enough to switch it to a new motherboard. Whenever the motherboard is powered, the DRAM is being refreshed, so won't degrade. A few bits lost is no fatal flaw, since most cold boot attack algorithms search for long key schedules, not just the key.
Bitlocker is extra vulberable because it stores the key in the TPM and requires no password to boot. An attacker can extract the key even if the computer is off when they get it.
Bitlocker is extra vulberable because it stores the key in the TPM and requires no password to boot. An attacker can extract the key even if the computer is off when they get it.
This is not true.
You would additionally need to bypass Secure Boot with a separate exploit such as the one in this article (which is mitigated by disabling USB boot) or LogoFAIL to put the TPM PCRs in a state where the keys can be released.
LUKS2 is no different here as either can be TPM-only or require a separate PIN.
Yes, assuming it's durably sealed and tamper-proof. If you have enough physical access, though, you can remove the DRAM and put it in another machine to scrape it. This adds time, but it has been done before. One experiment dipped the DRAM in liquid nitrogen for an hour, and found 0.13% decay.
Yeah you really need a password or TPM PIN protector to protect from cold boot attacks if that is in your threat model.
What's the advantage of disk encryption if you don't require a password to boot? Couldn't you just boot the device and extract the data using Explorer anyway?
Its kinda useful for devices where userland is also protected against exfil, like a kiosk or windows lock screen.
If the bios is hardened, secure boot on, bitlocker on, and windows is locked with a password, you can't simply take the disk out and manipulate it cause bitlocker with TPM means only that specific hardware profile will decrypt the disk automatically.
You can't get to explorer cause the system is locked with windows auth, and you can't reset the PW cause bitlocker is on, and you cant remove the disk cause the TPM protects against that with bitlocker.
Its really not perfect, and I'm not advocating for it, but its a decent protection in systems where adding another pin/password isn't practical.
Even Microsoft recommends at least also using a pin with bitlocker.
I assume they think the Windows login password will keep them safe. I don't know. But many corporate computers (several I've been forced to use) do use Bitlocker without a password.
Yeah, that's only going to protect from drive theft, which I guess makes disposal easier?
All secure implementations of Bitlocker also use a password on boot. Use of a TPM is not unique to Bitlocker either.
Is this really a BitLocker issue or more an issue inherent in the hardware design?
EDIT: Okay, looks like Microsoft could do better:
By kernel-level debugging with WinDbg, the researcher observed BitLocker operations during the Windows boot process, which revealed that while Microsoft attempts to erase encryption keys using functions like SymCryptSessionDestroy, some keys persist on the heap, potentially due to incomplete key destruction mechanisms.
But maybe the hardware/UEFI should immediately wipe memory upon restarting anyway..?
The key has to be stored somewhere to be able to use it. This is full disk encryption, so every single sector that is read or written (except some boot and kernel stuff, presumably) needs to go through that encryption key. You could maybe store it in a cryptographic coprocessor that uses SRAM for the key and key schedule, but those are very uncommon now that AES-NI is popular. And I don't think AES-NI has any special registers that could help here.
Is LUKS2 resistant against Cold Boot attacks?
Any encryption system that uses the CPU to decrypt will need the key in memory, so yes it can be attacked in a similar manner.
c/cybersecurity is a community centered on the cybersecurity and information security profession. You can come here to discuss news, post something interesting, or just chat with others.
THE RULES
Instance Rules
Community Rules
If you ask someone to hack your "friends" socials you're just going to get banned so don't do that.
Learn about hacking
Other security-related communities !databreaches@lemmy.zip !netsec@lemmy.world !securitynews@infosec.pub !cybersecurity@infosec.pub !pulse_of_truth@infosec.pub
Notable mention to !cybersecuritymemes@lemmy.world