Friday, 13 April 2012

Microsoft EMET in The Enterprise

Update May 16, 2012: Since originally posting this article Microsoft have released EMET v3.0 which further facilitates enterprise deployment. We encourage you to go and read the technet article.

It's Friday, so it's time to take a step back from the low-level and have another post on the practical steps organisations can take at little cost. Before we begin it's probably useful to outline some of the realities of business when it come to desktop and server security. These realities should come as no revelation:
  • Organisations can't always jump to the latest version of Windows for many years (if ever).
  • Organisations can't always jump to the latest version of software due to compatibility reasons.
  • Not all software vendors jump to the latest compilers and enable all the security features.
  • Not all software vendors have, follow or have heard of a Secure Development Life-cycle
As a result organisations need to contend with:
  • Software with known vulnerabilities that they can't upgrade from.
  • Software with unknown vulnerabilities that they can't upgrade from.
  • Software without mitigations against memory corruption vulnerabilities that fall under either of the previous two points.
  • Ageing versions of Windows that don't have the latest defensive mechanisms available.

To help organisations address some of the security skeletons on Windows Microsoft provides the Enhanced Mitigation Experience Toolkit (EMET). While EMET isn't a panacea or without small print it can provide excellent return on investment if you're trying to secure an ageing software infrastructure or have operational delays in patch deployment. When it comes to  how to do deployments of EMET in the enterprise Microsoft's (KB article) answer is:
"With the current version, the easiest way to deploy across an enterprise is by using the command prompt utility. To do this, follow these steps:
Install the MSI on each of the target computers. Or, put a copy of all the installed files on a network share. 
Run the command prompt utility on each of the target computers to configure EMET.
Note You can use many different techniques to do this, including using the System Center Configuration Manager. If you put EMET on a share, make sure that you run the command prompt utility from that share. When it runs, it will copy over the necessary files to the Windows directory, and it will make any needed registry changes.
We realize that this technique is not convenient for many enterprises. For the next version, we are working on making it easier to deploy and manage EMET in an enterprise environment"
We thought it would be useful to summarise some additional advice we've devised and information we've come across around EMET in enterprise. These points / areas are designed to further ease configuration, testing and deployment of EMET without creating mayhem.

EMET Development, Testing and Deployment Plan
When deploying EMET in your organisation we recommend a high-level plan similar to the below be used:
  • Development: EMET Configuration Development 
    • Deploy standard organisation desktop and server builds
    • Identify applications that need protection:
    • Identify the executable files that comprise the application
    • Configure EMET for identified executable files
  • Testing: Compatibility
    • Run standard common business function testing on all newly protected applications
  • Deployment: Phase 1
    • Deploy to 1% of user base having good representation from all departments
    • Monitor for increase in support calls related to unexpected application crashes
  • Deployment: Phase 2
    • Deploy to an additional 5% of user based having continued representation from all departments
    • Continue to monitor support calls
  • Deployment: Phase 3
    • Deploy to an additional 19% of user base, continue to monitor
  • Deployment: Phase 4
    • Deploy to remaining user base in 25% chunks with a month or so in-between
  • Maintenance
    • Continue to monitor standard builds and threat space for new applications that may be deemed appropriate for protection

Recx EMET Configuration Builder
Developed by Recx, it scans a directory and produces an EMET configuration files for all discovered binaries.

Developed by David Delaune, it is an extremely useful third-party EMET GUI for configuring, testing and redeploying EMET configurations. David was working with an embedded use-case and as a result removed the .NET dependency that the original EMET GUI has. He has also provided some enhanced features over the standard EMET GUI such as being able to supply additional heap address pre-allocations.

Developed by Tom Webb, he provides in this blog post:
  • An EMET configuration file protecting the following applications (mixture of 32bit and 64bit):
    • Adobe Acrobat Reader 9.0
    • Adobe Acrobat  Reader 10.0
    • Oracle (Sun) Java Run-time 6
    • Mozilla Firefox
    • Microsoft Internet Explorer
    • Microsoft Office 2007
    • Microsoft Office 2010
    • Microsoft Media Player
    • Apple iTunes
    • Apple QuickTime
    • VMWare Tools
  • VBS based deployment script that protects Google Chrome:
    • As Google Chrome is installed under each users home directory

The EMET Community
There is an excellent thread on the Microsoft communities about EMET which covers:

  • How to silent install EMET from the .MSI
    • msiexec.exe /i "EMETSetup.msi" /qn /norestart
  • A batch file protecting the following applications  (mixture of 32bit and 64bit):
    • Oracle (Sun) Java Run-time 6
    • Microsoft Office 2003
    • Microsoft Office 2007
    • Microsoft Office 2010
    • Microsoft Internet Explorer
    • Microsoft Media Player
    • Apple QuickTime
    • Winzip
    • Adobe Acrobat Reader 8.0
    • Adobe Acrobat Reader 9.0
    • Adobe Acrobat Reader 10.0
    • IBM Lotus Notes
    • Apple iTunes
    • Opera
    • Mozilla Firefox
There is also:

Vendor and System Integrator Call to Action
So vendors and system integrators what can you do? There are several things, yes they'll cost you some time and money but they'll also go along way in both presenting your organisation as both security aware while also helping your users maintain a level of security.
  • Vendors negotiate with Microsoft to re-distribute EMET as part of your installers
  • Test your applications for EMET compatibility and document externally 
  • If you can't recompile / use the latest tool chain ship EMET configurations for compatible components
  • For all end of life products ship and document one final 'EMET sunset patch' to provide those organisations stuck on these versions with a level of tested protection.

Anyway, we hope you've found this post useful. We've been contemplating an EMET Compatability Database to correlate peoples testing and compatibility experience of different products. We think this is especially important for big enterprise solutions such as older version of Microsoft Exchange, Microsoft SQL Server, Microsoft IIS, Oracle and SAP etc. If you think this initiative would be worthwhile either leave us a comment below or ping us on twitter @RecxLtd.

Technical Bonus Material
O.K. you've read this far down. Time for a little technical bonus material.
  • Fermin's Microsoft slides on EMET
  • Uses AppCompat, deploys its SDB by updating  the registry key
    • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\InstalledSDB
  • Registry key
    • Contains interestingly named 'EnableUnsafeSettings'  but is not used by the injected DLL
  • AppCompat Injected Libraries
    • C:\Windows\AppPatch\EMET.dll gets injected for 32bit
    • C:\Windows\AppPatch\AppPatch64\EMET64.dll gets injected for 64bit
  • Processes using EMET have an environment variable set
  • Processes using EMET create an event:
    • \BaseNamedObjects\EMET_PID_[PID]
  • Injected DLL uses RtlRandom instead of RtlRandomEx for randomisation (no great shakes).

No comments:

Post a Comment