Saturday, 1 July 2017

Device Guard - Fixing VMWare Tools

I've been really keen to try Device Guard out lately and I finally rolled up my sleeves and used Matt Graeber's excellent guide found at:

http://www.exploit-monday.com/2016/09/introduction-to-windows-device-guard.html

http://www.exploit-monday.com/2016/12/updating-device-guard-code-integrity.html

All this work is based on his work and full credit goes to him. I wanted to write this post in case someone finds themselves in the same situation I was in; simply wanting to get familiarized with Device Guard using their own mini home lab. Using VMWare Workstation with Device Guard won't enable every feature available in Device Guard, but it's a good starting point to get familiar with deploying policies and just getting a general feel for the technology.

After following Matt's guide - VMWare tools refused to function and I want to outline how I got them working again using his posts and some Microsoft documentation.

I'm going to start off assuming you have followed Matt's steps and have a system deployed with Device Guard but with VMWare Tools in a non working state. The culprit, it seems, is sigc-2.0.dll



It looks like that particular dll isn't signed which doesn't jive with our originally created policies.

From this point we have to create a new policy specifically for VMWare tools which we will merge with our master policy. I used the following code:

$VMWareFiles = Get-SystemDriver -ScanPath 'C:\Program Files\VMware\VMware Tools' -UserPEs
New-CIPolicy -FilePath C:\DGPolicyFiles\VMWare.xml -DriverFiles $VMWareFiles -Level Publisher -Fallback Hash -UserPEs

This first line sets a variable with our scan path and then uses the New-CIPolicy cmdlet to create a policy using the publisher CA and then file hashes as a fallback method to generate a CI Policy.

Taking a peak at the policy that was generated, we see hashes generated for the various dll's within the VMWare tools folder, including our sigc-2.0.dll:


Now that we have a policy generated, we need to merge it into our master policy, I used the following code:

$CIPolicyPath = "C:\DGPolicyFiles\"

$MasterPolicy = $CIPolicyPath+"MergedAuditPolicy.xml"
$NewPolicy = $CIPolicyPath+"VMWare.xml"

Merge-CIPolicy -PolicyPaths $MasterPolicy,$NewPolicy -OutputFilePath $CIPolicyPath\MasterMergedVMWareRules.xml

This simply sets some variables with our path, including the original policy we used and our new VMWare Tools policy, the Merge-CIPolicy cmdlet is used to merge the two policies into one "Master Merged" policy. We then need to convert this policy and apply it, here I used Matt's code again, from his "Phase #4" portion ( http://www.exploit-monday.com/2016/09/introduction-to-windows-device-guard.html ) - I just changed the relevant variable in the following line:

$MergedAuditPolicyXml = Join-Path -Path $PolicyDirectory -ChildPath 'MasterMergedVMWareRules.xml' 

Now after a reboot, you should have a working set of VMWare tools.

A few notes ...

- You should take a close look to see what the generated VMWare Tools policy looks like and if you are comfortable trusting the dll's and exe's whitelisted.

- I am by no means an expert in Device Guard, I just really wanted to get a feel for it because it's a pretty awesome way to secure your assets and it's free. I'm sure there are more streamlined ways to script this or to lock down the policy tighter.

- Perhaps using hashes isn't the most robust or secure way to build a whitelist policy, but I couldn't seem to get VMWare tools working using just the publisher CA level.

- Again, all credit goes to Matt Graeber for writing the original guides.

Some helpful links:

https://technet.microsoft.com/itpro/powershell/windows/configci/new-cipolicy

https://github.com/MicrosoftDocs/windows-itpro-docs/blob/master/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md

http://www.exploit-monday.com/2016/11/code-integrity-policy-audit-methodology.html

http://www.exploit-monday.com/2016/10/code-integrity-policy-reference.html