11 ms·

Dumping Memory to Bypass BitLocker on Windows 11

310 points by supermatou 2y ago

tnetenbaa 2y ago
BitLocker is crazy easy to bypass if you have physical access to the device. I work IT, and had to demonstrate to our head of security, that if you just pop in a Linux USB and boot from it, the drive is completely open.
- Grazester 2y ago
  Then the drive wasn't encrypted!
  - connicpu 2y ago
    Presumably they chose the weakest option where it can boot without a pin/password just using a key stored in the TPM.
    - dogma1138 2y ago
      Even if you are using Transparent Operation Mode then it still will not work as bitlocker will not decrypt the drive and lock itself into recovery mode if you make changes to the boot order or any other BIOS / UEFI changes. It uses secure boot and it’s pretty darn decent at detecting any form of tampering. TPM 2.0 isn’t particularly resilient against physical key extraction attacks but believe it or Microsoft did threat model this…
      - BuyMyBitcoins 2y ago
        This happened to me once. Sadly I had wiped the flash drive containing the recovery key months before the lockout without realizing it. Chide me if you must, but I certainly learned my lesson. I tried a few non-hardware exploits, even CVE-2022-41099 about WinRE but to no avail. I’m not a security pro, but I assume once it is in recovery mode lockout you’re pretty much out of luck. From what I can tell most other exploits require it to be unlocked in the first place. Even the hardware hacks seem to require a drive being in a non-lockdown state in order to sniff things during boot. That NVMe drive is just a keepsake now. I plan to frame it and put it on my wall as a memento.
        dogma1138 2y ago
        This is why i use the key backup to OneDrive option. My threat model is a lost or stolen device or RMA/repair. If someone wants my data so badly that they’ll be able get into my OneDrive account that is protected with a passkey or a 32 char password + MFA and also have physical access to my devices let them have it. Anyone who is that determined and capable can always resort to rubber hose cryptography and I want none of that in my life.
- deleted 2y ago
  [deleted]
- dogma1138 2y ago
  You should’ve enabled bitlocker first then… The only thing that would be unencrypted is the system restore partition.
  - simondanerd 2y ago
    Correct, ran into this last night. Dislocker works though: https://github.com/Aorimn/dislocker https://github.com/Aorimn/dislocker
    - dogma1138 2y ago
      Dislocker does require you to have the keys tho it’s not a bypass.
- davemtl 2y ago
  This sounds like BitLocker wasn't enabled on the drive. All of the laptops I've deployed with BitLocker are very good at detecting tampering and will immediately go into lockdown mode. A Linux USB most likely requires Secure Boot to be turned off to boot, if so, the TPM tamper will trigger and BitLocker will require the recovery key at next boot.
  - doodlesdev 2y ago
    > A Linux USB most likely requires Secure Boot to be turned off to boot That hasn't been my experience. All the recent laptops I've owned (Dell and HP) had a default secure boot setup that allowed booting to Ubuntu and Fedora without disabling Secure Boot. In fact, nowadays even Ventoy works with Secure Boot [0], and I've managed to use it with the setting enabled on all machines I've tested, however in this case you might need to enroll the keys on the first boot, which I imagine will trigger BitLocker. Apparently what happened is that Microsoft now signs some third party certs for common Linux distributions, and some setups allow these to boot by default. However, it also looks like Microsoft wants these certs disabled by default [1], which should improve BitLocker integrity on average. Although I believe what happened in OP's situation was that BitLocker wasn't actually enabled or working, likely due to misconfiguration or lack of any. [0]: https://www.ventoy.net/en/doc_secure.html https://www.ventoy.net/en/doc_secure.html [1]: https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-bios-setting/ https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-...
3eb7988a1663 2y ago
What was the hardware on which this was running? I thought DDR5 would be more resistant to this type of RAM attack.
- Arnavion 2y ago
  This is not "attacking" RAM. A UEFI binary (or Linux kernel in the CCC demo which uses a different method to retain the key in memory) already has access to all the extents of physical memory. It just has to search it for the scribble leftover from the bootloader. See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc056f9d9e10d34ca3541a55e325a8211d/app/Application.c#L119-L131 https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards. Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.
  - dogma1138 2y ago
    Indeed, however it should be noted that this is only a single attempt attack and which will trigger the tamper protection. Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout. This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery. And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.
    - mjg59 2y ago
      Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?
      - dogma1138 2y ago
        The TPM tracks the state of the secure boot and the bios, that log is stored in the TPM itself the next time you’ll try to boot into windows it will see that something happened and bitlocker will lock itself out. Do this experiment. Boot into any Linux live CD on a machine with bitlocker enabled. Reboot and see what happens.
mjg59 2y ago
This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-group-platform-reset-attack-mitigation-specification/ https://trustedcomputinggroup.org/resource/pc-client-work-gr... - if enabled, if the OS isn't cleanly shut down (giving it an opportunity to wipe encryption keys) the firmware will pause to wipe RAM before booting anything else on next boot. Does Windows not make use of this, or did the tested system not implement it?
- cyberax 2y ago
  This still won't prevent yoinking the entire RAM modules and dumping them offline. Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
  - bangaladore 2y ago
    > This still won't prevent yoinking the entire RAM modules and dumping them offline. Theoretically no, but realistically I doubt even intel agencies can pull this off. > Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die. The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
    - bri3d 2y ago
      > Theoretically no, but realistically I doubt even intel agencies can pull this off. For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though. > In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records. This already exists: it's the MOR bit and it's supposed to be in play here. I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.
jandrese 2y ago
Fundamentally I don't understand BitLocker's security model. In most installs it seems like you power on the machine by pressing the power button and it boots into Windows. So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated. I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that, but it seems like the machine is going to give up the key pretty easily regardless. With LUKS it at least has a password prompt to unlock the drive.
- bri3d 2y ago
  > I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around. > With LUKS it at least has a password prompt to unlock the drive. Configuration dependent. You can set up Linux to do the same thing as Windows here (I have my home video-security server set up this way, as it needs to reboot silently - I know that I'm vulnerable to warm/coldboot attack and software attack surface, but at least if someone yoinks the drive I'm safe), and Windows can also be configured to prompt for a password or use PIN-authenticated TPM sealed keys. > Fundamentally I don't understand BitLocker's security model. Minus the parameter encryption / bus-sniffing issue, it moves the boundary from "anyone can read your drive" to "someone needs to either perform a platform-level attack to access the contents of memory, or hack whatever services are running at the login screen to read your drive." It's a decent security improvement, actually, because it protects very well against stuff like "someone stole our financial data off of a random recycled hard drive."
  - raron 2y ago
    > It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around. AFAIK it is useless, there is no way the TPM could authenticate the CPU. You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.
maxo133 2y ago
Too bad the author did not provide hardware specs. Such attack is even harder on DDR4 and DDR5 memory and most publications refer to legacy ram such as DDR3 > 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. So what is this? It was supposed to be memory attack and he's dumping the keys after someone unlocked it and it's booting? So this is just another theoretical attack where perfect conditions must be met.
- bri3d 2y ago
  This attack has nothing to do with the memory type; memory is never made cold or allowed to decay. The system is hot-restarted into UEFI. Ideally no memory refreshes are skipped. I do wish they provided the hardware specs too, though, as this reflects an incorrect UEFI platform implementation of MOR.
  - maxo133 2y ago
    You are right, but i still have no idea what is the point of this article. The guy unlocked the bitlocker, then restarted PC just before login screen appeared. He said that's when he had most success. What sense does it make to restart and start looking for key in memory, when bitlocker has been just unlocked.
    - bri3d 2y ago
      > What sense does it make to restart when bitlocker has been just unlocked. You steal a laptop. You turn on the laptop. You reboot it into UEFI and steal the keys. This is bad for BitLocker. Ideally this is not possible because the MOR bit should cause the keys to be erased by the platform initialization before boot-from-USB is possible.
    - mjg59 2y ago
      I steal your Windows laptop. I want your data. I don't have your credentials, so can't login to Windows. I let your laptop boot to the point where Bitlocker is automatically unlocked, perform a hard reboot, dump the RAM, extract the keys, and can now decrypt your drive and extract your data.
jansommer 2y ago
I think you get the biggest advantage from BitLocker when you use TPM (PCR 7+11) with a PIN. That should mitigate the exploit because the FVEK should never be read without the PIN, and if BitLocker does it right (which I think it does) too many wrong PIN's results in the TPM going into dictionary attack lockout mode. Now I've been trying for months to do the same for Linux. There's systemd-cryptsetup/cryptenroll, but it's only for LUKS and I'm trying to encrypt a few sensitive directories on a super slow internal eMMC with fscrypt (keys for secure boot and /home). The TPM is _EXTREMELY_ hard to code for when things go beyond the basics: 1. Bind to PCR 7 2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated) 3. Use a PIN - but not the AuthValue, because I want to use the same authorization policy for resetting the DA lockout counter on login, and also have a long password/AuthValue for resetting the counter manually. 4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub. Maybe this isn't the right place to ask, but there's almost nothing but basic TPM guides out there, so if you're an expert I could really use your help. It's just for a personal project, but I'll write about it once I'm done - if I ever figure it out!
- varispeed 2y ago
  Isn't TPM just a honeypot of sorts? It seems strange to me that after successful open source encryption software, there was a shift to TPM, like you'll have a notion of super secure storage provided by big corporations and you should just not worry about it and not question. Surely there must be a backdoor access for three letter agencies to just download all the pins and passwords and then take a dip in the data, no worries.
  - jansommer 2y ago
    Should be good enough for a personal tablet used for mail and browsing. If I drop it and someone curious finds it, I'd like to make it impossible for them to extract anything useful.
  - cheschire 2y ago
    I prefer to think of TPM as equivalent to the chip in a smart card.
slicktux 2y ago
Why are more people not using self encrypting drives?
- varispeed 2y ago
  Ages ago I had an external drive that had a controller with built in keys that encrypted the data in and out. Problem was that the controller was poorly made and one time upon connecting to the PC, the controller chip died and so the keys with it. It was impossible to recover the data, but the disk itself was perfectly fine. I bought a damaged drive with working controller and swapped it out and my drive worked again, however I had to format it, because new board had different keys. Since then I preferred to use software encryption and steered clear of drives that use any sort of hardware encryption. The risk of losing data was not worth it.
  - arghwhat 2y ago
    All SSD's with OPAL are always encrypting your data. "Enabling" the feature just means that you change from a random on-device key to a key encrypted with your passphrase. (Whenever you wipe the drive through OPAL, you're just overwriting the key.)
- TiredOfLife 2y ago
  After this https://borncity.com/win/2018/11/06/ssd-vulnerability-breaks-bitlocker-encryption/ https://borncity.com/win/2018/11/06/ssd-vulnerability-breaks... Microsoft patched out support for self encrypting drives.
  - arghwhat 2y ago
    Quite dumb considering this was an issue with pretty much a single, low-cost consumer vendor (Crucial?). If nothing else, use it in combination - the encryption of OPAL drives is always active anyway, all that changes when the feature is "active" is whether the key is stored as-is on the controller or whether its protected by a passphrase.
PhilippGille 2y ago
Related 38C3 talk about Windows 11 BitLocker bypass: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-without-a-screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...
DEEP-MELTDOWN 2y ago
[dead]
layer8 2y ago
It’s fairly well known that BitLocker only really protects a computer that is turned off, and also only if you configure BitLocker to require a boot password [0]. [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_enough https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...
medlazik 2y ago
Step 3: Boot from the USB Device Game over, any laptop with data worth stealing will have this disabled in bios
- totalizator 2y ago
  Valid point but what about the reality? Imagine typical Evil Maid attack but within a workplace, as a cleaning staff. Game over.
RachelF 2y ago
Windows has a proposed memory encryption option along with memory compression. Both Intel and AMD are working on embedding this into their CPUs. However, the target use appears to be servers with multiple VMs, not laptops.
- p_ing 2y ago
  Intel has this via their Total Memory Encryption feature today. Yes, geared towards VMs in the Windows ecosystem. https://techcommunity.microsoft.com/blog/windowsosplatform/multi-key-total-memory-encryption-on-windows-11-22h2/3683043 https://techcommunity.microsoft.com/blog/windowsosplatform/m... Memory compression has been around for ages, at least since Windows 10 RTM. All major operating systems have implemented this feature -- it has no relation to security, though.
- jeroenhd 2y ago
  Microsoft is moving more and more to virtualisation based security, including the ability to run “enclaves” for protecting specific pieces of software: https://learn.microsoft.com/en-us/windows/win32/trusted-execution/vbs-enclaves https://learn.microsoft.com/en-us/windows/win32/trusted-exec.... I wouldn't be surprised if they'll soon leverage encrypted “VMs” as a means of storing secrets like these. All we need is wide general hardware availability on consumer platforms. That said, previous side-channel attacks on CPUs have shown it possible to attack encrypted memory (https://www.usenix.org/conference/usenixsecurity21/presentation/li-mengyuan https://www.usenix.org/conference/usenixsecurity21/presentat...), targetting the cache as the CPU decrypts memory for normal operation. While it'll stop memory dumps from being effective, encrypted RAM won't be the end of dumping keys from memory, especially for patient or highly-skilled attackers.
NoInitRD 2y ago
Hello everybody, I'm the author of the article. If you have any questions, please feel free to message me on this account. I had a lot of fun working on this and I really appreciate all of the engagement.
- 1970-01-01 2y ago
  This is an excellent write-up. It's short and to the point, with links right where I would want them.
  - NoInitRD 2y ago
    Thank you so much for your compliment, and for reading it. I tried to make it as thorough and informative as possible.
shortsunblack 2y ago
See the talk "Recent TPM Security Enhancements to the Linux Kernel" by a Microsoft engineer (I find this ironic) for recent Linux TPM security enhancements. New features add some transport security. https://youtu.be/WK7NERQXh4I https://youtu.be/WK7NERQXh4I
0xml 2y ago
Related: Bypassing Bitlocker using a cheap logic analyzer on a Lenovo laptop https://news.ycombinator.com/item?id=37249623 https://news.ycombinator.com/item?id=37249623
ivraatiems 2y ago
For any exploit which relies on reading a dump of the target machine's memory, if you have physical access to said machine: How feasible is an "interposer" device that copies off or modifies data as it goes in and out of RAM? I'm thinking of something like the old "Action Replay" devices for Gameboys, which modified memory from the game cartridge as it went into the system to be loaded (or executed in the case of code) in order to cheat in games. You slotted the cartridge into the Action Replay, then slotted the Action Replay into the Gameboy. Could you do something similar between the RAM and the motherboard? Slot your ram into the device, slot the device into the motherboard, and capture the state of memory at any moment by simply watching how memory is read/written? That way, you'd save yourself the hassle of manually powering off the machine and hoping the data you need is available? I'm not an electrical engineer so maybe what I am proposing is completely infeasible - physical space and bandwidth limitations certainly seem likely. But is it possible?
- mjg59 2y ago
  In theory? Sure. In practice? Establishing DDR links involves a lot of negotiation between the memory controller and the RAM and being in a situation where you can maintain the same timings while also dumping data isn't going to be easy. I wouldn't expect this to be an off the shelf solution.
- dist-epoch 2y ago
  New AMD/Intel CPUs support transparent full memory encryption, your interposer will just see encrypted RAM data.
wh_123 2y ago
Reminds me the cold boot attack....
ibbtown 2y ago
Having a surface 5 pro laying around here, with a bitlocker encrypted disk, which turns quickly into a BSOD during boot. Do you think it could work in auch situation? I'm still waiting for an exploit to the tom to extract some pictures from the disk
- aprilnya 2y ago
  I was trying to recover data off a laptop in basically the same situation. My solution was to boot into a WinPE live USB and use bcdedit to enable safe mode (as trying to do it the normal way would ask me for the BitLocker key), which let me boot without BSODing. Though this wouldn’t work if the BSOD happens in safe mode as well…
EVa5I7bHFq9mnYK 2y ago
Why bitlocker specifically? Will GPG encryption survive if an attacker can dump the RAM at any moment while it encrypts a file?
jpalomaki 2y ago
You can make things a bit harder by locking the boot order in bios and password protecting the bios settings. Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.
dist-epoch 2y ago
Few know this, but Intel/AMD CPUs released in the last few years support transparent full memory encryption, where the RAM content is encrypted with a random key kept in the CPU memory controller and generated at reset. It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%) But it would completely prevent this attack.
- sedatk 2y ago
  As I understand, the features are called SME (Secure Memory Encryption) on AMD, and TME-MK (Total Memory Encryption-Multi Key) on Intel.
devops99 2y ago
This is exactly why there are some more "enterprise" machines out there that an arbitrary adversary with physical access can not "abruptly restart" from the outside. It's a shame that popularly used OEMs still allow "abrupt restart" to be so easy.

310 points by supermatou 2y ago

BitLocker is crazy easy to bypass if you have physical access to the device. I work IT, and had to demonstrate to our head of security, that if you just pop in a Linux USB and boot from it, the drive is completely open.

Grazester 2y ago
Then the drive wasn't encrypted!
- connicpu 2y ago
  Presumably they chose the weakest option where it can boot without a pin/password just using a key stored in the TPM.
  - dogma1138 2y ago
    Even if you are using Transparent Operation Mode then it still will not work as bitlocker will not decrypt the drive and lock itself into recovery mode if you make changes to the boot order or any other BIOS / UEFI changes. It uses secure boot and it’s pretty darn decent at detecting any form of tampering. TPM 2.0 isn’t particularly resilient against physical key extraction attacks but believe it or Microsoft did threat model this…
    - BuyMyBitcoins 2y ago
      This happened to me once. Sadly I had wiped the flash drive containing the recovery key months before the lockout without realizing it. Chide me if you must, but I certainly learned my lesson. I tried a few non-hardware exploits, even CVE-2022-41099 about WinRE but to no avail. I’m not a security pro, but I assume once it is in recovery mode lockout you’re pretty much out of luck. From what I can tell most other exploits require it to be unlocked in the first place. Even the hardware hacks seem to require a drive being in a non-lockdown state in order to sniff things during boot. That NVMe drive is just a keepsake now. I plan to frame it and put it on my wall as a memento.
      - dogma1138 2y ago
        This is why i use the key backup to OneDrive option. My threat model is a lost or stolen device or RMA/repair. If someone wants my data so badly that they’ll be able get into my OneDrive account that is protected with a passkey or a 32 char password + MFA and also have physical access to my devices let them have it. Anyone who is that determined and capable can always resort to rubber hose cryptography and I want none of that in my life.
deleted 2y ago
[deleted]
dogma1138 2y ago
You should’ve enabled bitlocker first then… The only thing that would be unencrypted is the system restore partition.
- simondanerd 2y ago
  Correct, ran into this last night. Dislocker works though: https://github.com/Aorimn/dislocker https://github.com/Aorimn/dislocker
  - dogma1138 2y ago
    Dislocker does require you to have the keys tho it’s not a bypass.
davemtl 2y ago
This sounds like BitLocker wasn't enabled on the drive. All of the laptops I've deployed with BitLocker are very good at detecting tampering and will immediately go into lockdown mode. A Linux USB most likely requires Secure Boot to be turned off to boot, if so, the TPM tamper will trigger and BitLocker will require the recovery key at next boot.
- doodlesdev 2y ago
  > A Linux USB most likely requires Secure Boot to be turned off to boot That hasn't been my experience. All the recent laptops I've owned (Dell and HP) had a default secure boot setup that allowed booting to Ubuntu and Fedora without disabling Secure Boot. In fact, nowadays even Ventoy works with Secure Boot [0], and I've managed to use it with the setting enabled on all machines I've tested, however in this case you might need to enroll the keys on the first boot, which I imagine will trigger BitLocker. Apparently what happened is that Microsoft now signs some third party certs for common Linux distributions, and some setups allow these to boot by default. However, it also looks like Microsoft wants these certs disabled by default [1], which should improve BitLocker integrity on average. Although I believe what happened in OP's situation was that BitLocker wasn't actually enabled or working, likely due to misconfiguration or lack of any. [0]: https://www.ventoy.net/en/doc_secure.html https://www.ventoy.net/en/doc_secure.html [1]: https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-bios-setting/ https://www.omglinux.com/boot-linux-modern-lenovo-thinkpads-...

3eb7988a1663 2y ago

What was the hardware on which this was running? I thought DDR5 would be more resistant to this type of RAM attack.

Arnavion 2y ago
This is not "attacking" RAM. A UEFI binary (or Linux kernel in the CCC demo which uses a different method to retain the key in memory) already has access to all the extents of physical memory. It just has to search it for the scribble leftover from the bootloader. See https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc056f9d9e10d34ca3541a55e325a8211d/app/Application.c#L119-L131 https://github.com/NoInitRD/Memory-Dump-UEFI/blob/db4888dc05... and onwards. Edit: Ah, I guess you're referring to the fact that the reboot preserves RAM contents? DDR5 doesn't change anything about that AFAIK.
- dogma1138 2y ago
  Indeed, however it should be noted that this is only a single attempt attack and which will trigger the tamper protection. Changing the boot order, making changes to the BIOS or booting from an unsigned bootloader would trigger a bitlocker lockout. This means that if you don’t get the keys on the first attempt you can’t just pass the machine back to the user and try again later since the next time it will boot it would boot into bitlocker recovery. And even if the attack is successful the user will still be aware that something did happen so you are still better off with other physical attacks if they are still possible.
  - mjg59 2y ago
    Why? You're not booting Windows again, and restoring the secure boot state and boot order to the original values will result in the PCR values being what they were before, so what's changing that would force recovery mode?
    - dogma1138 2y ago
      The TPM tracks the state of the secure boot and the bios, that log is stored in the TPM itself the next time you’ll try to boot into windows it will see that something happened and bitlocker will lock itself out. Do this experiment. Boot into any Linux live CD on a machine with bitlocker enabled. Reboot and see what happens.

mjg59 2y ago

This is entirely defeated by https://trustedcomputinggroup.org/resource/pc-client-work-group-platform-reset-attack-mitigation-specification/ https://trustedcomputinggroup.org/resource/pc-client-work-gr... - if enabled, if the OS isn't cleanly shut down (giving it an opportunity to wipe encryption keys) the firmware will pause to wipe RAM before booting anything else on next boot. Does Windows not make use of this, or did the tested system not implement it?

cyberax 2y ago
This still won't prevent yoinking the entire RAM modules and dumping them offline. Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die.
- bangaladore 2y ago
  > This still won't prevent yoinking the entire RAM modules and dumping them offline. Theoretically no, but realistically I doubt even intel agencies can pull this off. > Ideally, the keys should just remain inside the SRAM cache on the CPU, never even going outside of the CPU die. The real solution is putting the keys somewhere with a guarantee they will be gone prior to possibly executing untrusted code. In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records.
  - bri3d 2y ago
    > Theoretically no, but realistically I doubt even intel agencies can pull this off. For older LPDDR3 it's completely practical, see https://www.youtube.com/watch?v=nTvIQDe0rQU https://www.youtube.com/watch?v=nTvIQDe0rQU . It definitely gets harder with newer systems, though. > In my mind the only real solution is UEFI APIs to support this (or wiping the ram as shown here). But then you have to trust the UEFI vendors which don't exactly have stellar track records. This already exists: it's the MOR bit and it's supposed to be in play here. I actually think that having a CPU scratchpad key area which is guaranteed to be wiped across any reset action is a much better idea than trusting any dumpster fire UEFI implementation of anything, ever. At least you're trusting a few CPU vendors with something you can audit that way, rather than a million different cobbled-together junky firmware blobs.

jandrese 2y ago

Fundamentally I don't understand BitLocker's security model. In most installs it seems like you power on the machine by pressing the power button and it boots into Windows. So if someone steals you machine with an encrypted hard drive they need to...just turn it on? That can't be right, but at the same time I have no idea how this particular attack is defeated. I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that, but it seems like the machine is going to give up the key pretty easily regardless. With LUKS it at least has a password prompt to unlock the drive.

bri3d 2y ago
> I have to assume the traffic over the SPI bus is encrypted so the key can't just be dumped like that It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around. > With LUKS it at least has a password prompt to unlock the drive. Configuration dependent. You can set up Linux to do the same thing as Windows here (I have my home video-security server set up this way, as it needs to reboot silently - I know that I'm vulnerable to warm/coldboot attack and software attack surface, but at least if someone yoinks the drive I'm safe), and Windows can also be configured to prompt for a password or use PIN-authenticated TPM sealed keys. > Fundamentally I don't understand BitLocker's security model. Minus the parameter encryption / bus-sniffing issue, it moves the boundary from "anyone can read your drive" to "someone needs to either perform a platform-level attack to access the contents of memory, or hack whatever services are running at the login screen to read your drive." It's a decent security improvement, actually, because it protects very well against stuff like "someone stole our financial data off of a random recycled hard drive."
- raron 2y ago
  > It's not. For some reason, Microsoft don't use TPM parameter encryption, even though every year or two some security researcher or another comes up with another stunt TPM-sniffing device to parade around. AFAIK it is useless, there is no way the TPM could authenticate the CPU. You could always desolder the TPM chip, send the correct data for updating PCRs and get the sealed key.

maxo133 2y ago

Too bad the author did not provide hardware specs. Such attack is even harder on DDR4 and DDR5 memory and most publications refer to legacy ram such as DDR3 > 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. So what is this? It was supposed to be memory attack and he's dumping the keys after someone unlocked it and it's booting? So this is just another theoretical attack where perfect conditions must be met.

bri3d 2y ago
This attack has nothing to do with the memory type; memory is never made cold or allowed to decay. The system is hot-restarted into UEFI. Ideally no memory refreshes are skipped. I do wish they provided the hardware specs too, though, as this reflects an incorrect UEFI platform implementation of MOR.
- maxo133 2y ago
  You are right, but i still have no idea what is the point of this article. The guy unlocked the bitlocker, then restarted PC just before login screen appeared. He said that's when he had most success. What sense does it make to restart and start looking for key in memory, when bitlocker has been just unlocked.
  - bri3d 2y ago
    > What sense does it make to restart when bitlocker has been just unlocked. You steal a laptop. You turn on the laptop. You reboot it into UEFI and steal the keys. This is bad for BitLocker. Ideally this is not possible because the MOR bit should cause the keys to be erased by the platform initialization before boot-from-USB is possible.
  - mjg59 2y ago
    I steal your Windows laptop. I want your data. I don't have your credentials, so can't login to Windows. I let your laptop boot to the point where Bitlocker is automatically unlocked, perform a hard reboot, dump the RAM, extract the keys, and can now decrypt your drive and extract your data.

jansommer 2y ago

I think you get the biggest advantage from BitLocker when you use TPM (PCR 7+11) with a PIN. That should mitigate the exploit because the FVEK should never be read without the PIN, and if BitLocker does it right (which I think it does) too many wrong PIN's results in the TPM going into dictionary attack lockout mode. Now I've been trying for months to do the same for Linux. There's systemd-cryptsetup/cryptenroll, but it's only for LUKS and I'm trying to encrypt a few sensitive directories on a super slow internal eMMC with fscrypt (keys for secure boot and /home). The TPM is _EXTREMELY_ hard to code for when things go beyond the basics: 1. Bind to PCR 7 2. Bind to changing PCR 11 (changes whenever the kernel, init, cmdline etc. is updated) 3. Use a PIN - but not the AuthValue, because I want to use the same authorization policy for resetting the DA lockout counter on login, and also have a long password/AuthValue for resetting the counter manually. 4. Make it all work with PCR 11 signatures and public keys provided by systemd-stub. Maybe this isn't the right place to ask, but there's almost nothing but basic TPM guides out there, so if you're an expert I could really use your help. It's just for a personal project, but I'll write about it once I'm done - if I ever figure it out!

varispeed 2y ago
Isn't TPM just a honeypot of sorts? It seems strange to me that after successful open source encryption software, there was a shift to TPM, like you'll have a notion of super secure storage provided by big corporations and you should just not worry about it and not question. Surely there must be a backdoor access for three letter agencies to just download all the pins and passwords and then take a dip in the data, no worries.
- jansommer 2y ago
  Should be good enough for a personal tablet used for mail and browsing. If I drop it and someone curious finds it, I'd like to make it impossible for them to extract anything useful.
- cheschire 2y ago
  I prefer to think of TPM as equivalent to the chip in a smart card.

slicktux 2y ago

Why are more people not using self encrypting drives?

varispeed 2y ago
Ages ago I had an external drive that had a controller with built in keys that encrypted the data in and out. Problem was that the controller was poorly made and one time upon connecting to the PC, the controller chip died and so the keys with it. It was impossible to recover the data, but the disk itself was perfectly fine. I bought a damaged drive with working controller and swapped it out and my drive worked again, however I had to format it, because new board had different keys. Since then I preferred to use software encryption and steered clear of drives that use any sort of hardware encryption. The risk of losing data was not worth it.
- arghwhat 2y ago
  All SSD's with OPAL are always encrypting your data. "Enabling" the feature just means that you change from a random on-device key to a key encrypted with your passphrase. (Whenever you wipe the drive through OPAL, you're just overwriting the key.)
TiredOfLife 2y ago
After this https://borncity.com/win/2018/11/06/ssd-vulnerability-breaks-bitlocker-encryption/ https://borncity.com/win/2018/11/06/ssd-vulnerability-breaks... Microsoft patched out support for self encrypting drives.
- arghwhat 2y ago
  Quite dumb considering this was an issue with pretty much a single, low-cost consumer vendor (Crucial?). If nothing else, use it in combination - the encryption of OPAL drives is always active anyway, all that changes when the feature is "active" is whether the key is stored as-is on the controller or whether its protected by a passphrase.

PhilippGille 2y ago

Related 38C3 talk about Windows 11 BitLocker bypass: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-without-a-screwdriver https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

DEEP-MELTDOWN 2y ago

[dead]

layer8 2y ago

It’s fairly well known that BitLocker only really protects a computer that is turned off, and also only if you configure BitLocker to require a boot password [0]. [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_enough https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

medlazik 2y ago

Step 3: Boot from the USB Device Game over, any laptop with data worth stealing will have this disabled in bios

totalizator 2y ago
Valid point but what about the reality? Imagine typical Evil Maid attack but within a workplace, as a cleaning staff. Game over.

RachelF 2y ago

Windows has a proposed memory encryption option along with memory compression. Both Intel and AMD are working on embedding this into their CPUs. However, the target use appears to be servers with multiple VMs, not laptops.

p_ing 2y ago
Intel has this via their Total Memory Encryption feature today. Yes, geared towards VMs in the Windows ecosystem. https://techcommunity.microsoft.com/blog/windowsosplatform/multi-key-total-memory-encryption-on-windows-11-22h2/3683043 https://techcommunity.microsoft.com/blog/windowsosplatform/m... Memory compression has been around for ages, at least since Windows 10 RTM. All major operating systems have implemented this feature -- it has no relation to security, though.
jeroenhd 2y ago
Microsoft is moving more and more to virtualisation based security, including the ability to run “enclaves” for protecting specific pieces of software: https://learn.microsoft.com/en-us/windows/win32/trusted-execution/vbs-enclaves https://learn.microsoft.com/en-us/windows/win32/trusted-exec.... I wouldn't be surprised if they'll soon leverage encrypted “VMs” as a means of storing secrets like these. All we need is wide general hardware availability on consumer platforms. That said, previous side-channel attacks on CPUs have shown it possible to attack encrypted memory (https://www.usenix.org/conference/usenixsecurity21/presentation/li-mengyuan https://www.usenix.org/conference/usenixsecurity21/presentat...), targetting the cache as the CPU decrypts memory for normal operation. While it'll stop memory dumps from being effective, encrypted RAM won't be the end of dumping keys from memory, especially for patient or highly-skilled attackers.

NoInitRD 2y ago

Hello everybody, I'm the author of the article. If you have any questions, please feel free to message me on this account. I had a lot of fun working on this and I really appreciate all of the engagement.

1970-01-01 2y ago
This is an excellent write-up. It's short and to the point, with links right where I would want them.
- NoInitRD 2y ago
  Thank you so much for your compliment, and for reading it. I tried to make it as thorough and informative as possible.

shortsunblack 2y ago

See the talk "Recent TPM Security Enhancements to the Linux Kernel" by a Microsoft engineer (I find this ironic) for recent Linux TPM security enhancements. New features add some transport security. https://youtu.be/WK7NERQXh4I https://youtu.be/WK7NERQXh4I

0xml 2y ago

Related: Bypassing Bitlocker using a cheap logic analyzer on a Lenovo laptop https://news.ycombinator.com/item?id=37249623 https://news.ycombinator.com/item?id=37249623

ivraatiems 2y ago

For any exploit which relies on reading a dump of the target machine's memory, if you have physical access to said machine: How feasible is an "interposer" device that copies off or modifies data as it goes in and out of RAM? I'm thinking of something like the old "Action Replay" devices for Gameboys, which modified memory from the game cartridge as it went into the system to be loaded (or executed in the case of code) in order to cheat in games. You slotted the cartridge into the Action Replay, then slotted the Action Replay into the Gameboy. Could you do something similar between the RAM and the motherboard? Slot your ram into the device, slot the device into the motherboard, and capture the state of memory at any moment by simply watching how memory is read/written? That way, you'd save yourself the hassle of manually powering off the machine and hoping the data you need is available? I'm not an electrical engineer so maybe what I am proposing is completely infeasible - physical space and bandwidth limitations certainly seem likely. But is it possible?

mjg59 2y ago
In theory? Sure. In practice? Establishing DDR links involves a lot of negotiation between the memory controller and the RAM and being in a situation where you can maintain the same timings while also dumping data isn't going to be easy. I wouldn't expect this to be an off the shelf solution.
dist-epoch 2y ago
New AMD/Intel CPUs support transparent full memory encryption, your interposer will just see encrypted RAM data.

wh_123 2y ago

Reminds me the cold boot attack....

ibbtown 2y ago

Having a surface 5 pro laying around here, with a bitlocker encrypted disk, which turns quickly into a BSOD during boot. Do you think it could work in auch situation? I'm still waiting for an exploit to the tom to extract some pictures from the disk

aprilnya 2y ago
I was trying to recover data off a laptop in basically the same situation. My solution was to boot into a WinPE live USB and use bcdedit to enable safe mode (as trying to do it the normal way would ask me for the BitLocker key), which let me boot without BSODing. Though this wouldn’t work if the BSOD happens in safe mode as well…

EVa5I7bHFq9mnYK 2y ago

Why bitlocker specifically? Will GPG encryption survive if an attacker can dump the RAM at any moment while it encrypts a file?

jpalomaki 2y ago

You can make things a bit harder by locking the boot order in bios and password protecting the bios settings. Not sure how much this helps against a determined attacker, but it's easy and inconvenience is minimal in most cases.

dist-epoch 2y ago

Few know this, but Intel/AMD CPUs released in the last few years support transparent full memory encryption, where the RAM content is encrypted with a random key kept in the CPU memory controller and generated at reset. It's typically disabled in BIOS, since it has a small memory performance penalty (0.1%->1%) But it would completely prevent this attack.

sedatk 2y ago
As I understand, the features are called SME (Secure Memory Encryption) on AMD, and TME-MK (Total Memory Encryption-Multi Key) on Intel.

devops99 2y ago

This is exactly why there are some more "enterprise" machines out there that an arbitrary adversary with physical access can not "abruptly restart" from the outside. It's a shame that popularly used OEMs still allow "abrupt restart" to be so easy.