Microsoft's mistake with Secure Boot and its secret policy is a perfect illustration of why it's too dangerous to create encryption systems with a secure backdoor. Someone will inevitably make a mistake, and users are left vulnerable while the company scrambles for a fix.
Secure Boot, a feature of the Unified Extensible Firmware Interface (UEFI), protects the boot process in latest the Windows versions from malicious bootkits and packages. It implements only bootloader components that have been signed and verified by Microsoft before bringing on kernel drivers, user drivers, and applications; all this is governed by different policies. Therefore, devices with Secure Boot enabled cannot be reinstalled with another operating system, even if the user has administrator privileges, because the binaries aren't signed by Microsoft.
Microsoft made it harder for malware to infect the locked-down device, but it also weakened the Secure Boot feature for every device with its secret Secure Boot policy that bypasses normal checks, warned two researchers, MY123 and Slipstream, in a detailed writeup. They referred to the policy, which enables test signing on Windows devices, as a backdoor.
"A backdoor, which MS put into Secure Boot because they decided to not let the user turn it off in certain devices, allows for Secure Boot to be disabled everywhere," the researchers said.
Test signing is a state where developers can load fresh operating system builds without signing each one. Since Secure Boot cannot be disabled on some devices, such as Windows RT, HoloLens, and Windows Phone, this special policy lets developers and engineers work with different software on locked-down hardware.
With this policy, Windows boot manager will not verify if the device is booting an official Microsoft-signed software. The Secure Boot policy, which is not available on commercial products for obvious reasons, will boot any cryptographically signed binary -- even if it's self-signed -- such as malware or non-Microsoft operating system, rendering the entire concept of Secure Boot moot.
"The supplemental policy does NOT contain a DeviceID. And because they were meant to be merged into a base policy, they don't contain any BCD rules either, which means that if they are loaded, you can enable testsigning. Not just for Windows (to load unsigned driver, ie rootkit), but for the {bootmgr} element as well, which allows bootmgr to run what is effectively an unsigned .efi (ie bootkit)!" the researchers wrote.
Microsoft had good intentions -- a debugging mode to make it easier for developers to work -- but let's face it, this Secure Boot policy is a backdoor. While the company never intended to make the policy public, someone leaked it online, meaning anyone can now access it. With the policy, anyone can trick Secure Boot and install a different operating system or malware on the device.
IT administrators relying on Secure Boot to prevent rootkits and bootkits from loading on their Windows systems should be worried. This kind of god mode will load any unsigned binary and driver.
"This is a perfect real-world example about why your idea of backdooring cryptosystems with a 'secure golden key' is very bad!" the researchers said in a pointed message to the FBI.
As for fixing the problem, there are limitations. After the researchers notified Microsoft of the issue, the company released a security patch MS16-094 in July to move several policies on the revocation list and prevent Windows boot manager from executing them. A Microsoft tool that's used to provision policies will check the revocation list before installing policies, so this "golden key" policy is blocked from loading on systems with the July patch installed. However, the revocation list is checked after policies are loaded, so the July patch is not a complete fix -- it's at most a small roadblock.
The latest security patch, MS16-100, revokes more policies, but the problematic Secure Boot policy remains unaffected. The company is expected to release another patch addressing Secure Boot policy next month.
The issue remains only partially addressed, and what's worse, it is believed that Microsoft can't fully revoke the leaked policies.
"It'd be impossible in practice for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc," the researchers said.
This puts users in a precarious position. They can't do anything to protect themselves except make sure they're up to date on all patches to ensure attackers can't get in via an existing vulnerability and infect the machine with a malicious bootloader.
Law enforcement authorities and elected government officials have been demanding the industry come up with special backdoor keys that can be used to unlock devices or decrypt communications as part of criminal investigations. Security experts have pushed back on the demands because backdoors inevitably jeopardize the security of every user. While Secure Boot doesn't impact user communications or sensitive transactions, the difficulty in revoking the policies and fixing the backdoor should be a lesson for the FBI.
The first lesson was that keys and secrets will eventually get leaked. The second is that a fix is not always available.
"Microsoft implemented a 'secure golden key' system. And the golden keys got released by Microsoft's own stupidity. Now, what happens if you tell everyone to make a 'secure golden key' system?" the researchers asked.