8

Today, tech media outlets are discussing the discovery of an integrated backdoor hidden within the SecureBoot feature of mobile Windows 10 operating systems. It seems that, from a surface reading of the nature of the vulnerability, that exploitation requires physical access. That is to say, it doesn't seem to be an attack that can be performed remotely; an attacker would need to actually steal the device to make use of it.

What sort of use might this vulnerability have to an attacker with respect to end-users (what sort of scenarios does it open up to an attacker), and what (if any) mitigating steps should an end-user take?

Bradley Evans
  • 275
  • 2
  • 6
  • 2
    It makes it easier for malware that is already on your pc to take over the boot progress and completely overtake your pc – Jonas Wilms Aug 12 '16 at 05:25
  • 2
    Thank you, thank you for asking a question about this in a far clearer and far, far more concise way than I could come up with. (The way I tried to ask it is here: http://security.stackexchange.com/questions/133572/windows-secure-boot-compromise-are-fully-patched-pcs-vulnerable?rq=1 .) I am going to edit my question to put a link to this one prominently in it. – mostlyinformed Aug 30 '16 at 02:46
  • @halfinformed Is your question similar enough that you're willing to flag it as a duplicate of this one and get the banner at the top? – Mike Ounsworth Sep 02 '16 at 15:48

1 Answers1

4

SecureBoot is a part of UEFI and other firmwares that can be used to verify signatures on the software that will be loaded at boot. This is usually a bootloader, but it can also be the OS itself.

On some implementations the user can "burn" a custom certificate for the firmware to use for validation. In other cases the certificates are preloaded by the manufacturer and only software signed by them can be used on the device.

Embedded devices like phones and tablets usually fall under the second category, where the user can't change the installed software except where allowed by the manufacturer (i.e., an OS update).

By breaking this lock, users would be allowed to install anything they want. This is usually called "jailbreaking" the device.

The problem with jailbreaking is that it also allows bad actors to compromise the device at a low level, which makes the threats more persistent and difficult to detect.

Different devices have had different methods for jailbreaking accross the years. In this case it was a snafu by Microsoft that allowed it. From the original write up (perhaps NSFW):

[secure boot policy is] 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.

This is a very clever and extensible scheme that was broken by an overlook during development:

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). [...] 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.

In other words, they have a signed policy that allows them to load unsigned binaries, presumably to allow for testing development versions without having to sign each one.

They accidentally shipped this policy in some devices, someone discovered it and published it, and it can now be loaded on any device.

The write-up goes into a lot more detail about how it works. The point is that this is a jailbreak exploit. For some it's good news, for others not so much.

Successfull exploitation requires admin rights or physical access.

@Bradley mentioned in the comments that "It makes it easier for malware that is already on your pc to take over the boot progress and completely overtake your pc". While true, it means the malware already had admin rights on the device, so the boot compromise is the least of your problems.

Microsoft has stated:

The jailbreak technique described in the researchers’ report on August 10 does not apply to desktop or enterprise PC systems. It requires physical access and administrator rights to ARM and RT devices and does not compromise encryption protections.

But that may have been an understatement. They released two patches: MS16-094 and MS16-100. The first one states:

An attacker must have either administrative privileges or physical access to install a policy and bypass Secure Boot.

This security update is rated Important for all supported editions of Windows 8.1, Windows RT 8.1, Windows Server 2012, Windows Server 2012 R2, and Windows 10. [...] The security update addresses the vulnerability by blacklisting affected policies.

So it's either root or physical access, as mentioned before.

And it does affect desktops and servers (see comments discussion for speculation on why they might have said it didn't).

Also, the policy blacklisting was deemed insufficient: rolling back to an older bootmgr could still allow for the policy to be loaded (this is mentioned in the write up). The second patch also blacklists old boot managers to address that.

TL;DR: Patch your windows systems and don't worry too much about this. There are far worse issues.

GnP
  • 2,299
  • 1
  • 15
  • 25
  • Actually, I think the MS statement you quoted means that the attack shouldn't work at all on x86 PC & servers. Unless I'm missing something. (Which I might be.) – mostlyinformed Aug 30 '16 at 02:49
  • This is probably a stupid question, but just to clarify for people stumbling into this from Google regarding this golden key thing, mitigation is more or less a moot point because exploitation requires physical access and administrative privileges, correct? – Bradley Evans Aug 30 '16 at 05:26
  • @halfinformed the problem affects all platforms, but x86 desktops and servers are usually unlocked already. – GnP Sep 02 '16 at 15:02
  • @Bradley-Evans depends on threat model :-). If you have FDE this could be used to trick you into giving away the key (through an evil-maid attack). – GnP Sep 02 '16 at 15:13
  • @GnP I'm a bit confused by what you mean "unlocked already". They are certainly unlockable, in the sense that a user can go into boot settings and turn Secure Boot off on them, where that's not the case on, say, an ARM-based Windows device. Though if you have a password protecting those settings, the ability to unlock then comes down to how secure that UEFI password is against easy reset. Which, IIRC, often requires physically opening the case & accessing the motherboard. Which would rule out both remote malware-implemented abuse and the fastest/most practical varieties of Evil Maid attacks – mostlyinformed Sep 02 '16 at 20:50
  • @halfinformed I'm saying that's why Microsoft said it only affects RT platforms. The "golden key" can be used to bypass secureboot on all platforms including x86. – GnP Sep 02 '16 at 20:59
  • @Bradley-Evans To be quite honest, l'm still a little unsure myself with whether physical access is required or not. The researchers's explanation seems to suggest it might not be. But much of the news coverage I've read suggests that it is. (Although much of that explanation is inscrutable as heck.) At the same time, almost all of that same coverage has otherwise contained gross technical errors about what's going on here. So... – mostlyinformed Sep 02 '16 at 21:16
  • @GnP . Uh...forgive me, but I think those two things are diametrically opposed to each other. Unless this approach does turn out to work on x86 PCs and servers (contrary to what Microsoft said) there's no widely-applicable way to bypass the protection (unless your are physically at the keyboard of the machine and either the UEFI console isn't password-protected or you can physically access the innards of the machine to reset that password). The was no other, actual release of any.cryptographic key, just this exploit approach that people have misnamed "Golden Key" – mostlyinformed Sep 02 '16 at 22:41
  • @halfinformed check my updated answer. You're reading too much into Microsoft's press release. It does affect x86. And I didn't say any actual crypto key was leaked, it's clear that by "golden key" (notice the quotes) I meant the issue at hand. – GnP Sep 02 '16 at 22:54