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.
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 …
This post has been deleted by its author
"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.
"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
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.
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."
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.
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.
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™!
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.
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.
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.
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...
> 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
"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'
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.
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.
"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...]
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.
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...
"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.
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.
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?"
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.
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..
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.
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?
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.
"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.
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?)
"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).
"that have been signed by a key that the target machine trusts for this purpose"
Yup, the OS will only trust updates that have been signed using the same key as the kernel and base libraries were signed with. This is to stop people trying to spoof the Windows update servers and even going so far as to cut certificates that the client trusts.
If you can somehow manage to either replace the kernel and the base libraries with version you wrote and signed yourself, or somehow managed to figure out Microsoft's 4096-bit code signing key, then you can perform much better hacks than impersonating the update servers...
>> "Yup, the OS will only trust updates that have been signed using the same key as the kernel and base libraries were signed with".
I thought of this, and I'm not sure it will save the day, really.
I don't know the details of the link to Windows update itself -- I always figured the digital signatures on the updates themselves are enough, so I didn't bother to dig any deeper. But certainly the link to local WSUS is not usually HTTPS; though it can be.
You see, the update itself can be perfectly legit! Just so long as it will trigger this behaviour, it can be used to effectively remove BitLocker.
I mean, it doesn't affect me, so far as I can determine, because I'm a paranoid basterd. But this one is an Epic Fail worthy of the great Bloody Stupid Johnson himself!
"[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.
"The clever sods makes sure you never know when a bloody update will happen, making it FAR harder to do this."
then I connect a network sniffer, watching for "upgrade" net traffic, to something that powers off the box or at least alarms you to go over and pay attention to it...
these things can be defeated. Also may be possible to trigger an update by mucking with the clock
"Linus's shareware OS is a security risk!"
Care to elaborate? If you know what you are talking about, that is.
You do realise that software where we have no access to the source code can and often do a lot of stuff that we don't have any control over. Windows 10 is a recent example.
P.S: Wasn't the term "shareware" retired about 15 years ago? Linux is "open source".
How you download it is irrelevant, but most download it from an official distro's website.
No recovery keys, no backdoors, only the password/keydisk you used to create it will work[*]. If you lose the authentication method, well, you do back up your data, don't you? The encryption key is never stored as plain-text, only the encrypted version. The only time a plain-text version of the key exists on the system is after the user inserts the keydisk or types in the password in which case it only exists in a highly-protected region of memory and is overwritten with random data when the volume is unmounted. The region in memory it is stored is also used for all the other secrets the kernel keeps around and has quite a few protections looking after it.
[*] provided you haven't changed the password since creating it, in which case, only the most recent password/keydisk will work.
There's a lot to recommend stand-alone FDE with no backdoors or recovery options whatsoever. But it's not appropriate for a corporate environment where multiple entities may have legitimate claim to the data. There needs to be a way to recover even if the day-to-day key is "lost".
If you have proper folder redirection and a proper backup regimen, then access to the files on the individual machine is unnecessary. If your company depends on being able to access files on user systems, then your company is doomed. My company uses rsync over SSH to backup users' home directories and configuration deltas (EG pulling the logs from the package manager and producing diff's between the current version of a config file and the base file that shipped with the system).
This happens daily and allows for backing up no matter where the employee is located so long as they are connected to the internet. The intention is that any lost / stolen / failed / attacked / infected system can just be fully written off and replaced with a new system with only trivial loss in productivity. Rather than waste time to disinfect systems or to try and recover files from a failed hard disk, we just grab a new machine, through an image on it, provide the list of packages that were on the system to the package manager to install, then apply all the backed-up diffs to the configuration files. The users' home directory is then copied onto the machine, rebooted and the user can carry on with, at most, loss of anything that happened in the last 24 hours.