Holding Shift + F10 During Windows 10 Updates Opens Root CLI, Bypasses BitLocker (bleepingcomputer.com)

An anonymous reader quotes a report from BleepingComputer: Windows security expert and infrastructure trainer Sami Laiho says that by holding SHIFT + F10 while a Windows 10 computer is installing a new OS build, an attacker can open a command-line interface with SYSTEM privileges. This CLI debugging interface also grants the attacker full access to the computer's hard drive data, despite the presence of BitLocker. The CLI debugging interface is present when updating to new Windows 10 and Windows 10 Insiders builds. The most obvious exploitation scenario is when a user leaves his computer unattended during the update procedure. A malicious insider can open the CLI debugger and perform malicious operations under a root user, despite BitLocker's presence. But there are other scenarios where Laiho's SHIFT + F10 trick can come in handy. For example when police have seized computers from users who deployed BitLocker or when someone steals your laptop. Windows 10 defaults help police/thieves in this case because these defaults forcibly update computers, even if the user hasn't logged on for weeks or months. This CLI debugging interface grants the attacker full access to the computer's hard drive, despite the presence of BitLocker. The reason is that during the Windows 10 update procedure, the OS disables BitLocker while the Windows PE (Preinstallation Environment) installs a new image of the main Windows 10 operating system. "This [update procedure] has a feature for troubleshooting that allows you to press SHIFT + F10 to get a Command Prompt," Laiho writes on his blog. "The real issue here is the Elevation of Privilege that takes a non-admin to SYSTEM (the root of Windows) even on a BitLocker (Microsoft's hard disk encryption) protected machine." Laiho informed Microsoft of the issue and the company is apparently working on a fix.

Comments

Re: Something Smells Fishy

[Billly Gates]

The reason why is the key is stored on the TPM chip. NTFS.sys can simply use it as a layer in it's I/O stack when filling it's read/write buffers.

Re: Only the lazy and terminally lame dont know?

[sexconker]

BitLocker can be used without TPM. You can supply your key via a USB drive or even use a keyboard to put in the 48-digit recovery key.

Are you doing it (BitLocker) right?

[Nkwe]

If you are doing BitLocker correctly, you have to type in a password every time you boot the computer. If you are doing is really right, that password is only a PIN used to unlock the actual encryption key stored in a Trusted Platform Module (hardware protected crypto storage device). This means that although a computer may update itself automatically if it gets powered up by an adversary, thus opening an opportunity for the diagnostic shell to have access to a temporarily disabled BitLocker, this could only happen if the adversary knows (or can coerce) the BitLocker password from you. While some may believe that there is a backdoor to BitLocker, this particular diagnostic window is not it because it should never be accessible by an adversary.

Re:Yeah but

[Anonymous Coward]

Another plus to VeraCrypt were the results and actions taken from their recent audit:

http://blog.quarkslab.com/security-assessment-of-veracrypt-fixes-and-evolutions-from-truecrypt.html
https://ostif.org/the-veracrypt-audit-results/

Obviously if you're thinking of switching to VeraCrypt over bitlocker make sure you consider their security model (though most of this applies to any full disk encryption software).
https://veracrypt.codeplex.com/wikipage?title=Security%20Model

Re:Something Smells Fishy

[EndlessNameless]

You obviously have no idea how Bitlocker works. It is architecturally similar to many other full-disk encryption packages.

There is a volume encryption key which is used to encrypt the user data on the disk. This key is generally used with a fast symmetric cipher like AES. Once the initial volume encryption is completed, all reads/writes require the key to encrypt or decrypt the data.

The volume encryption key is encrypted with the public key or password for each unique user. Thus, each user has his own means of accessing the volume key, which must be the same for everyone. There is an encrypted copy of the volume key on the hard drive for every user. It could be one, or it could a hundred. (In most enterprises, the TPM is also a "user" who can unlock the drive with its key.)

In this case, the disk can be temporarily "unlocked" if an administrator suspends Bitlocker. When Bitlocker is suspended, the volume encryption key is stored in a cleartext container on disk. That volume will automatically unlock until Bitlocker protection is reenabled, which scrubs the cleartext key.

Microsoft should require administrator consent before suspending Bitlocker, so this is more of a design flaw than an exploit. Manually suspending Bitlocker does require administrator privileges.