from Hacker News

Windows BitLocker – Screwed Without a Screwdriver

by lima on 1/18/25, 12:31 PM with 96 comments

  • by wat10000 on 1/18/25, 3:00 PM

    I can’t understand this design. You should derive the disk’s encryption key from the user’s login password. You have a small, secure program that presents a login screen on boot. It takes the password you input and uses it to unlock the disk. It passes the username and password along to the OS so that it can take you right into your account after it boots.

    As long as your encryption is decent, this makes it fundamentally impossible to read the drive from a turned-off state without knowing or cracking the password.

  • by layer8 on 1/18/25, 9:27 PM

    This is all correct, but it’s been fairly well known since over 15 years ago that BitLocker only really protects a computer if you configure BitLocker to require a pre-boot password, and also only after you turned off the computer [0].

    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

  • by yread on 1/18/25, 11:46 PM

    > Okay, so now we know how to edit a BCD file. But what do we put in there? This was the trickiest part of this exploit chain, as you get very little feedback when things go wrong. Recall the bug we are trying to reproduce: We want the bootloader to attempt to boot from our BitLocker partition, fail, and then trigger a PXE soft reboot into our controlled OS.

    > The easiest way to get this working has three parts:

    > Get the original BCD from the victim’s device. This ensures the configuration matches the specific partition GUIDs. You can do that by shift-rebooting Windows, going “Troubleshoot > Advanced options > Command Prompt”, mounting the boot partition, and copying its contents to a USB drive. Or, be more advanced and use an SMB mount, if you don’t have USB access.

    Do I understand it correctly that to bypass the encryption you need access to the decrypted contents of the encrypted disk? Did the original exploit guess the layout of the partitions instead?

  • by laurensr on 1/18/25, 4:36 PM

  • by kopirgan on 1/19/25, 12:44 AM

    I had posted this question in another thread re TPM on Linux and the answer is here after a couple of days.

  • by lostmsu on 1/18/25, 3:34 PM

    This is easily mitigated by requiring password to change boot order.

  • by lostmsu on 1/18/25, 3:37 PM

    Was BIOS fully updated as well?

    Do new devices still suffer from the issue?

  • by varispeed on 1/18/25, 4:19 PM

    How these work on a headless server where you cannot enter password upon boot? If someone steals the server can they read data?

  • by antithesis-nl on 1/18/25, 3:47 PM

    TL;DR, like all secure-boot disk-encryption outrage-bait articles of late: if you're really concerned about any of this, set a TPM PIN and/or explicit disk encryption password.

  • by kylebenzle on 1/18/25, 3:45 PM

    NSA and CIA do NOT want this info to be public. Surprised OP hasn't gotten a call yet to shut it down...