Microsoft’s Debug Mode Flaw and “Golden Key” Leak Allows Disabling of Secure Boot

Microsoft’s Debug Mode Flaw and “Golden Key” Leak Allows Disabling of Secure Boot

Windows-based OSs are no longer the default and top choice in the mobile scene. The Open Source nature of Android has found many fans in OEMs, and as a result, less and less phones use Windows these days.

But if you are among those who still continue to use a Windows device in your daily life, there’s a bit of news for you. Good or bad, that would depend on your stance and interpretation of the use cases of this news.

As reported by Ars Technica and TheRegister with the news originating from a website which will likely give you a headache (not kidding), a few developers (@never_released and @TheWack0lian) have found out that a backdoor that Microsoft baked in for debug purposes has opened up possibilities of disabling secure boot on Windows devices.


https://twitter.com/neobiscuit/status/763571136726564864

Secure Boot and what is it?

When you first boot up a Windows device, the boot procedure goes around in this general order: UEFI (Unified Extensible Firmware Interface, which is a replacement of BIOS) -> Boot Manager -> Boot Loader -> Windows. UEFI is where the Secure Boot functionality is present. As the name implies with Secure Boot, it aims to improve security by requiring digital signatures on the next steps. Essentially, if the bootloader is not signed with keys that UEFI is expecting it to be with, the procedure of booting your device will not complete.

Secure Boot is an optional feature, but Microsoft has made enabling it mandatory to get Windows certification from Windows 8 and onward. The reasoning here was that Secure Boot would make it difficult for malware authors to insert code into the boot procedure. However, a side effect to Secure Boot was that it made it a bit complicated to dual-boot on Windows machines, as either the second OS and all its pre-requisites also need to be digitally signed, or Secure Boot would need to be disabled. There are a lot of other issues to this, and seasoned dual-booters would know about them more than I could explain in a paragraph.

Now, there are some devices on which Secure Boot can not be disabled by the user even if they wanted to. This is the realm where our subject matter gets drastically narrowed down from all Windows devices (including desktops) to specific Windows devices like Windows Phone devices, Windows RT devices, some Surface devices and even HoloLens. These end user devices have Secure Boot locked on, meaning that an end user can not modify or disable aspects related to Secure Boot, and by extension, they can not touch the OS in manners not authorized by Microsoft for the end user.

But for the purposes of ongoing official development, Secure Boot needs to loosen up a bit. On devices that Secure Boot is locked on, Secure Boot Policies exist which can help with authorized development without needing to disable Secure Boot. As the researching users mention, this Secure Boot Policy file is loaded by the Boot Manager early in the boot process for windows. The Policy files also can contain registry rules which in turn have the ability to contain configurations for the policy itself among other things. Again, the Policy file must be signed and there are other provisions in place which exist to make sure that only Microsoft can provision these changes.

The signing element also relies on what is called the DeviceID, which is used when applying. I’ll let the blog post do the explaining here, since there are a few parts which aren’t as clear to me:

Also, there is such a thing called DeviceID. It’s the first 64 bits of a salted SHA-256 hash, of some UEFI PRNG output. It’s used when applying policies on Windows Phone, and on Windows RT (mobilestartup sets it on Phone, and SecureBootDebug.efi when that’s launched for the first time on RT).
On Phone, the policy must be located in a specific place on EFIESP partition with the filename including the hex-form of the DeviceID. (With Redstone, this got changed to UnlockID, which is set by bootmgr, and is just the raw UEFI PRNG output).

Basically, bootmgr checks the policy when it loads, if it includes a DeviceID, which doesn’t match the DeviceID of the device that bootmgr is running on, the policy will fail to load. Any policy that allows for enabling testsigning (MS calls these Retail Device Unlock / RDU policies, and to install them is unlocking a device), is supposed to be locked to a DeviceID (UnlockID on Redstone and above). Indeed, I have several policies (signed by the Windows Phone production certificate) like this, where the only differences are the included DeviceID, and the signature. If there is no valid policy installed, bootmgr falls back to using a default policy located in its resources. This policy is the one which blocks enabling testsigning, etc, using BCD rules.

This is the part where things gets interesting. During the development of Windows 10 v1607, Microsoft created a new type of Secure Boot Policy (referred to as SBP henceforth for the sake of brevity) for internal testing and debugging purposes. The policy is “supplemental” in nature with no DeviceID present, and it causes its settings to be merged in onto an existing Boot Policy. The Boot Manager loads in the older types of SBP, then verifies its signing and authenticity and then loads in these supplemental boot policies. The issue here is that there is no further verification on the supplemental policy itself. Also, Boot Managers earlier than Windows 10 v1511 do not know about the existence of the supplemental nature of these policies, and hence, react as if they loaded a perfectly valid and signed policy. Again, this behavior was likely for internal development, so that the developers shouldn’t have had to sign each and every OS version and minor change they had to do on the device.

This SBP is being referred to as a “Golden Key” since it basically nullifies the purpose of signature checks. This SBP was unintentionally shipped on retail devices, albeit in a deactivated state. The developers found this SBP and made known their findings. Now, the SBP can be found floating around on the internet, with this particular zip being used to install the SBP on Windows RT devices.

What does this mean?

If you loaded a supplemental SBP, you can enable test signing for Windows to allow you to load in unsigned drivers. Further, since these Policies come into play before the Boot Manager stage in the boot procedure, you can compromise the security of the whole order and run unauthorized (read self-signed) code. This opens up a lot of possibilities, for users intending to modify parts of Windows beyond authorization and for malware creators alike.

The authors of this finding focus on the irony of the whole fiasco. Microsoft locked on Secure Boot on certain devices to keep unauthorized changes far, but then built in a backdoor to let them continue with development and debugging. But this very backdoor paves the way for Secure Boot to be disabled on all devices running Windows, rendering the whole ordeal pointless.

Not only can willing users now install Linux distros (and possibly Android) on Windows-only Tablets and Phones, unwilling users can also have malicious bootkits installed if they compromise physical access to their device. While the former is something we can jump up in the air upon, the latter does not really instill a lot of confidence. It goes both ways, and it shows us why security is a dual-edged sword. Further, the SBP is universal in nature, allowing its use on any device irrespective of architecture. It isn’t particularly useful for cases of desktops where Secure Boot can be toggled off easily, but it is of immense scope for devices where you can’t mess around with Secure Boot.

So, what’s the fix?

Microsoft did release some patches, but the developers insist that the issue is not entirely fixed up. You can check out these patches (MS16-094 and MS16-100) and then read up on the blog post itself on why they do not solve the issue. If they are correct, this issue does not have a fix or a patch in sight, though that won’t stop Microsoft from trying to place more roadblocks on the way.

What next?

There’s a world of possibilities, and some of them are brewing up over at our Windows Forums. You can check out our forums on Windows Phone 8 Development and Hacking and our forums for Windows 8, Windows RT and Surface Development and Hacking. You can also find instruction threads for some devices, where other users are discussing the same.


The presence of this debug backdoor and the leak of the SBP are important not only for the third-party development of locked Windows devices, they also show us a grim reminder on what can happen if intentional backdoors are left. Recent focus on security had turned towards investigative agencies pressing for the presence of such backdoors to be used to aid in their legal investigative purposes. But sooner or later, these methods will fall into the wrong hands. What is intended to be used as a tool for fighting crime and aiding in justice, would then become the tool for the crime itself one day.

What are your thoughts on the leak of the Debug SBP? Do you feel that “Golden Keys” like these should exist? Let us know in the comments below!

Discuss This Story

Want more posts like this delivered to your inbox? Enter your email to be subscribed to our newsletter.

READ THIS NEXT