Bungling Microsoft proves that golden backdoor keys are a terrible idea...

Redmond races to revoke Secure Boot policy

https://regmedia.co.uk/2016/08/10/sh...8&y=348&crop=1 http://www.theregister.co.uk/Design/...n/facebook.png

Updated Microsoft leaked the golden keys that unlock Windows-powered tablets, phones and other devices sealed by Secure Boot – and is now scrambling to undo the blunder.
These skeleton keys can be used to install non-Redmond operating systems on locked-down computers. In other words, on devices that do not allow you to disable Secure Boot even if you have administrator rights – such as ARM-based Windows RT tablets – it is now possible to sidestep this block and run, say, GNU/Linux or Android.
What's more, it is believed it will be impossible for Microsoft to fully revoke the leaked keys.
And perhaps most importantly: it is a reminder that demands by politicians and crimefighters for special keys, which can be used by investigators to unlock devices in criminal cases, will inevitably jeopardize the security of everyone.
Microsoft's misstep was uncovered by two researchers, MY123 and Slipstream, who documented their findings here in a demoscene-themed writeup published on Tuesday. Slip believes Microsoft will find it impossible to undo its leak.
Bring you up to speed on Secure Boot

Before we delve further, it is important to understand that up until now we've been talking about keys metaphorically: at the heart of this matter are what's called Secure Boot policies.
You don't have to completely understand all the ins and outs of Secure Boot to get your head around Microsoft's cockup. However, if you want more details of how Secure Boot works, the Linux Foundation has a guide here [PDF] and Microsoft blogged a gentle introduction here.
Basically, what you need to know is this: when Secure Boot is fully enabled in the firmware of a Microsoft device, it will only boot up an operating system that is cryptographically signed by Redmond. That stops you from booting up any OS you want on your Windows RT tablet, certain Windows Phones and so on.
Alongside this, there are Secure Boot policies, which are rules that are loaded and obeyed during early startup by the Windows boot manager. These policies must also be signed by Microsoft to be accepted, and are installed on devices and machines using a Microsoft-signed tool.
For internal debugging purposes, Microsoft created and signed a special Secure Boot policy that disables the operating system signature checks, presumably to allow programmers to boot and test fresh OS builds without having to sign each one.
If you provision this magic policy, that is, if you install it into your firmware, the Windows boot manager will not verify that it is booting an official Microsoft-signed operating system. It will boot anything you give it provided it is cryptographically signed, even a self-signed binary – like a shim that loads a Linux kernel.
The Register understands that this debug-mode policy was accidentally shipped on retail devices, and discovered by curious minds including Slip and MY123. The policy was effectively inert and deactivated on these products but present nonetheless.
Now that golden policy has leaked onto the internet. It is signed by Microsoft's Windows Production PCA 2011 key. If you provision it onto your device or computer as an active policy, you'll unlock Secure Boot.
The policy is universal; it is not tied to any particular architecture or device. It works on x86 and ARM, on anything that uses the Windows boot manager. Technically speaking, it is a supplemental policy: it's supposed to be merged with other Secure Boot policies, but you can use it as a main policy to switch off signature checks.
Microsoft's response

According to the pair of researchers, they contacted Microsoft's security team around March to say they had found the debug-mode policy. Initially, we're told, Redmond declined to follow up the find, then decided about a month later it was a security issue and paid out a bounty reward.
In July, Microsoft pushed out security patch MS16-094 in an attempt to stop people unlocking their Secure Boot-sealed devices. That added a bunch of policies, including the debug-mode policy, to a revocation list held in the firmware that's checked during startup by the Windows boot manager.
That didn't fully kill off the magic policy, however. The revocation list is checked by the boot manager after policies are loaded. By the point in the startup sequence, it's too late. However, a Microsoft tool used to provision the policy into the firmware does check the revocation list, and thus refuses to accept the magic policy when you try to install it, so MS16-094 acts merely as a minor roadblock.
This week, Microsoft issued patch MS16-100, which revokes more stuff but doesn't affect the golden policy, we're told. A third patch is due to arrive next month as a follow-up.
If you haven't installed the July fix yet, you can use this script to provision the unlock policy onto your ARM-powered Windows RT tablet. You must be an administrator to update the firmware. After that, you can set about trying to boot a non-Windows OS or any other self-signed EFI binary. We're told by one brave tester that this policy installation method worked on a Windows RT tab that was not patched for MS16-094.
The aforementioned script works by running a Microsoft-provided EFI binary during the next reboot that inserts the debug-mode policy into storage space on the motherboard that only the firmware and boot manager are allowed to access. The script's ZIP archive contains the leaked magic policy.
If you have installed the July update, the above script will fail because the updated revocation list will be checked by Microsoft's installation tool and the magic policy will be rejected before it can be provisioned. In about a week's time, MY123 is expected to release a package that will work around this and install the debug-mode policy on all devices, including Windows RT tablets.
People are particularly keen to unlock their ARM-powered Surface fondleslabs and install a new operating system because Microsoft has all but abandoned the platform. Windows RT is essentially Windows 8.x ported to 32-bit ARMv7-compatible processors, and Microsoft has stopped developing it. Mainstream support for Surface RT tabs runs out in 2017 and Windows RT 8.1 in 2018.
A policy similar to the leaked debug-mode policy can be used to unlock Windows Phone handsets, too, so alternative operating systems can be installed. A policy provision tool for Windows Phone is already available. We expect to hear more about that soon.
This Secure Boot misstep also affects Windows PCs and servers, but it's not that big a deal for them because these machines are typically unlocked anyway. You can boot your unrestricted computer into its firmware settings, and switch off Secure Boot, or delete all the keys from its database to disable it, if you really want to. You don't need any debug-mode tricks to do that.
In the unlikely event you're using a locked-down Secure Boot PC and you have admin rights on the box, and you want to boot something else, all the above is going to be of interest to you. If you're an IT admin who is relying on Secure Boot to prevent the loading of unsigned binaries and drivers – such as rootkits and bootkits – then all the above is going to worry you.
FBI and golden keys

To reiterate, these Microsoft-signed resources – the debug-mode policy and the EFI installation tool – are only meant to be used by developers debugging drivers and other low-level operating system code. In the hands of Windows RT slab owners, whose devices are completely locked down, they become surprisingly powerful.
It's akin to giving special secret keys to the police and the Feds that grant investigators full access to people's devices and computer systems. Such backdoor keys can and most probably will fall into the wrong hands: rather than be used exclusively for fighting crime, they will be found and exploited by criminals to compromise communications and swipe sensitive personal information.
Anyone who thinks government servers holding these keys are safe need only be reminded of the OPM megahack; anyone who thinks these keys cannot be extracted from software or hardware need only spend a weekend with a determined reverse-engineer and a copy of IDA Pro.
The Secure Boot policies Microsoft is rushing to revoke can't be used to backdoor conversations or remotely hijack systems, but they remind us that this kind of information rarely stays secret.
"This is a perfect real world example about why your idea of backdooring cryptosystems with a 'secure golden key' is very bad," Slipstream wrote, addressing the FBI in particular.
"Smarter people than me have been telling this to you for so long. It seems you have your fingers in your ears. You seriously don't understand still? 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?"
Microsoft declined to comment. Meanwhile, you can chat to the researchers at irc.rol.im in #rtchurch. ®
Updated to add

We're told the policy installation script has been updated to work on Windows RT tablets even if you have applied the July and August Patch Tuesday updates.



SOURCE


DJ OD

The bit I found interesting, when did MS obtain permission to modify firmware on pc's?

Quote:

---

Originally Posted by Over Carl

The bit I found interesting, when did MS obtain permission to modify firmware on pc's?

---

These are Windows devices that come pre-installed. I'm sure in these instances it's in the agreement. I know my SP3 gets firmware updates quite regularly from Windows Update - I've given up my tin foil hat and just let it get on with it :)

Me being a bit dumb I don't get it..

I have win7/win10/Kali 2.0/Debian on multiboot over 3 drives.

Don't have to change UEFI when going from win10 to any of the others.