back to article SHIFT + F10, Linux gets you Windows 10's cleartext BitLocker key

Microsoft is working on a patch for a bug or feature in Windows 10 that allowed access to the command line and, using a live Linux .ISO, made it possible steal BitLocker keys during OS updates. The command line interface bypasses BitLocker and permits access to local drives simply by tapping the Shift and F10 keys. BitLocker …

Page:

  1. Anonymous Coward
    Anonymous Coward

    No other place to put this

    The El Reg commenting platform is now hopelessly broken on Chrome on Android which, as you endlessly report, is most of everybody. How do you not know this? It has been a week at least.

    1. Anonymous Coward
      Anonymous Coward

      Re: No other place to put this

      Use Firefox instead? (With Ublock Origin - makes for a much nicer browsing experience).

    2. This post has been deleted by its author

      1. Anonymous Coward
        Anonymous Coward

        Re: No other place to put this

        you lot are supposed to be at work in the I.T industry.

        surely you have proper computers to read el Reg from?

        I find a 21" screen for better than a 4" screen for reading on

        1. M man

          Re: No other place to put this

          ....or three

      2. davidp231

        Re: No other place to put this

        "Out of curiosity, how? Posted from Chrome on Android."

        How? Simple, it's not Chrome.

        Chrome has only one use in my eyes, and that's for watching Netflix under Linux. First thing I do when setting up a droid phone is disable all the bloatware - Chrome included.

        1. Lord_Beavis
          Linux

          @ davidp231 Re: No other place to put this

          "Chrome has only one use in my eyes, and that's for watching Netflix under Linux."

          I'm using Firefox (with uBlock Origin) and the User Agent Overrider and this in the preferences:

          Linux / Chrome 53: Mozilla/5.0 (X11; Ubuntu; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/53.0.2785.34 Safari/537.36

    3. Marco Fontani

      Re: No other place to put this

      The El Reg commenting platform is now hopelessly broken on Chrome on Android

      Would you be able to share more details about this? e-mail webmaster@ please and we'll see how we can help!

  2. Anonymous Coward
    Anonymous Coward

    This, because we can't overwrite files that are in use.

    Which is the prime reason the updates have to be applied during boot up anyway. And how does it know the passphrase to unlock the disk to perform those updates?

    Maybe I'm a little naïve about how BitLocker works, but if it can just unlock the drive at will for OS updates, then I have serious questions about how truly secure it is.

    1. Anonymous Coward
      Anonymous Coward

      Re: This, because we can't overwrite files that are in use.

      Your disk is not actually encrypted using your password... Your disk is encrypted with a symmetric encryption key, that key is then encrypted again, and then your password encrypts THAT key.

      When bitlocker is disabled, the symmetric key used to unlock the disk key is stored in plain text in a special partition on the boot. This allows it to unlock the drive without your password, until that key is then deleted.

      It's a fairly terrible oversight... Here's MS's own technet article:

      "Exposing the drive master key even for a brief period is a security risk, because it is possible that an attacker might have accessed the drive master key and full drive encryption key when these keys were exposed by the unencrypted key."

      1. AMBxx Silver badge
        Black Helicopters

        Re: This, because we can't overwrite files that are in use.

        But it needs you to have the PC rather than a remote hack.

        Sounds almost intentional - Microsoft's offering to government agencies?

        1. DJ Smiley

          Re: This, because we can't overwrite files that are in use.

          No you don't.

          You need to remotely have the system request the password of a user who has the ability to create the clear text key, you then save that key, get to the system whenever you want (and however you want); put the key back; reboot it.

          It reboots back up, and unencrypts the drive for you while it does it.

        2. Mage Silver badge

          Re: Physical Access

          All security bets are off anyway with local / physical access.

          It's only an issue if it's via the LAN.

          1. Prst. V.Jeltz Silver badge

            Re: Physical Access

            I thought encryption was pretty much FOR local access - ie stolen / lost laptops

            If you're accessing a machine via LAN you've probably completely sidestepped the drive encryption.

            1. M man

              Re: Physical Access

              That was my though....What else IS bitlocker for?

        3. John H Woods Silver badge

          Re: This, because we can't overwrite files that are in use.

          "But it needs you to have the PC rather than a remote hack." -- AMBxx

          The main purpose of whole disk / volume encryption is to protect the contents from people who have gained physical access to the computer.

      2. Anonymous Coward
        Anonymous Coward

        Re: This, because we can't overwrite files that are in use.

        Your disk is not actually encrypted using your password... Your disk is encrypted with a symmetric encryption key, that key is then encrypted again, and then your password encrypts THAT key.

        Yeah, I figured it'd be along those lines… whether they store the passphrase or the key unencrypted is immaterial, all the knowledge needed to access that key is available on-disk in a form that allows unauthorized access (by the OS or other parties).

        They could encrypt it 10 or 20 times if they wanted … all that is blown the moment they store any one of those keys or the passphrase in cleartext.

      3. The Man Who Fell To Earth Silver badge
        WTF?

        Re Mark Randall: This, because we can't overwrite files that are in use.

        "... until that key is then deleted."

        I hope you really mean "... until that key is then physically over written a bazillion times." Otherwise, it's still there for anyone to find if they know where to look.

      4. Hans 1
        FAIL

        Re: This, because we can't overwrite files that are in use.

        This is even worse, ever heard of undelete ?

        What this means is that bitlocker is basically broken. Steal laptop with WIndows 10, wait for the upgrade, plug it in, wait for it to get the upgrade, get key -> data!

        I guess it would probably be easier to boot Linux, use data-recovery to recover the key on that other partition -> decrypt main partition -> data! Testdisk, anybody ? Ok, if bios is protected, as should be, plug drive into your Linux box.

        I wonder if undelete would do it from within another windows box ?

        Both last two cases, using data-recovery, just need a laptop that has been upgraded to a new Windows 10 build in the past. I guess Windows 8.x had the same feeble-minded vuln, so any Windows 8+ laptop, they would not implement encryption without the possibility of easily gaining access to the data, surely a federal requirement drawn up in one of Murika's secret courts, or simply dumb-c*nt devs, after all, they are Microsoft for a reason™!

        1. Anonymous Coward
          Anonymous Coward

          Re: This, because we can't overwrite files that are in use.

          If the laptop was cold when this happened, it would still be secure, as you could not boot into the operating system to allow it to start the update process. The master key is usually only exposed when the system is fully booted.

          If the system is turned on at the time, it's different.

      5. joed

        Re: This, because we can't overwrite files that are in use.

        It may be a terrible oversight but it may also have no remedy. It possible that disabling bitlocker is required because the actual upgrade is performed in WinPE (that can't get the key from TPM) or maybe because major changes to the system can result in bitlocker lockout (where manual entry of the key is required). So Windows suspends the BL for the upgrade and resumes it after next boot to Windows (since 8 it's SOP anyway) when new system can re-establish trust with TPM (and prevent lockout at the next reboot). Just a guess, but I'm curious if the same process would take place in SP1 update to Windows 7 and 8.1 upgrade from 8.

    2. Dazed and Confused

      Re: This, because we can't overwrite files that are in use.

      The W10 1607 update seems to have real problems with drive encryption generally. This laptop and the one on my desk use HP's drive encryption and now everyday I get a nag from Windows saying an update failed. If I go through the fix it process then eventually it comes back and says that I need to remove the encryption SW, which means I need to decrypt the whole disk then once that has happened I can remove the SW and then I can update after which I would need to reinstall the encryption SW and re-encrypt my disk. Yeah like thanks guys. Just pull your F*&^ing fingers out and sort this, it isn't funny.

      1. Sandtitz Silver badge
        Unhappy

        Re: This, because we can't overwrite files that are in use. @Dazed

        This laptop and the one on my desk use HP's drive encryption and now everyday I get a nag from Windows saying an update failed. If I go through the fix it process then eventually it comes back and says that I need to remove the encryption SW, which means I need to decrypt the whole disk then once that has happened I can remove the SW and then I can update after which I would need to reinstall the encryption SW and re-encrypt my disk.

        HP has an advisory document regarding this problem.

        In short: MS has brought about a security change and HP is unwilling to support the Drive Encryption component any longer, and it will never work with 1607, aka Win10 Anniversary Update.

        It's a real pity since the HP Client Security was easy to use and integrated all the way to BIOS and supported pre-boot authentication with fingerprints and smart cards. (and still does, but losing the drive encryption is a big blow).

        My guess is that since HP has licensed the encryption part from a 3rd party they would have had to re-license a newer version and it wasn't financially justified...

        1. Dazed and Confused

          Re: This, because we can't overwrite files that are in use. @Dazed

          > HP has an advisory document regarding this problem.

          Oh B*&^^&*r

          > but losing the drive encryption is a big blow

          You can say that again.

          Pity they didn't tell me.

          Pity they didn't tell me before I bought this laptop in June. It's a EliteBook Folio 1040 G3, which isn't on the list, but I assume it's being clobbered by the same issue.

          Thanks

          1. Dazed and Confused

            Re: This, because we can't overwrite files that are in use. @Dazed

            > Oh B*&^^&*r

            Oh double triple B*&^^&*r

            That advisory has just been followed up with. c05348215

            Saying that you can't use HW encryption with bitlocker.

            Now I just want to scream!

    3. bombastic bob Silver badge
      Devil

      Re: This, because we can't overwrite files that are in use.

      "Which is the prime reason the updates have to be applied during boot up anyway."

      In the POSIX world, a directory entry is simply a pointer to an INODE, which represents "the file". An 'overwrite' of a file that's in-use simply points to a different INODE. Then, subsequent 'opens' of that file use the NEW version (and not the old one). The old inode is kept around on the file system until the last reference to it closes, and then it gets deleted. [this would keep running processes from crashing, for example, if you swapped in a new shared lib before restarting them, and when they re-start, they automatically use the NEW one].

      Micro-shaft, on the other hand, ENCOURAGES multiple processes to be able to directly muck with the same file, using a sharing system that MOST LIKELY creates a LOT of inefficiency inside the kernel.

      Hence, file I/O on a POSIX system appears to be FASTER than on an equivalent windows system [at least, that's been MY experience].

      I sometimes refer to the WORST of this as "paranoid cacheing", i.e. the apparent assumption that "something came along" and changed what was on the hard drive behind your back, and now you have to re-re-read the same block from the physical file, again, even though you just wrote it BACK to the file a few milliseconds ago... [seems to happen most often wirh the registry, most likely due to excessive 'layering' and ".Not"-ishness]

      .So, *NOW*, this file-system philosophy of Micro-shaft's is *BITING* *THEM* in the backside, with respect to the hoops they have to jump through when Bitlocker is in use.

      /me is now thinking of some terms involving a circle, a cluster, and 'Situation Normal'

  3. Daniel B.
    FAIL

    All those MS apologists are hiding

    This is almost like the Linux boot vulnerability ... except this one can actually expose the master keys and thus open up your entire "encrypted" filesystem. Way to go, MS!

    1. Anonymous Coward
      Anonymous Coward

      Re: All those MS apologists are hiding

      Yep, 'least with the Linux one, the partitions remained encrypted.

    2. Anonymous Coward
      Anonymous Coward

      @Daniel

      Well, this isn't something limited to Microsoft you know. Linux & BSD have also had their fair share of local exploits.

      Which is why I think your comment isn't fully fair. I mean: no computer is safe when an attacker has physical access. Including those which have applied HD encryption.

      1. Dazed and Confused

        Re: @Daniel

        I mean: no computer is safe when an attacker has physical access. Including those which have applied HD encryption.

        The data on your disk should be safe if the encryption is any good (ie doesn't have a May door). That's the whole point of encrypting the thing.

        1. Anonymous Coward
          Anonymous Coward

          Re: @Daniel

          Usually, that is true as long as the computer is off. Once it is on, and something needs to access files, keys needs to be somewhere readable. The issue here is they are in clear text and accessible outside the upgrade process.

          1. Anonymous Coward
            Anonymous Coward

            Re: @Daniel

            You both have a point.

            There should be no access to encrypted storage without the user permitting it which, for reasons of update and patching, means that it would be best if the system is separated from the user data (which is easy in Linux systems that use a separate partition for /home, but that's not a common default).

            On the other hand, you will also need to protect system files, and only undo that protection come patching time which is then a separate process. That said, I prefer to see the patching rather than let it automate overnight, and that's independent of platform, Linux, OSX or Windows.

      2. bombastic bob Silver badge
        FAIL

        Re: @Daniel

        "Linux & BSD have also had their fair share of local exploits."

        NONE of which involved *FORCED* *UPDATES* as I recall... and when it happens to Linux or BSD, you get *HEADLINES* like plane crashes vs car crashes... [and Micro-shaft would be the 'car crash' equivalent - ANOTHER vulnerability? Eh, no surprises...]

  4. Ken Hagan Gold badge

    Whole-disk encryption is silly anyway

    The OS files (which are the ones that MS wanted to update in this case) are not secret. The ones you actually want to protect are the per-user files, which MS never need to update and so they can be encrypted with a mechanism that doesn't need to have a back-door designed into it.

    Traditionally, the objection was that Windows failed miserably to separate system files and user data, but that's actually been getting better (slowly) over time. These days, I suspect that *most* Windows apps can tolerate a setup where directories are either per-user-encrypted or read-only-for-that-user.

    1. Paul Crawford Silver badge

      Re: Whole-disk encryption is silly anyway

      Not so silly - while the OS files & configurations may not be secret, whole disk encryption prevents an "evil maid" style of attack from modifying them because you have to decrypt the disk in the first place.

      Assuming your password is not known to the main, of course...

      1. Anonymous Coward
        Anonymous Coward

        Re: Whole-disk encryption is silly anyway

        "Not so silly - while the OS files & configurations may not be secret, whole disk encryption prevents an "evil maid" style of attack from modifying them because you have to decrypt the disk in the first place."

        Yes, but TBH, you'll still need physical access to the machine unbeknownst to its owner which isn't the domain of script kiddies or your normal hacker, we're talking espionage here. And of course once you have the machine + the skills of a government agency behind you then all bets are off since installing special hardware to intercept data is well within their abilities.

      2. Anonymous Coward
        Anonymous Coward

        Re: Whole-disk encryption is silly anyway

        Not so silly - while the OS files & configurations may not be secret, whole disk encryption prevents an "evil maid" style of attack from modifying them because you have to decrypt the disk in the first place.

        Ah, but therein lies a little problem: whole disk encryption is unhelpful when the specific user does not shut down the system, but merely puts it into suspend/sleep mode. At that point, you have the equivalent of an open safe in an office with a locked door: far less protection than you think. That's not just the case with Windows, but also with OSX, sorry, macOS FileVault, and there is no warning to end users that this is the case (or an option to disable sleep in favour of shutdown, which swaps a risk of disclosure with one for lost work because you were away from your system too long - you can't really win).

        I prefer the Linux idea of having a separately encrypted /home/user partition, but even that doesn't cope well with sleep/wake cycles insofar that it leaves the crypto door open until shutdown.

        In short, crypto is fine, but you still need to have some idea of what does what to make the right choices and get the benefit from it that you require for your specific needs. It's not something you can just hand to Joe User who needs to keep things safe, a bit of discussion and education is still needed.

        1. Anonymous Coward
          Anonymous Coward

          Re: Whole-disk encryption is silly anyway

          If your "evil maid" shows up, it's too late. The only time she comes around is when you have given her a home in the environment ,and to do that, you've already decrypted the environment.

          If you need to encrypt an entire disk, you really just need better plain old directory/partition management, it's just that simple. Of course this is easy to say for a UNIX user, but as mentioned, Microsoft users are stuck with file management thoughts like "Why the fuck is it there?" or "Where the hell did it go?" or "It looks like a directory, so why isn't it?"

        2. Daniel B.
          Boffin

          Re: Whole-disk encryption is silly anyway

          That's not just the case with Windows, but also with OSX, sorry, macOS FileVault, and there is no warning to end users that this is the case (or an option to disable sleep in favour of shutdown, which swaps a risk of disclosure with one for lost work because you were away from your system too long - you can't really win).

          You haven't googled it, then.

          pmset -a hibernatemode 25

          pmset -a destroyfvkeyonstandby 1

          Which indeed changes the "sleep" to "hibernate" and destroys the FV key from memory. Thus the RAM won't have it, and the swap file with the RAM state won't have it either. Sure, you need to enter your password on "wake up" but it's worth the extra security.

          1. Anonymous Coward
            Anonymous Coward

            Re: Whole-disk encryption is silly anyway

            You haven't googled it, then.

            pmset -a hibernatemode 25

            pmset -a destroyfvkeyonstandby 1

            Thanks for that, hadn't gotten round to look at that last loophole but you saved me time by putting me on the right path (and a Godawful amount of Googling because there's a bit more to it due to powernap settings and other challenges but I think I've caught all of it now :) ).

            And no, I won't use a Yubikey. I prefer adding OTP capability because they're not dependent on having any physical to the hardware..

      3. oldcoder

        Re: Whole-disk encryption is silly anyway

        Wasn't that the purpose of Microsoft signed binaries? The "modified" binaries shouldn't work...

        I guess this is just another Microsoft screwup.

        The standard substandard Microsoft insecure security...

    2. Crazy Operations Guy

      Re: Whole-disk encryption is silly anyway

      And that would be (one reason) why /home should always be a separate partition. I do the same thing on all my application directories for my servers.

      Each parition is encrypted with a separate password. I have the system set up so that /, /bin, /dev, /etc, /root, /sbin, and a /util (Which contains scp, curl, and a few other utilities). That way the server admins can patch, upgrade, and manage the system and only need to know a single de-cryption password and even knowing the root pass, do not have access to sensitive data. Application owners, on the other hand, only know the passwords to decrypt their password's partition and neither the root or / decryption password.

      Each application is chroot'ed with its own set of directories (such as /etc, /sbin, /var, and so on), so the application owners can do what they need to their partition without affecting anything else.

  5. RIBrsiq
    Facepalm

    Security is a trade-off. Usually with convenience.

    I would appreciate it if Microsoft didn't decide to not inconvenience me when I have clearly elected to be inconvenienced. Please assume that I know what I am doing, and have good reason to do it when I use things like BitLocker, etc.

    I mean, just ask for the bloody key on boot time, same as you would in any other case the machine is rebooted. What's wrong with that, Microsoft...? What's wrong with that?

    1. Roger Lipscombe

      What's wrong with that, Microsoft...?

      Requiring the password be entered again during the upgrade process means that you can't do remote (unattended) upgrades, which is kinda important for companies managing tens of thousands of Windows desktops.

      1. DJ Smiley

        Re: What's wrong with that, Microsoft...?

        Anyone doing remote/unattended upgrades should be capable of reading the articles on how to do this manually, create a clear key and save it to the drive - along with the appropriate warnings about doing so (I'd be worried if anyone has un-monitored access to their physical servers anyway).

        Doing it by default is just plain ignorant, stupid and possibliy malicious.

        It's not impossible for me to have dns claim my server is updates.microsoft.com (or whatever the address is now) and tell windows I have a 'new upgrade' package for it to install. Suddenly this looks very dodgy indeed.

        1. Anonymous Coward
          Anonymous Coward

          Re: What's wrong with that, Microsoft...?

          "Anyone doing remote/unattended upgrades should be capable of reading the articles on how to do this manually, create a clear key and save it to the drive - along with the appropriate warnings about doing so"

          Rinse and repeat 10K times. Err, no thanks.

          1. Anonymous Coward
            Anonymous Coward

            Re: Rinse and repeat 10K times. Err, no thanks.

            Hi, my name's Al, I'm from a well known vendor of Virtual Desktop Infrastructure.

            I believe I have a cost-saving and labour-saving opportunity for you.

            Call me.

            1. Steve Aubrey
              Happy

              Re: Rinse and repeat 10K times. Err, no thanks.

              "Hi, my name's Al, I'm from a well known vendor of Virtual Desktop Infrastructure.

              I believe I have a cost-saving and labour-saving opportunity for you.

              Call me."

              My number's 867-5309. You can call me, Al.

              - Jenny

          2. Daniel B.

            Re: What's wrong with that, Microsoft...?

            Rinse and repeat 10K times. Err, no thanks.

            You mean it can't be done through GPO?

          3. Kiwi
            FAIL

            Re: What's wrong with that, Microsoft...?

            Rinse and repeat 10K times. Err, no thanks.

            So you'd rather have 10k of your machines have an easily recoverable clear-text decryption key sitting on the HDD?

            Oh, of course. You promote MS products. You obviously have no clue what "security" is.

            (El reg, can we have a "the previous poster is a completely clueless idiot" icon please?)

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like