Monday, April 22, 2013

Microsoft's EMET 4.0 - a free enterprise security tool for blocking Windows exploits

Last week Microsoft announced their 4.0 beta release of EMET (Enhanced Mitigation Experience Toolkit). If you are responsible for securing Windows systems, you should definitely be looking at this free tool if you haven't already.

EMET is a toolkit provided by Microsoft to configure security controls on Windows systems making it more difficult for attackers to successfully launch exploits. EMET doesn't take the place of antivirus or patch management, but it does provide an important set of safeguards against not only existing exploits, but also against future 0-day exploits which have yet to be developed or released. Even the best signature-based antivirus programs don't do a good job at protecting from 0-days.

EMET allows administrators to exercise fine-grained control over Windows' built-in security features in Windows 7 and higher, including:



While DEP and ASLR have been supported by Microsoft since Windows XP SP2 and Windows Vista (respectively), one of the main weaknesses of this mitigation is that existing applications needed to be recompiled by the developer to "opt-in" to these security controls.  A great benefit of EMET is that it allows administrators to "force" DEP and ASLR onto existing legacy applications.

While there are many exploits out there which bypass DEP and ASLR, it's worth noting that the first versions of these exploits are sometimes thwarted by these controls, which buys you some time for either patches or antivirus detection to become available. There are good reasons why the Australian DSD (Defense Signals Directorate) has included DEP and ASLR on its "Top 35 Mitigations" for two years running.

EMET 3.0 and 3.5 introduced the ability to manage EMET via GPO, putting installation and configuration within reach of the enterprise. EMET 4.0 builds on this feature set and includes some very useful new protections, including:

  • SSL certificate pinning - allows mitigation of "man-in-the-middle" attacks by detecting situations where the Root CA for an SSL certificate has changed from the "pinned" value configured in EMET. For example, you can configure EMET to say "There is only a single trusted root CA that should ever be issuing certificates for acme.com, and if I see a certificate for any FQDN ending in .acme.com from a different CA, report this as a potential man-in-the-middle attack. You can pin the CA for entire domains or for individual certificates. EMET 4.0 beta ships with pinned certificates for login.live.com and login.microsoftonline.com, but administrators can add their own.
  • Enhanced ROP mitigation. There is a never-ending arms race between OS and application developers on the one side and exploit developers on the other side. When a new mitigation technique is developed by Microsoft, clever exploit developers work hard to find ways to bypass the mitigation. In the case of ROP mitigations, EMET 3.5 included some basic ROP mitigations that blocked assembly language "return" calls to memory addresses corresponding to known lists of low-level memory management functions in certain DLLs. This rendered a common exploit technique ineffective. However, exploit developers responded with adjusted techniques to bypass EMET's ROP mitigations, such as returning into the memory management code a few bytes beyond the function prologue. I don't have enough time or space to do this fascinating topic justice, but you can read a good overview of ROP exploit techniques here.

    EMET 4.0 blocks some of these mitigation bypass techniques, which puts the onus back on exploit developers in this cat-and-mouse game. I'm looking forward to the first white paper detailing how the new mitigations can be bypassed.
  • Improved logging. With the new and improved EMET notifier agent, EMET 4.0 does a much better job at logging events to the Windows event log. This opens up the possibility of using a centralized event log monitoring systems such as Microsoft Systems Center Operations Manager (SCOM) 2012 to act as an enterprise-wide early detection system for exploit attempts. Imagine having instantaneous alerting any time EMET blocked an attack on any Windows system across the enterprise.

    One could also use a free tool like event-log-to-syslog to gather event logs centrally, or even something like Splunk (with universal forwarders) if you don't mind breaking the bank.

    Another benefit of centrally logging and analyzing EMET events is it will give you early warning on EMET compatibility problems. Past versions of EMET have been known to cause problems with certain applications, for example I found that the LastPass extension for Chrome needed certain EMET settings disabled in order to run. If you haven't used EMET before in your enterprise, you will definitely want to introduce EMET in a limited rollout before going enterprise-wide via GPO. Note any programs requiring exemption or settings customization and make sure those settings are reflected in the GPO policy.
Update 4/22/2013: +gaten guess was nice enough to point out that ASLR was introduced in Vista, not Windows XP so I clarified my comments above. Many of these controls work poorly or not at all in XP, so it goes without saying that if you're running Windows XP anywhere in your enterprise, EMET should be the least of your worries. :)

ShareThis