Select a language to translate this page!
Powered by Microsoft® Translator
No matter where you are today, software is there. Whether it’s your phone, your car, your work or even in the grocery store. One thing that is common to all these software’s is vulnerabilities. Vendor market share, the motivation of the attackers and the profile of a victim all play into who ultimately gets attacked and who doesn’t. However, there is a free tool that can help. EMET is a utility designed to help IT Professionals protect systems from common threats, and works by applying security mitigation technologies to arbitrary applications to block against exploitation.
This tool is especially important for Line of Business Apps or PII data stores, where losing that data could results in significant financial implications. It’s also important for zero day attacks as these attacks exploit vulnerabilities for which there is no fix available. Microsoft has been building mitigation technology into the OS and compiler tools for over a decade. The EMET tool provides users with the ability to more easily take advantage of these mitigations in addition to EMET-specific mitigations that are not currently supported by Windows.
EMET relies on the concept of a security mitigation technology and is able to apply these technologies to an arbitrary process. It doesn’t matter which company wrote the software, the language it was written in, when it was written etc. You might have a LOB app from 1992 where the developer has retired or maybe the company that wrote it is no longer in business. This doesn’t matter; EMET can help. In 2010, if you deployed EMET, you could have blocked 90% of the memory corruption exploits that were found in common productivity applications without ever applying the fixes (although we still of course encourage everyone to apply their updates). By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products. In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.
EMET 1.02 was first release in Oct 2009. The more recent EMET 2.0 can be downloaded here and boasts the following capabilities:
Microsoft offers a number of different mitigation technologies that are designed to make it more difficult for an attacker to exploit vulnerabilities in a given piece of software. Until EMET was released, many of the available mitigations have required for an application to be manually opted in and recompiled. EMET changes this by allowing a user to opt in applications via a simple command-line utility without recompilation. This is especially handy for deploying mitigations on software that was written before the mitigations were available and when source code is not available. EMET also provides a higher degree of granularity by allowing mitigations to be applied on a per process basis. There is no need to enable an entire product or suite of applications. This is helpful in situations where a process is not compatible with a particular mitigation technology. When that happens, a user can simply turn EMET off for that process. Furthermore, several of the Mitigations that have previously been limited to up-level versions of Microsoft Windows now ship with EMET and are available down-level. Users can benefit from these mitigations while they are in the process of upgrading their systems. Keep in mind, EMET is a living tool designed to be updated as new mitigation technologies become available. This provides a chance for users to try out and benefit from cutting edge mitigation technologies. It also gives users the opportunity to provide feedback on their experiences and help guide the future of mitigation technologies in Microsoft products.
The Mitigations EMET offers are:
Structured Exception Handler Overwrite Protection: This mitigation performs Structured Exception Handler (SEH) chain validation and breaks SEH overwrite exploitation techniques. Take a look at the following SRD blog post for more information on what these exploits are and how they are blocked. View post here.
Dynamic DEP Data Execution Prevention (DEP): This is a memory protection mitigation that marks portions of a process’ memory non-executable. This makes it more difficult to an attacker to exploit memory corruption vulnerabilities. For more information on what DEP is and how it works, take a look at the two part SRD blog here and here.
NULL page allocation: This blocks attackers from being able to take advantage of NULL dereferences in user mode. It functions by allocating the first page of memory before the program starts.
Heap spray allocation: Heap spraying is an attack technique that involves filling a process’ heap with specially crafted content to aid in exploitation. Right now, many attackers rely on their content being placed at a common set of memory addresses. This mitigation is designed to pre-allocate those memory addresses and thus block these common attacks. Please note that it only aims to break current exploit that take advantage of these common addresses. It is not a general mitigation for the larger heap spraying attack. That said, if attackers do change the addresses they use, EMET users can change the addresses that are blocked.
Export Address Table (EAT) Access Filtering: In order to do something useful an exploit generally needs to call functions exposed by Windows. However, in order to call one of these functions, the exploit must first find where it is loaded. This mitigation blocks the most common approach used by exploits to look up the location of a function which involves scanning the export address table of loaded libraries. It is highly effective at blocking exploits currently being used.
Mandatory Address Space Layout Randomization: ASLR randomizes the addresses where modules are loaded to help prevent an attacker from leveraging data at predictable locations. The problem with this is that all modules have to use a compile time flag to opt into this. Mandatory ASLR forces all modules to be loaded at randomized addresses regardless of what flags they were compiled with. Exploits relying on data at fixed addresses will fail.
An online video giving a more thorough overview of the mitigations can be seen here.
For more helpful information, please visit or feel free to stop by our blog here.