BitLocker bypass on Windows 10 through upgrades
A security researcher discovered a new issue in Microsoft's Windows 10 operating system that allows attackers to gain access to BitLocker encrypted data.
A post on the Win-Fu blog highlights the method. Basically, what the method does is exploit a troubleshooting feature that is enabled during the upgrade process.
There is a small but CRAZY bug in the way the "Feature Update" (previously known as "Upgrade") is installed. The installation of a new build is done by reimaging the machine and the image installed by a small version of Windows called Windows PE (Preinstallation Environment).
This has a feature for troubleshooting that allows you to press SHIFT+F10 to get a Command Prompt. This sadly allows for access to the hard disk as during the upgrade Microsoft disables BitLocker.
If you press Shift-F10, you open a command prompt window which lets you access the storage devices of the operating system.
Since BitLocker protection is disabled during upgrades, it means that anyone exploiting the issue gets access to all files that are usually encrypted by BitLocker.
BitLocker bypass on Windows 10 through upgrades
The method works currently when updating the original Windows 10 release build to the November update version 1511 or the Anniversary update version 1607. Furthermore, it works on any new Insider Build that Microsoft puts out, at least for the time being.
The main issue, as noted by Sami Laiho, the researcher who disclosed the issue, is that anyone with local access to the machine may exploit the issue. Administrative access is not required, and so is not special software, settings or hardware on the Windows device.
Since this is a local issue, it is clear that the issue won't be exploited in the wild. Anyone with local access to a Windows machine on the other hand may exploit the issue. If it is a user, Windows 10 may be configured to accept Windows Insider updates if not prevented by a system administrator.
Companies therefore should disallow the switching on of Windows Insider builds for machines running Windows 10.
This is done in the following way:
- Tap on the Windows-key, type regedit.exe and hit the Enter-key.
- Navigate to the following Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\UI\Visibility
- Right-click Visibility, and select New > Dword (32-bit) Value.
- Name it HideInsiderPage.
- Double-click on the new preference and set its value to 1.
You can undo the change at any time by deleting the key, or by setting it to 0.
Companies may also want to disallow unattended upgrades (not updates necessarily) on Windows 10 machines to prevent the issue from being exploited.
The disclosed security issue is problematic for BitLocker protected devices that run Windows 10. The main issue here is of course the revealing of protected files during upgrade processes.
So much for “the most secure windoze ever!!11”. I suppose LTSB would not have this problem, but hey, they can’t milk the user of money through that SKU so they’re not going to sell it to you.
Doesn’t seem much like an issue. This would be the same as a user leaving a Bitlocker-protected computer logged in while away from the computer. It requires physical access. It’s not possible to modify files on an encrypted volume without decrypting/mounting it first.
This basically just reinforces the fact you shouldn’t leave an encrypted computer unattended when the encrypted contents are mounted/accessible.
While it’s not as bad as a remote exploit it’s still pretty bad to allow anyone (non administrators) access to files that have been encrypted for a reason.
No wonder ms wants to force windows10 down our throats.
This isn’t surprising because Windows disables bitlocker temporarily during an upgrade. It really comes down to security vs ease of upgrade with this, though I do find it interesting that you can still access the command prompt while upgrading.
But before you all get your panties in a bunch, take some time to think about it. If you used a 3rd party encryption (like diskcryptor) you wouldn’t even be able to upgrade without having to decrypt your system OS first as Martin pointed out here: https://www.ghacks.net/2015/11/19/fix-the-instalboot-operation/
So you either can temporarily disable bitlocker up until it’s finished upgrading, or decrypt the drive, upgrade, then wait for it to encrypt. Either way, as long as you monitor your computer during the upgrade you should be fine.
Why is it being disabled when you upgrade? If the encryption isn’t enabled all the time, then it is useless. Linux FDE isn’t disabled when you dist-upgrade. Android doesn’t seem to disable its encryption too. Even Windows encrypted by a third party app like Veracrypt can be upgraded while encrypted.
And if MS can disable encryption while upgrading, then they can also disable it if asked by a state actor.
All of the encryption methods you just listed are absolutely suspended when you use them – your drive is “decrypted” as soon you login to any of those services because that’s the only way it could possibly run.
You literally don’t know what you’re talking about. If you encrypted Windows with Vercrypt and tried to install Windows 7 SP1, it would fail immediately as the drive would be locked and unreadable.
Christ, the ghacks commenters are literally just the worst.
Bullshit. Show me how any of them are disabled. I know what I’m talking about. You do not. You are talking on-the-fly-decryption, not disabling encryption entirely, numbnuts. Read the original article. MS “disables” Bitlocker encryption while upgrading. Linux LUKS and Veracrypt do not.
Read before you speak, you ignorant git.
I believe by stating “disable” meant that the decryption key is temporarily saved during the upgrade process. You can’t just turn off bitlocker like an on/off switch and expect it to work without decrypting the data.
Thanks for the clarification. But still, saving the decryption key in plaintext is very bad. Windows can upgrade just fine while encrypted with Veracrypt. I don’t see MS getting Veracrypt’s decryption key and saving it in plaintext. Neither does Linux LUKS do so.
Which is my point in the first place. If other OSes and third party FDE work without compromising their encrypting while OS upgrading, I don’t see why MS can’t even do that.
Agreed that saving the encryption key anywhere in unencrypted space is very bad. I believe the main issue has to do with rebooting. I don’t understand why microsoft doesn’t force windows to do a soft reboot instead of a a hard reboot during updates. that would prevent the need of saving the encryption key anywhere since it is only rebooting windows and not the whole system. I believe this might be what other OSs are doing unless they require you to put in the password each time.
Personally it doesn’t phase me since I am always present during any upgrade or patch. not having to punch in my 20 character password 3+ times during an upgrade does make it easier
That’s what I was thinking too. I use dist-upgrade on at least a weekly basis on a system with LUKS full disk encryption. The encryption is definitely not disabled when that happens, and there is nothing complicated about the process from a user standpoint.
From what I understand, this is very _very_ bad. Windows writes a copy of the master key to the disk in clear text (in order to perform an unattended/inplace update) and then overwrites it multiple times when done, but the thing is that on an SSD, there’s no way to actually guarantee that you actually overwrote a file due to wear leveling in the SSD.
If critical information which allows someone to decrypt the disk ever gets written to that disk in plain text, even for a second, you have already failed in designing a secure product.