Protect Your Applications Using EMET

Is there a way to make your Windows environment certainly not bullet-proof but stronger enough against attacks? A few weeks ago, Microsoft released an interesting add-on called EMET for its Windows operating systems range. EMET stands for “Enhanced Mitigation Experience Toolkit” and is designed to increase the security of your Windows executables. How?

Microsoft Windows is a very common operating system and became a regular target for the bad guys for years now (more systems are targeted, more chances you have to compromise them). Still today, it remains the preferred target of most worms, viruses and trojans. A common attack vector is to abuse the stack with a “stack overflow” (There are plenty of examples based on this weakness). Wikipedia defines a stack overflow like this:

In software, a stack overflow occurs when too much memory is used on the call stack. The call stack contains a limited amount of memory, often determined at the start of the program. The size of the call stack depends on many factors, including the programming language, machine architecture, multi-threading, and amount of available memory. When too much memory is used on the call stack the stack is said to overflow, typically resulting in a program crash.
Source: wikipedia.org.

Indeed, the result of a stack overflow in an application is a crash which can be defined as a DoS (“Deny of Service”) attack. But, in worst cases, this can be exploited to execute some attacker’s code. The goal of EMET is to protect the running processes against this type of attack by implementing six mitigations:

SEHOP – “Structure Exception Handler Overwrite Protection”
Implemented since Windows XP SP1 and able to be turned on or off in Windows 7, this feature protects the process against the most common technique to exploit stack overflows. It prevents an attacker to change the execution stack.

DEP – “Dynamic Data Execution Prevention”
Also available since Windows XP, DEP prevents code in memory from being executed if not flagged as executable. DEP was available for applications compiled with a specific flag. EMET allows to activate DEP even without this compilation option.

Heapspray Allocations
Attackers use this technique to place several copies of their malicious code in memory. This way, they increase the chances of a successful exploitation.EMET pre-allocates commonly used pages to prevent exploits to use them.

Null page allocation
Like heapspray allocations above, this technique is designed to prevent potential null dereference issues in user mode.

ASLR – “Address Space Layout Randomization”
Attackers are good to predict the locations of functions and data in memory. By using ASLR, allocations are randomized. Like DEP, this is normally enabled at compilation time.

EAF – “Export Address Table Access Filtering”
Exploits need to call APIs and need to find them in memory. This technique makes it more difficult to find them and will block the malicious code.

Note that all the mitigation techniques are not available on all supported operating systems! Also, changing the behavior of some processes may affect the stability. Before implementing EMET in a production environment, test it in a lab!

The installation is a straight away process. Once done, run the GUI and configure your default setting using the “Configure System” button:

Click to enlarge

Note that changing the default settings, requires a system reboot. Then, you can configure your applications one by one with more granularity:

Click to enlarge

To be clear, EMET does not bring new techniques to protect against malicious code. Example: DEP has been made available since the Windows XP ServicePack 2. But, executables have to be compiled with a specific flag to enable it. Today, EMET allows you to enable it for any applications even if not compiled for the right flags. No need to recompile a bunch of source files.

Is EMET the definitive solution to prevent execution of malicious code? Certainly not! But it’s a step forward to increase the system security. It does not prevent you to keep your environment protected with a up-to-date antivirus solution. Execution of suspicious applications in a sandbox is also certainly a good idea. But EMET is easy to implement and can protect even your legacy application.

I’ve used EMET to enable security for Microsoft Office, Firefox and it’s extensions, Adobe Acrobat Reader and some others like the lsass service. But i also wonder how simple it would be to have it turned off again. As EMET runs from the commandline i fear this one day will be the case.