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 …

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.

4
4
Anonymous Coward

Re: No other place to put this

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

11
0

This post has been deleted by its author

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

11
0

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
1
Bronze badge

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.

2
0

Re: No other place to put this

....or three

0
0
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

0
0
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.

10
3

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."

20
0
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?

13
5
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.

6
0
Silver badge

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.

7
0

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.

0
1
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.

0
6
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.

19
0
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.

8
0
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.

3
1
Silver badge
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™!

2
2
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'

7
4

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.

1
0
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...

2
0
Bronze badge

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.

0
0
Silver badge

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
0

Re: Physical Access

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

0
0
Silver badge

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!

0
0
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!

12
3
Anonymous Coward

Re: All those MS apologists are hiding

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

8
0
Silver badge

@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.

6
13
Silver badge

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.

15
0
LDS
Silver badge

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.

4
0
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.

4
0
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
4
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.

9
1
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...

5
0
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."

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.

1
0
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.

5
0
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?"

0
0
Silver badge

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.

0
0
Silver badge

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
0
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.

2
0
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..

0
0
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?

9
0

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.

5
1

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.

4
0
Silver badge

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.

0
6
Anonymous Coward

Re: "dns claim my server is updates.microsoft.com"

"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."

Oh no. Surely not? You're not suggesting.... no, it's unthinkable.

Somebody please tell me there's more (preferably with a little bit of detail of *what* the "more" is).

0
0
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
0
Anonymous Coward

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

They could have implemented their bitlocker network unlock feature in the upgrade process. So when its connected to the corp network, then no password, pin etc is needed to unlock the bitlocker drive.

*Does require support from the BIOS.

1
0

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

"[T]ens of thousands of Windows desktops" with BitLocker deployed?

Are you sure that's a real scenario?

Even if it is, shouldn't something be worked out using AD instead of storing cleartext decryption keys on the local machine...? Or, if that's impossible, for whatever reason, shouldn't enabling this "feature" require an admin flipping something in a GPO or something? Some sort of opt-in? If all of that is impossible, shouldn't this be well-documented by Microsoft, to let people know that there's this tiny security hole they should consider?

This is not a bug. This is a "feature" of a security system that completely and totally obliterates it, in certain scenarios. It didn't happen by accident. Someone sat down and engineered this. And any number of other people signed off on it.

I, personally, would be very happy to see all of them fired.

5
0

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

Forums

Biting the hand that feeds IT © 1998–2017