Using the Enhanced Mitigation Experience Toolkit to Safeguard Against Zero Days

There have been a number of zero-day vulnerabilities circulating around the Internet recently. A zero-day vulnerability is a security issue in a product that is disclosed publicly before the vendor has created a security update for it. In a zero-day exploit, the program takes advantage of the product vulnerability in order to compromise a machine by running attacker-controlled code. Zero-day exploits are a significant concern because in many cases there are no workarounds with which to block the exploit, and, therefore, no way for users to protect themselves.

EMET provides new layers of security by implementing extra security mitigations. Briefly described, a security mitigation is a technology that makes the successful exploitation of a vulnerability more difficult and less reliable. Take a look at Michael Howard’s article
“Protecting Your Code with Visual C++ Defenses” for a brief overview of some of these technologies. EMET allows users to manage the security mitigations on their system and provides several advantages:

Highly configurable: With EMET, mitigations can be individually enabled and disabled on a per-process basis. There is no need to recompile a process or change system policies for all processes. Users can simply select which mitigations get applied to which processes. This also allows users to apply mitigations to software that was compiled before the mitigations were even available.

The latest mitigations: EMET comes bundled with many of the latest mitigation technologies, several of which are unique to EMET and not available elsewhere. These cutting edge technologies help provide users with the most up-to-date protection.

Ongoing improvement: The release cycle for EMET is not tied to any product. EMET updates can be made dynamically as soon as new mitigation technologies become available. The platform is designed so that the mitigations can be updated as attackers start trying to evade them.

Supports OS policies: The policy for OS-supported mitigations can be seen and configured with EMET's graphical user interface. There is no need to locate and decipher registry keys or run platform-dependent utilities. Your mitigations can be seen and configured from a central point.

Now, let’s dive into one of the unique EMET mitigations, Mandatory Address Space Layout Randomization (ASLR), to see how it works and how it helps prevent successful exploitation. Mandatory ASLR builds on the ASLR mitigation that has shipped with every version of the Windows operating system since Windows Vista. ASLR works by randomizing the addresses where executables and modules are loaded, which helps prevent an attacker from leveraging data at predictable locations. Because an attacker must guess where the data they need is located, a successful attack is less likely. There is a problem, though. Even when an application has opted in to ASLR, some of the dynamic-link library (DLL) files being used by the application can be placed at predictable locations. This happens when DLLs are not compiled with the /DYNAMICBASE linker option. However, when mandatory ASLR is enabled, EMET solves this problem by forcing the relocation of the DLLs.

To see how Mandatory ASLR can help block exploitation, let’s take a look at the
metasploit module for the Adobe SING stack overflow vulnerability. This exploit relies on several return-oriented programming (ROP) gadgets located on a non-ASLR-aware module, icucnv36.dll. ROP gadgets are pieces of code used by attackers to bypass Data Execution Prevention (DEP). Attackers commonly use gadgets from predictable mappings, thus circumventing ASLR.

The first ROP gadget used places the stack at a controlled place. This can be done because the attacker can reuse these lines of assembly from the non-ASLR module. Here is what the ROP gadget looks like:

When EMET is in place and Mandatory ASLR is enabled, this DLL will be relocated to a random place. The exploit will try to jump to 0x4a80cb38 but, since the DLL was relocated, an attempt to change the ESP stack register to a controlled place will fail. Here, you can see the ROP gadget is not present:

This mitigation has proved to be quite effective, and even the author of the metasploit module for this vulnerability
suggests installing EMET so it will be harder to successfully exploit the vulnerability.

Mandatory ASLR it just one of the six mitigations bundled with
EMET version 2.0. To read more about EMET, including a link to the User’s Guide, please refer to this
blog post. As a final note, we would like to point out that while EMET will minimize the risks of exploitation, it is by no means 100-percent effective and should not be considered an alternative for security updates and patching. Instead, EMET should be used in conjunction with other efforts to safeguard your environment.

About the Authors

Fermin J. Serna s a Security Software Engineer in the MSRC Engineering team. Prior to joining Microsoft, he spent 7 years in Spain working as a Penetration tester and lately running his own company in the security field. He has collaborated with US-CERT in the responsible disclosure of several vulnerabilities, such as CA-2002-12 for ISC-DHCP, and published documents on exploitation techniques on rare architectures such as SPARC and PA-RISC.

Andrew Roths manages one of two MSRC Engineering teams. His team is responsible for triaging externally discovered security issues and helping to ensure they are addressed appropriately. Other responsibilities of his team include hunting for variations of security issues and providing technical guidance to customers. Prior to being a manager, Andrew was part of Microsoft's Security Engineering Center (MSEC).