The Enhance Mitigation Experience Toolkit (EMET) has to be one of the Microsoft security tools that I recommend the most to organizations of all sizes, friends and family do to that it helps curve in many cases the window of exploitation for many client side attacks when configured right on client machines in the network. EMET also provides protection for known vulnerabilities that have not been tailored to bypass it and against 0 day client side exploits for known software.
Many other people have written about the capabilities of EMET so I will not cover all the new features added and new capabilities in 4.0, in fact the documentation from Microsoft is great http://www.microsoft.com/en-us/download/details.aspx?id=39273 it covers how to deploy EMET via Group Policy and how to deploy it using System Center Configuration Manager. The documentation also cover all the features in great detail so I will not bore you regurgitating that information from there.
Now for this blog post it will part from some pre-conceived notions:
- All machines where we will deploy EMET are part of a Domain.
- WSUS is configured and issuing patches to the machines in the domain.
- You have organized your machines in to groups and your deployment of EMET is planned along this groups.
Checking for dependencies
The first thing we will do is log in to our WSUS console and make sure that we have deployed .Net Framework 4.0 to all the machines we want to install EMET on. First thing we do is we check that in the option that under classifications that Feature Packs is selected if not available under Updates:
If we have Windows 8 client machines in the network we also check for KB2790907
Configuring WSUS Package Publisher
The tool we will use to to publish thru WSUS EMET is the WSUS Package Publisher tool, it is an Open Source Tool that can be found at http://wsuspackagepublisher.codeplex.com/ This tool allows us to publish MSI Packages, executable and MSP files. The tool also has reporting capabilities that can be use to determine the deployment of the packages. This is a great alternative for small to medium organizations that need to deliver packages like Java, Adobe Reader and Flash and make sure their machines are update in a timely fashion and not have to wait for a user to either log in to the machine or the machine to reboot like in the case of using GPOs. The perfect scenario would be to have a Third party patch management system like Tivoli Endpoint Manager or use Microsoft own System Center Configuration Manager but many do not have the resources for this solutions since they can be complex and expensive.
Thankfully the author of the project has done great documentation on how to use the tools including examples for common packages http://wsuspackagepublisher.codeplex.com/documentation
There are 2 ways to run the tool:
- Locally in the WSUS server.
- Remotely from a management station, the WSUS server has to be configured to use SSL in this case http://technet.microsoft.com/en-us/library/bb633246.aspx
The prerequisites for running the tool are :
- Microsoft .NET 4.0 must be installed on the local machine.
- The user must be Administrator of the local machine.
- The WSUS server must be at release 3.0 SP2 or greater.
- The user used must be part of “WSUS Administrators” group of the WSUS server.
- In the case it is ran from a management workstation the RSAT tools must be installed and the WSUS Management console has to enabled.
We start by clicking on the download button and downloading the latest version of the tool.
After downloading the zip file:
- Right click on the download zip file and select Properties.
- Click on the Unblock button.
- De-compress the archive and all files should have inherited the unlock we did on the zip file.
Once the package is decompressed we launch the executable “Wsus Package Publisher.exe”
Once the application is launched depending on the environment and if the tool is ran locally or remotely connection setting will have to be set. For configuring the connections setting go to Tools –> Settings and make sure that the server is the correct one, check the credentials and if SSL will be used or not. The rest of the settings can be left with the defaults.
If you are running the tool in the same machine as the WSUS server with default values or if you already set the settings for your WSUS server you can just click on the Connect/Reload button to connect to the server.
Once connected to the server we can create a Self Signed certificate for use with WSUS for publishing packages. The way WSUS works all packages distributed by the server are signed digitally and the machines where the packages are deployed need to trust the Root CA for the certificate used and also trust the Publisher. For simplicity we will use self signed certificates and then distribute them using Group Policy Objects. The documentation for the projects does cover in detail how to use a Windows Certificate Authority or a third party authority for this.
To generate the certificate go to Tools –> Certificates.
- Click on the Generate the Certificate button and wait for the message that the certificate has been generated successfully.
- Click on the Save the Certificate button and give the certificate a friendly name and store it an a safe place since the certificate will be deployed via GPO in a later step.
You will need to restart the WSUS Server services for the Certificate to be loaded. On the WSUS Server open PowerShell and type:
Get-Service wsus* | Restart-Service -Verbose
This will restart all services that start with the letter WSUS and will show the actions taken since the –Verbose option was used.
You can also use PowerShell to verify if the certificate was installed properly on the WSUS server:
PS C:\Users\administrator.ACMELABS> Get-ChildItem Cert:\LocalMachine\WSUS\ -CodeSigningCert
Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\WSUS
Thumbprint Subject
---------- -------
681249451028091B250828DA56D70FD2A3547FE5 CN=WSUS Publishers Self-signed
Once we have confirmed that the certificate has been stored properly we can deploy the certificate to our infrastructure using Group Policy and ensure the certificate has been applied to all the hosts in the network before we add the package for deployment.
From the Group Policy Management Console we can edit the GPO that we use for configuring WSUS on our client machines so as to keep all settings related to patch management on one single Policy Object.
- Open the appropriate group policy for editing
- Expand “Computer Management” -> “Policies” -> “Windows Settings” -> “Security
Settings” -> “Public Key Policies”
3. Select the certificate that was exported earlier.
4. Repeat the steps for importing but this time for Trusted Root Certificate Authorities.
5 . Expand “Computer Management” -> “Policies” -> “Administrative Templates” -> “Windows Components” -> “Windows Update”
6. Enable "Allow signed content from intranet Microsoft update service location” if you do not enable this feature you will receive an error with code 800b0109 when it tries to validate the signature of the file when the client downloads it.
Once the Group Policy is updated in the background every 90 minutes, with a random offset of 0 to 30 minutes, this means that it can take up to 2 hours for the update to actually apply to your client machines.
If you have a Window 2012 Domain Controller and you have not done this already I recommend you use a New feature in Windows 2012 Domain Controllers that is a templates that will open the correct ports on remote windows machines so as to be able to force a GP Update remotely, this could prove quite useful when one has to push changes in a quick manner like when responding to an incident. On a Domain Controller open PowerShell and run the following command to create and link the GPO, modify the DN so it will match your environment in this case it is for my lab domain acmelabs.com:
Neww-GPO –Name "Configure firewall rules for remote gpupdate" –StarterGpoName "Group Policy Remote Update Firewall Ports" | New-GPLink –target "dc=acmelabs,dc=com" –LinkEnabled yes
Once it is linked and the policy has been applied to all machines in the domain you can invoke a Group Policy update across my domain from a Windows 2012 machine as Domain Admin in PowerShell:
Get-ADComputer –filter * -Searchbase "dc=acmelabs,dc=com" | foreach{ Invoke-GPUpdate –computer $_.name -force}
On a client machine we can verify that the certificate was propagated by using PowerShell to check the store and compare the certificate fingerprints with the one we saw earlier when we generated the cert.
PS C:\Users\Administrator> ls Cert:\LocalMachine\TrustedPublisher
Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\TrustedPublisher
Thumbprint Subject
---------- -------
681249451028091B250828DA56D70FD2A3547FE5 CN=WSUS Publishers Self-signed
Creating a EMET 4.0 Update and Publishing It
Before we deploy the package we have to set the ground for it in the case of EMET. First we need to download the MSI and install it on a Management Workstation since the installation will include the ADMX GPO Policy Templates we will use to manage EMET configuration centrally. We can Download the file from http://www.microsoft.com/en-us/download/details.aspx?id=39273 Once installed the ADMX files will be located on:
- For x64 Systems C:\Program Files (x86)\EMET 4.0\Deployment\Group Policy Files
- On x86 System C:\Program Files\EMET 4.0\Deployment\Group Policy Files
Depending on how you manage your ADMX files either centrally or per Domain Controller you will need to copy the files to their proper location so they can be used (http://technet.microsoft.com/en-us/library/cc709647(v=ws.10).aspx).
On a DC by DC solution you need to copy your ADMX file to SYSTEMDRIVE\Windows\PolicyDefinitions and the ADML to SYSTEMDRIVE\Windows\PolicyDefinitions\en-US if you are using centralized management of the policy files you would copy them to %logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions and %logonserver%\sysvol\%userdnsdomain%\Policies\PolicyDefinitions\en-US respectably.
We can now set a base configuration for EMET. I recommend you test the settings in your environment first since different vendors have different coding standards and some applications may be affected by EMET. For this example I will use a base configuration using Microsoft recommended settings for popular apps and enable most of the protections.
In the Group Policy Management Console we can create a new GPO or use an existing one for security settings and edit it (Do not use the Default Domain Policy GPO!) Expand “Computer Management” -> “Policies” -> “Administrative Templates” -> “Windows Components” -> “Windows Update” and set the parameters to fit in your environment:
Once configured and linked we can create the package for deployment, we start by using the WSUS Package Publisher
- Select Tools –> Create an Update
- In the next screen select the EMET MSI package to be deployed, this is the file we downloaded from Microsoft
- We click on Next and set a Product Name, Description and Info URL. Depending on your internal policy and environment you may wish to modify the Package Type, Impact and if you want it to reboot after the installation or not. EMET does require a Reboot after being install so it can set different hooks in APIs and Memory. Click on Next on the other screen accepting the default values
- Once the package is published and signed we need to approve the package from the WSUS Package Publishing application.
- Once we click on Approve it will bring up a window for us to decide to what computer groups it will apply this is one of the limiting factors of using WSUS, your strategy has to match your computer groups.
The package should now be available to your machines thru Windows Update on those that use the the WSUS Server and in the group you deployed the package to:
On Windows 7
On Windows 8
Installation is as simple as accepting the install.
Hope you find this blog post useful and that it serves as a base for your deployments in your environment.