Today, we are excited to announce the general availability of the Enhanced Mitigation Experience Toolkit (EMET) 5.0. As many of you already know, EMET is a free tool, designed to help customers with their defense in depth strategies against cyberattacks, by helping detect and block exploitation techniques that are commonly used to exploit memory corruption vulnerabilities. EMET 5.0 further helps to protect with two new mitigations and several other improvements. You can download EMET 5.0 from the Microsoft Download Center.
Let’s start with the two new mitigations, which we initially introduced in EMET 5.0 Technical Preview: the Attack Surface Reduction (ASR), and the Export Address Table Filtering Plus (EAF+). We already described details about these two new mitigations in the Technical Preview announcement blog post, but let’s talk briefly about the improvements made during the preview period.
The ASR is a mechanism to block the usage of a specific modules or plug-ins within an application. For example, you can configure EMET 5.0 to prevent Microsoft Word from loading the Adobe Flash Player plug-in, or, with the support of security zones, you can use EMET 5.0 to prevent Internet Explorer from loading the Java plug-in on an Internet Zone website while continuing to allow Java on Intranet Zone websites.
During the preview period we have performed several tests and collected your feedback to finalize the default configuration for this mitigation. We aimed at having a configuration that provided security, and at the same time, did not limit the user experience with the applications protected by EMET 5.0. By default, EMET 5.0 is configured to block some modules and plug-ins from being loaded by Internet Explorer while navigating to websites belonging to the Internet Zone, and to also block the Adobe Flash plug-in from being loaded by Microsoft Word, Excel, and PowerPoint. We have chosen modules that are commonly used in certain exploitation scenarios, but like all EMET features and mitigations, the ASR is completely configurable to satisfy everybody’s needs and to be tailored to specific systems’ requirements.
Internet Explorer ASR default configuration
The EAF+ starts by the same concept as the existing Export Address Table Filtering (EAF) mitigation, but it amplifies its scope and robustness. During the Technical Preview, we have presented the EAF+ as an extension to the EAF. During the last couple of months we have made several improvements to it, and we decided that it should be a new mitigation on its own.
As already mentioned in the Technical Preview blog post, when EAF+ is enabled it adds the following additional safeguards:
These improvements help detect and disrupt some current techniques used to dynamically discover ROP (Return Oriented Programming) gadgets and reliably execute code when a vulnerability is exploited.
EMET 5.0 introduces many other improvements. Let’s go through them and see what customer benefits they add.
Many ROP mitigations are now available also for 64-bit processes: Deep Hooks, Stack Pivot, Load Library, and MemProt. Although we have not yet detected exploits that use ROP techniques to exploit 64-bit applications, we decided to extend the anti-ROP mitigations to this architecture to be ready when the time comes.
The Certificate Trust’s pinning rules can now be configured with a more aggressive “blocking” mode (not enabled by default), so that EMET 5.0 can force Internet Explorer to terminate the SSL connection without sending session data instead of just detecting the untrusted certificate.
Certificate Trust Blocking Rule option
We have added a new service, called EMET Service, which is taking in charge many duties that EMET Agent used to do in previous versions. The EMET Service, among other things, takes care of evaluating the Certificate Trust rules, appropriately dispatching EMET Agents in every user’s instance, and automatically applying Group Policy settings pushed through the network. Also, a service offers more resiliency and better ability to being monitored.
We have seen a technique to potentially bypass some of the EMET 4 mitigations. This technique is possible when a memory corruption within an EMET-protected application can be abused to overwrite selected memory areas and corrupt data belonging to EMET itself. We have also seen techniques aiming at disabling the EAF mitigation by invoking some specific API calls. In EMET 5.0 we worked to harden against potential bypass techniques.
We also refactored many components of the EMET 5.0 engine, in order to maximize application compatibility, also with some popular anti-malware products, and reduce potential false-positives.
We have done a lot of work to bring EMET 5.0 to life, and we want to thank all those who provided feedback during the Technical Preview time frame, either through email@example.com or through the EMET Connect Portal (which we’ll continue to use). Your feedback helped to create a great version of EMET. Now, we are giving you back the product that you helped us build. We invite you then to download EMET 5.0, install it, and let us know what you think.
The EMET Team:
Adam Zabrocki, Andy Renk, Chengyun Chu, Cristian Craioveanu, Elia Florio, Elias Bachaalany, Gerardo Di Giacomo, Neil Sikka