Microsoft proves backdoor keys are a bad idea
theregister.co.uk
Microsoft proves backdoor keys are a bad idea
1–10 of 106 posts
Re: Microsoft proves backdoor keys are a bad idea
#2I genuinely hope this will influence the whole government mandated back door debate for the better but I'm afraid that this will just be forgotten in a matter of minutes.
Like Gove said "we've had enough of experts", especially when their educated opinions don't suit us.
Re: Microsoft proves backdoor keys are a bad idea
#3I genuinely hope this will influence the whole government mandated back door debate for the better but I'm afraid that this will just be forgotten in a matter of minutes. Like Gove said "we've had enough of experts", especially when their educated opinions don't suit us.
Except the "no encryption at all" crowd gets a louder voice.
Re: Microsoft proves backdoor keys are a bad idea
#4I genuinely hope this will influence the whole government mandated back door debate for the better but I'm afraid that this will just be forgotten in a matter of minutes. Like Gove said "we've had enough of experts", especially when their educated opinions don't suit us.
Did anything come of this? https://en.wikipedia.org/wiki/NSAKEY
Re: Microsoft proves backdoor keys are a bad idea
#5(disclaimer, MS employee, non-security expert here).
I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it.
In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're already screwed.
So, I don't doubt that the key exists (I had to use it myself when testing RT devices back in the win8 days), but what's the exploit here? Why is it, as the title suggests, a 'bad idea'? Isn't a secure boot policy that can be bypassed with physical access more secure than none?
Re: Microsoft proves backdoor keys are a bad idea
#6The researchers' writeup, in a very fun form, can be found at https://rol.im/securegoldenkeyboot/
With text as follows for those whom the joviality of the original presentation is undesirable:
irc.rol.im #rtchurch :: https://rol.im/chat/rtchurch
Specific Secure Boot policies, when provisioned, allow for testsigning to be enabled, on any BCD object, including {bootmgr}. This also removes the NT loader options blacklist (AFAIK). (MS16-094 / CVE-2016-3287, and MS16-100 / CVE-2016-3320)
Found by my123 (@never_released) and slipstream (@TheWack0lian) Writeup by slipstream (@TheWack0lian)
First up, "Secure Boot policies". What are they exactly?
As you know, secureboot is a part of the uefi firmware, when enabled, it only lets stuff run that's signed by a cert in db, and whose hash is not in dbx (revoked).
As you probably also know, there are devices where secure boot can NOT be disabled by the user (Windows RT, HoloLens, Windows Phone, maybe Surface Hub, and maybe some IoTCore devices if such things actually exist -- not talking about the boards themselves which are not locked down at all by default, but end devices sold that may have secureboot locked on).
But in some cases, the "shape" of secure boot needs to change a bit. For example in development, engineering, refurbishment, running flightsigned stuff (as of win10) etc. How to do that, with devices where secure boot is locked on?
Enter the Secure Boot policy.
It's a file in a binary format that's embedded within an ASN.1 blob, that is signed. It's loaded by bootmgr REALLY early into the windows boot process. It must be signed by a certificate in db. It gets loaded from a UEFI variable in the secureboot namespace (therefore, it can only be touched by boot services). There's a couple .efis signed by MS that can provision such a policy, that is, set the UEFI variable with its contents being the policy.
What can policies do, you ask?
They have two different types of rules. BCD rules, which override settings in the on-disk BCD, and registry rules, which contain configuration for the policy itself, plus configuration for other parts of boot services, etc. For example, one registry element was introduced in Windows 10 version 1607 'Redstone' which disables certificate expiry checking inside mobilestartup's .ffu flashing (ie, the "lightning bolt" windows phone flasher); and another one enables mobilestartup's USB mass storage mode. Other interesting registry rules change the shape of Code Integrity, ie, for a certain type of binary, it changes the certificates considered valid for that specific binary.
(Alex Ionescu wrote a blog post that touches on Secure Boot policies. He teased a followup post that would be all about them, but that never came.)
But, they must be signed by a cert in db. That is to say, Microsoft.
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.
Now, for Microsoft's screwups.
During the development of Windows 10 v1607 'Redstone', MS added a new type of secure boot policy. Namely, "supplemental" policies that are located in the EFIESP partition (rather than in a UEFI variable), and have their settings merged in, dependant on conditions (namely, that a certain "activation" policy is also in existance, and has been loaded in).
Redstone's bootmgr.efi loads "legacy" policies (namely, a policy from UEFI variables) first. At a certain time in redstone dev, it did not do any further checks beyond signature / deviceID checks. (This has now changed, but see how the change is stupid) After loading the "legacy" policy, or a base policy from EFIESP partition, it then loads, checks and merges in the supplemental policies.
See the issue here? If not, let me spell it out to you plain and clear. The "supplemental" policy contains new elements, for the merging conditions. These conditions are (well, at one time) unchecked by bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and earlier certainly doesn't know about them. To those bootmgrs, it has just loaded in a perfectly valid, signed policy.
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)!!! (In practise, the .efi file must be signed, but it can be self-signed) You can see how this is very bad!! A backdoor, which MS put in to secure boot because they decided to not let the user turn it off in certain devices, allows for secure boot to be disabled everywhere!
You can see the irony. Also the irony in that MS themselves provided us several nice "golden keys" (as the FBI would say ;) for us to use for that purpose :)
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! 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 from MS own stupidity. Now, what happens if you tell everyone to make a "secure golden key" system? Hopefully you can add 2+2...
Anyway, enough about that little rant, wanted to add that to a writeup ever since this stuff was found ;)
Anyway, MS's first patch attempt. I say "attempt" because it surely doesn't do anything useful. It blacklists (in boot.stl), most (not all!) of the policies. Now, about boot.stl. It's a file that gets cloned to a UEFI variable only boot services can touch, and only when the boot.stl signing time is later than the time this UEFI variable was set. However, this is done AFTER a secure boot policy gets loaded. Redstone's bootmgr has extra code to use the boot.stl in the UEFI variable to check policy revocation, but the bootmgrs of TH2 and earlier does NOT have such code. So, an attacker can just replace a later bootmgr with an earlier one.
Another thing: I saw some additional code in the load-legacy-policy function in redstone 14381.rs1_release. Code that wasn't there in 14361. Code that specifically checked the policy being loaded for an element that meant this was a supplemental policy, and erroring out if so. So, if a system is running Windows 10 version 1607 or above, an attacker MUST replace bootmgr with an earlier one.
On August 9th, 2016, another patch came about, this one was given the designation MS16-100 and CVE-2016-3320. This one updates dbx. The advisory says it revokes bootmgrs. The dbx update seems to add these SHA256 hashes (unless I screwed up my parsing):
I checked the hash in the signature of several bootmgrs of several architectures against this list, and found no matches. So either this revokes many "obscure" bootmgrs and bootmgfws, or I'm checking the wrong hash.
Either way, it'd be impossible in practise for MS to revoke every bootmgr earlier than a certain point, as they'd break install media, recovery partitions, backups, etc.
- RoL
disclosure timeline: ~march-april 2016 - found initial policy, contacted MSRC ~april 2016 - MSRC reply: wontfix, started analysis and reversing, working on almost-silent (3 reboots needed) PoC for possible emfcamp demonstration ~june-july 2016 - MSRC reply again, finally realising: bug bounty awarded july 2016 - initial fix - fix analysed, deemed inadequate. reversed later rs1 bootmgr, noticed additional inadequate mitigation august 2016 - mini-talk about the issue at emfcamp, second fix, full writeup release
credits: my123 (@never_released) -- found initial policy set, tested on surface rt slipstream (@TheWack0lian) -- analysis of policies, reversing bootmgr/ mobilestartup/etc, found even more policies, this writeup.
tiny-tro credits: code and design: slipstream/RoL awesome chiptune: bzl/cRO <3
Re: Microsoft proves backdoor keys are a bad idea
#7(disclaimer, MS employee, non-security expert here). I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it. In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're…
The point the register makes is not that this allows unlocking devices (though that's interesting in it's own right), but that is done via a "secret key" that now got exposed. Very similar to what the government wants with key escrows and other backdoor mechanisms for decryption of communication.
Maybe to clarify: it highlights the mechanism (golden key) is flawed. That Microsoft uses it for boot loaders is unimportant.
Re: Microsoft proves backdoor keys are a bad idea
#8(disclaimer, MS employee, non-security expert here). I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it. In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're…
I don't know the full set of security measures on Windows RT devices, but if it doesn't have an effective hardware-level flash write protection in place, you should be able to change the policy with admin/kernel code execution rights, allowing for remote installation of a rootkit.
Besides, it is a worthy goal to protect a device from physical manipulation as well, i.e. to prevent border agents or secret agencies of a nondemocratic country from planting malware on your device.
The recent Apple vs. FBI debate has brought up a large number of arguments pro and contra protection from physical attacks.
Re: Microsoft proves backdoor keys are a bad idea
#9(disclaimer, MS employee, non-security expert here). I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it. In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're…
From the last section:
> 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.
Re: Microsoft proves backdoor keys are a bad idea
#10(disclaimer, MS employee, non-security expert here). I've read through the article, here, and in other places, and I'm seeing sentiment that this is a big fuck up on Microsoft's part. I might be completely misunderstanding, but I just don't see it. In order to use the backdoor, you've got to flash firmware, so, you've got to have physical access to the device. If an attacker has physical access to your device, you're…
> Isn't a secure boot policy that can be bypassed with physical access more secure than none?
Of course it isn't. Impossibility of bypassing is the only reason for secure boot technologies to exist. They are invented so that you are NOT automatically screwed if an attacker has physical access to your device. Secure boot technology is fine in principle, it's just stupid position the manufacturers hold. They ignore recent history. At their own peril, I'd say. https://en.wikipedia.org/wiki/Clipper_chip
And I'm not even sure physical access factor is strictly necessary for adversarial bypassing.
(I'm not a security expert, too.)