Thursday, 20 July 2017

Device Guard on Windows 10 S

This blog is about Device Guard (DG) on Windows 10 S (Win10S). I’ll go through extracting the policy and finding out what you can and cannot run on a default Win10S system. Perhaps in a future blog post, I’ll describe some ways of getting arbitrary code execution without installing any additional software such as Office or upgrading to Windows 10 Pro.

Win10S is the first Windows operating system released to consumers which comes pre-locked down with DG. DG builds upon Kernel Mode Code Integrity (KMCI) introduced in Windows Vista and User Mode Code Integrity (UMCI) which was introduced in Windows 8 RT. It contains many features to restrict code execution by limiting what types of executable files/scripts, including DLLs can be loaded based on a set of policy rules. A good first step towards trying to find ways to run arbitrary code on a system with DG is to extract the DG policy and inspect it for weaknesses.

Before we start, I'd like to thank Matt Graeber for reviewing this post before it went out. His DG knowledge is far better than anyone I know.

Extracting the DG System Integrity Policy

The enforcement of DG is configured through a System Integrity (SI) policy. The SI policy is stored as a binary file on disk. When the operating system boots either WINLOAD or the kernel CI driver loads the policy into memory and begins enforcement based on the various rules configured.

The location of the file varies depending on how the policy was deployed. On the Surface Laptop I have, which comes with Win10S pre-installed the policy is located inside the C:\Windows\Boot\EFI folder with the name winsipolicy.p7b. There’s no restrictions on reading this file to extract its contents to determine what policy is enforced. Unfortunately, there’s no official documentation I know of which describes the binary policy file format. There is the ConfigCI Powershell module which will convert an XML file to a binary policy. Unfortunately, there’s no corresponding command to perform the reverse.

Fortunately, the ever amazing Matt Graeber put in the effort and wrote a Powershell script which can convert the binary format back to the XML format. Unfortunately, there was some issues with the original script, such as missing some new additions to the format that Microsoft have added as well as a couple of bugs. Therefore, I’ve tweaked the original to fully support the policy format used on Win10S as well as fixing some bugs. Matt updated his copy on github with my fixes, you can get it from here. Load the script into Powershell then run the following command:

ConvertTo-CIPolicy winsipolicy.p7b output.xml

The result of the conversion is an XML file we can read. As with the binary file, the XML file is poorly documented, the best resource is almost certainly Matt Graeber’s blog, specific this post. Let’s break it down into small sections.

System Integrity Policy Rules

The first important section are the Rules which define a set of boolean options to enable in the System Integrity policy.

The first option enables UMCI. By default, DG doesn’t enforce UMCI, although it does enforce KMCI. The second option enables the Advanced Boot Options Menu, this is interesting as by default the menu would be disabled and this policy allows the user of the system to have more control over the boot process. This configuration will become important in a later blog post. The third option Enforces Store Applications. This ensures you can’t disable UMCI for store applications. Without this setting, it’d be possible to configure a side-loading policy to allow you deploy your own UWP applications. As the purpose of Win10S is “security,” they only allow UWP applications which are store signed, I’ll explain what that means in the section on allowed signers. Finally, Conditional Windows Lockdown Policy seems to be related to the Windows 10 S SKU and the potential that the lockdown policy can ultimately be disabled. This is related to the license values and a system environment variable “Kernel_CI_SKU_UNLOCKED”. This probably needs further investigation.

File Rules

Next up are the set of file rules. These are usually used to blacklist specific executable files which are known DG bypasses and would allow you to trivially run arbitrary code. This is close to the same list provided by Microsoft in their DG deployment guide here. However, they also block things like registry editing tools and Windows Scripting Host.

For each deny rule, the policy specifies a filename and a minimum file version. Note that the minimum version is really the maximum when it comes to a deny rule. In the sense that the rule only applies to files with a version number less than that specified. As every rule has the version set to 65535.65535.65535.65535 which is the absolute maximum it ensures that no version of these executables can ever execute. The filename and version are extracted from the executable’s version resources, this means you can’t just rename cmd.exe to badger.exe, the policy will see the Original Filename inside the version resource and block execution. If you try and modify the version resource then the file’s signature no longer matches and you won’t pass the signing policy.

It’s not really clear why Microsoft went all out and blocked things like CMD other than to annoy users. Sure, you could use it to run commands but you’re still somewhat limited by what executables you can run based on the signing policy. PowerShell and WScript I can perhaps more understand, but as we’ll see later, these file policy rules only serve as a speed bump to prevent us getting arbitrary code execution.

Allowed Signers

Now we get on to what signers the DG policy will allow (assuming of course they’re not blocked by the file rules). First, the DG policy defines the list of allowed signers, this list is then referred to later in the policy configuration. The list of allowed signers is as follows:

The majority of the signing certificates use a special “Wellknown” format with just a single numeric value which identifies the certificate. Finding out what certificates these correspond to can be tricky, again poor documentation. Fortunately, the Powershell ConfigCI module on Win10S has example policy files such as Default_WindowsEnforced.xml which at least gives them names if not spelling out the explicit certificate used (they could be multiple Microsoft Product Root 2010 certificates after all). It’s likely for example that “Microsoft Product Root 2010” is the following root which is the root certificate of pretty much all the signed files on Win10S:

However, it’s not enough to be signed by whitelisted signer that’d be too easy. You must also have in the certificate chain a specific Enhanced Key Usage (EKU). So for example signer ID_SIGNER_WINDOWS_PRODUCTION_USER must have the EKU ID_EKU_WINDOWS which has the OID value 1.3.6.1.4.1.311.10.3.6. The Windows binaries have this EKU set, but something which is also Microsoft signed such as WinDBG is signed by the same root but doesn’t have this EKU set meaning it doesn’t load. From this information we can understand what it means to be store signed. It’s a combination of a specific certificate chain and a specific Store EKU. This is reflected in the ID_SIGNER_STORE signing rule.

The only thing which stands out here is the user mode signing for ID_SIGNER_DRM which is because it’s a pre-trusted root key for DRM. And as I’ve blogged about before, it’s almost certainly possible to get a private key for a certificate which chains to this root from many graphics drivers (see my blog post here). I’ve not tested it but while you could chain to this root by grabbing the private key from the kernel driver (assuming it’s in software), the chain you could build probably isn’t suitable for code signing anyway. But again it’s something worth looking at.

The final use for signers is specifying who’s allowed to sign and update the policy. In order for a policy to be used unsigned there must be the “Enabled:Unsigned System Integrity Policy” set, however as we saw earlier in this blog that wasn’t the case. You can see which signer is allowed to sign the policy in the following snippet.

This policy is using ID_SIGNER_WINDOWS_PRODUCTION_USER_2011 which if you look back at the signers is a To-Be-Signed certificate rather than a well known one. So we’d need to find the actual certificate which matches this hash value. However we can guess, it’s almost certainly just one of the roots for signing the existing winsipolicy.p7b file. We can use the Get-CIBinaryPolicyCertificate cmdlet from Matt’s script to dump the certificates and then use the ConfigCI Powershell module to generate the TBS value. Which we can see matches up with the TBS value from before:

Conclusions

Overall, from a basic DG policy perspective, Win10S seems reasonable. Effectively, only Microsoft signed code can run and then only ones with either WHQL or Windows EKUs in the certificates which would make it tricky to the find anything useful outside of what’s installed with the operating system to exploit. Of course with Desktop Bridge applications, which are effectively store signed Win32 applications and the general quality of Windows driver developers no doubt there’s some additional code which can be exploited by installing it onto the system. You just have to look at Office, which is allowed to be installed from the Store which has its VBA macro functionality intact.

What is missing though is any use of Hyper-V based enforcement, either to restrict removing the policy or ensure kernel mode integrity through HyperGuard or HVCI code integrity enforcement. This is a severe weakness, it’s not like Win10S doesn’t support Hyper-V, you can even install the full Hyper-V and configuration tools. This allows you to run a normal version on Windows in a VM on top of the locked down platform which is actually kind of nice. But it means that the System Integrity policy is not very well protected. This is something which we’ll come back to at a later date in a future blog post.