Device Guard - Fixing VMWare Tools
Last updated
Last updated
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
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
