Tuesday, July 02, 2013

toolsmith: EMET 4.0 - These Aren’t the Exploits You’re Looking For

Windows operating system
.NET Framework 4.0 or higher

In classic Star Wars parlance, have you been looking for improved tactics with which to wave off grievous Windows client exploits? Look no further; Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) 4.0 was released to the public on 17 JUN 2013 and quickly caught the attention of security aficionados and general press alike. KrebsOnSecurity even gave EMET full coverage and as always Brian’s quality work is well worth a read for the 101 perspective on EMET 4.0. So much of the basic usage, configuration, and feature set has already been covered or introduced that I’m going to simply refer you to the Kreb’s post as well as Gerardo Di Giacomo’s ThreatMitigation with EMET 4.0 as prerequisite reading material. I work with Gerardo at Microsoft and as with all toolsmith’s I sought insight on the tool in question. As his Threat Mitigation post had just gone live as we talked, I will simply draw a quick summary from there; you can read the rest for yourself. EMET is a “free utility that helps prevent memory corruption vulnerabilities in software from being successfully exploited for code execution. It does so by opting in software to the latest security mitigation techniques. The result is that a wide variety of software is made significantly more resistant to exploitation – even against zero day vulnerabilities and vulnerabilities for which an update is not available or has not yet been applied. EMET offers protections for all currently supported Microsoft Windows operating systems, and supports enterprise deployment, configuration, and monitoring.” I will give you the quick bullet list of features but will move quickly to what exploitation mitigations EMET 4.0 offers when tossing attacks via Metasploit against a protected system and applications. Following are feature highlights for EMET 4.0:
·         Certificate Trust: Detect Man in the Middle (MITM) attacks that leverage fraudulent SSL certificates
·         ROP mitigations: Block exploits that utilize Return Oriented Programming exploitation techniques.
·         Early Warning Program: Allows enterprise customers and Microsoft to analyze the details of an attack and respond effectively.
·         Audit Mode: Provides monitoring functionalities for testing purposes.
·         Redesigned User Interface: Streamlined configuration and improved accessibility.
Of note, the Early Warning Program sends information back to Microsoft. If yours is an organization that already does this via other enterprise means, this is already common place behavior, but if your preference is to keep such data in house you can disable Early Warning under the Reporting menu or use System Center Agentless monitoring to forward the telemetry data to an on-premise server that can be later used for forensics or post-mortem. In production environments, you may want to make use of Audit Mode before setting EMET to terminate programs when attacked. Audit Mode instead simply reports the exploitation attempt; helpful for monitoring potential compatibility issues between EMET and protected applications.
Installing EMET 4.0

Installing EMET is point-and-click simple. Just download, ensure you have .NET Framework 4.0 or higher installed, accept installation defaults (Use Recommended Settings), and you’re off to the races.
The EMET 4.0 User’s Guide included on the download page is a required read as well. I ran EMET 4.0 on a Windows 7 SP1 Enterprise 32bit VM with .NET Framework 4.0, Java 1.7.0_25, and Firefox 22 (really?).
For testing, enabled the Maximum security settings under Quick Profiles. This sets Data Execution Prevention (DEP) to Always On and Structured Exception Handler Overwrite Protection (SEHOP) to Application Opt Out as seen in Figure 1.

FIGURE 1: EMET deployed and ready
That said, on production systems, take baby steps. You can begin to add other applications than those protected by default (Internet Explorer, Java, Wordpad, Adobe Reader, Microsoft Office, etc.) but as mentioned above and in Kreb’s article, phase apps in to ensure they don’t struggle or crash with the added protection and “avoid the temptation to make system-wide changes.”

EMET 4.0 Mitigations and Blocked Attacks

First up, ye olde heap spray attack. Via Metasploit on my Kali Linux VM, I queued up the Microsoft Internet Explorer Fixed Table Col Span Heap Overflow (MS12-037) module. This module “exploits a heap overflow vulnerability in Internet Explorer caused by an incorrect handling of the span attribute for col elements from a fixed table, when they are modified dynamically by JavaScript code” and utilizes ROP chains as part of the attack. Drawing right from Rapid 7, as they describe heap spray techniques for Metasploit browser exploitation, a heap spray is a way to manipulate memory by controlling heap allocations and placing arbitrary code in a predictable place.  This allows the attacker, when controlling the crash, to trick a program into going to said predictable place and gain code execution. Figure 2 represents the attempted delivery of such an attack via MSF.

FIGURE 2: MS12-037 IE Col Span attack
On the Windows 7 VM, when browsing to my attacker server,, via Internet Explorer, EMET immediately responded with an application mitigation, shut down IE and popped a Tray Icon notification as seen in Figure 3.

FIGURE 3: EMET blocks HeapSpray attack
Given that EMET also writes events to the Windows Application Event Log, enterprises are afforded an additional monitoring opportunity as a result. No matter your Windows event collection mechanism, be it Windows Event Collector, Audit Collection Services (ACS), OSSEC, Snare and Splunk, or your preferred method, you can add an alerting mechanism (you may be feeding a SIEM) to give you a heads up when a client machine triggers an EMET event. Regardless, Figure 4 represents the Event Viewer perspective on our attack from Figure 2.

FIGURE 4: EMET event in Event Viewer
Another example includes the Mandatory ASLR mitigation. Address space layout randomization (ASLR) randomly arranges the positions of key data areas, to include the base of the executable, as well as position of libraries, heap, and stack, in a process's address space. Note that, as indicated in the EMET User’s Guide, EMET’s mitigations only become active after the address space for the core process and the static dependencies has been set up. Mandatory ASLR does not force address space randomization on any of these. Instead, Mandatory ASLR is intended to protect dynamically linked modules, such as plug-ins. When I browsed my Metasploit instance configured with the Internet Explorer CSS Recursive Import Use After Free module (MS11-003) enabled Internet Explorer was again terminated as seen in Figure 5

FIGURE 5: EMET Mandatory ASLR notification
Last but not least, I tested the Certificate Trust (Pinning) feature by manipulating the pinned certificates for login.live.com. EMET 4.0 protects the likes of Live, Yahoo, Skype, Twitter, Facebook and Office 365 by adding extra checks during the certificate chain trust validation process, with the goal to detect man-in-the-middle attacks over an encrypted channel. By default, EMET pins the certificate for a website to the good, trusted Root CA certificate; login.live.com is pinned to Baltimore CyberTrust Root, Verisign, GlobalSign Root CA, and GTE CyberTrust Global Root, as these are the Root CA certificates that are expected to have issued a certificate for login.live.com. I arbitrarily removed these and imported a Thawte Windows Trusted Root Certificate (trusted by Windows). This resulted in EMET sounding off with another “I don’t think so” as seen in Figure 6.

FIGURE 6: EMET trusts you not
As Thawte is clearly not the Root CA that issued the certificate for login.live.com, EMET flagged the SSL cert. By pinning the right certificates’ websites to their expected Root CA certificates, you can detect scenarios where a certificate is fraudulently issued from a compromised Root CA or one of its intermediates.
For you command line fans, you can choose to utilize EMET_Conf.exe. You’ll need to set C:\Program Files\EMET 4.0 in your PATH statement if you wish to call EMET_Conf.exe from any prompt. EMET_Conf.exe allows you to add applications, list those already added, list enabled mitigations and trusts, as well as remove, modify, import/export, and configure.
Remember, for those of you with enterprise deployment responsibilities, EMET can be deployed and configure with System Center Configuration Manager (SCCM), and EMET system and application mitigation settings can be configured via Group Policy.

In Conclusion

The release of version 4.0 brings EMET squarely in sight for users who may have been hesitant to utilize or deploy it. Now’s the time to investigate and engage (wait, that’s Star Trek). EMET 4.0 adds a layer of protection that friend, and EMET’s #1 fan, TJ O’Connor refers to as “creativity in defense”; I'll give him the closing comments:
"All too often the balance of creativity favors the attacker. Attackers overcome difficult exploit mitigation strategies by hurdling over them with creative attack strategies. Attackers have succeeded with creative techniques like heap-spraying, ROP Gadgets, SEH Overwrites, or ASLR partial over-writes. EMET 4.0 returns the balance of creativity to the defender. Instead of looking for fixed known signatures of attack, EMET 4.0 looks for the adversary trying to hurdle over the mitigation strategy. Because of this, EMET can identify a novel attack and stop it without previous knowledge of the attack. Its the most overlooked game changer in a defense strategy." 
Remember, test and tune before going full tilt boogie but know that EMET adds defense-in-depth for one host or an entire enterprise, even in the face of 0-days.
Ping me via email if you have questions (russ at holisticinfosec dot org).
Cheers…until next month.


Gerardo Di Giacomo, Security Program Manager, Microsoft Security Response Center (MSRC) Software Security Incident Response team

No comments: