Microsoft addresses debug policy causing Secure Boot bypass

Aug 10, 2016 17:35 GMT  ·  By

Two security researchers, MY123 and Slipstream, discovered and helped Microsoft fix a security flaw that allowed attackers to bypass the Secure Boot system that protects devices booting Windows operating systems.

According to Microsoft's description, Secure Boot is a security protocol developed together with members of the PC industry. It's automatically included in the UEFI firmware that helps your computer, laptop, or smartphone through the boot-up process.

Secure Boot was created to fight bootkits, a type of malware that alters the boot-up process, and its role is to prevent tampering of the files loaded during the boot-up.

Microsoft itself added the problematic code

MY123 and Slipstream discovered that, after Windows 10 v1607 Redstone, Microsoft added a new type of Secure Boot policy, called "supplemental" policies.

The two claim that one of these supplemental policies can be used to disable a Secure Boot feature that checks if the files executed during the boot sequence are cryptographically signed by Microsoft.

This policy allows an attacker to switch Secure Boot into a testing mode called "testsigning," which lets someone in physical control of the device load unsigned binaries, and by doing so, take over the boot sequence and load malware or even a custom operating system.

The problematic Secure Boot policy is nothing more than leftover debug code

Most likely, this policy was introduced during Windows 10's development process, so developers can load unsigned drivers and Windows 10 versions.

Nevertheless, this policy has remained and has also made its way into the firmware of various Secure Boot-enabled devices sold during the past year.

In its current state, this Secure Boot policy acts like a backdoor, allowing a third party access to a previously secured device.

Problematic Secure Boot policy leaks online

Even worse, someone found this "testing" policy and leaked it online, allowing anyone to load it with UEFI firmware and bypass Secure Boot on protected devices.

The researchers privately disclosed the problem to Microsoft, who initially didn't want to fix it, for undisclosed reasons.

The company had a change of heart and issued a patch in July with MS16-096 (CVE-2016-3287). That patch was incomplete, and yesterday, Microsoft issued a second patch, MS16-100 (CVE-2016-3320), but it is currently unknown if this fixes the problem.

Slipstream, one of the researchers, has told Softpedia that this second patch might not entirely fix the problem. "I have reviewed the second patch," Slipstream explains. "I know it revokes *stuff*, just no idea what." A clear status for this problem might still need some time to figure out.

The backdoor the FBI has always wanted

While not an encryption backdoor, this issue is called a "golden key" because it provides a way to unlock devices that were previously securely locked.

In the famous Apple vs. FBI case, a golden key would have not helped recover the encrypted data, but law enforcement agencies can find creative ways for using golden keys in many other situations.

"About the FBI: are you reading this? If you are, then this is a perfect real world example about why your idea of backdooring cryptosystems with a 'secure golden key' is very bad!" the researchers explain in their highly technical write-up.

"You seriously don't understand still? Microsoft implemented a 'secure golden key' system. And the golden keys got released from MS own stupidity. Now, what happens if you tell everyone to make a 'secure golden key' system? Hopefully you can add 2+2..."