EMET v4 Release

Last week, the beta version of the EMET v4 toolkit was released. We already wrote about some new features of the 4th version and would like to dwell in more detail on the release itself, since this tool really deserves attention. Again, the Enhanced Mitigation Experience Toolkit (EMET) uses preventive methods to block various actions of exploits to protect applications from attacks that are aimed at exploiting flaws (or vulnerabilities) in software and changing the flow of code. Despite the fact that modern Windows 7 and Windows 8 have built-in, enabled by default, DEP and ASLR capabilities aimed at mitigating (mitigation) the consequences of exploitation, EMET allows you to introduce new features for blocking actions of exploits, as well as enable DEP or ASLR default, for example, for outdated Windows XP.

In our post, we want to provide an overview of the main features of the fourth version of EMET, which help protect against exploits.

Before considering the main features of this tool, let's clarify a few points:

• EMET is not a substitute for antivirus or HIPS, because it does not have the functionality of such tools: it does not contain a signature database or special behavioral threat patterns.
• EMET is not a substitute for sandbox (sandbox), because it is not designed for this and is not able to emulate the actions of the application.
• EMET is not a 100% system of protection against exploits, since, in fact, it is focused on tracking known methods of operation and will not be able to help against exploitation methods that are unknown to it.
• EMET is aimed at advanced users who are able to set the appropriate system settings and respond to incoming messages.
• EMET is free to use.

EMET main window.
')


From the point of view of protection against exploits, the tool has two types of settings: for the system as a whole, that is, the general rule for all applications in the system (System Status) and for specific applications (Configure Applications). Settings for the system include four main points:

• Data Execution Prevention (DEP) —determines which applications should use DEP.
• Structured Exception Handler Overwrite Protection (SEHOP) —determines which applications should use the protection against overwriting of SEH handlers. Modification of SEH handlers has been a long time in exploit mode. SEHOP was introduced at the system level already with Vista SP1.
• Address Space Layout Randmization (ASLR) —determines which applications should use ASLR.
• Certificate Trust (Pinning) - the function is available only for Internet Explorer and allows you to manually create rules for verifying digital certificates for SSL / TLS connections when visiting specific web resources.

Decoding settings DEP, ASLR, SEHOP, see here .
The tool supports built-in protection profiles for quick setup:

• Maximum Security Settings - the option enables all system settings to the maximum level.
• Recommended Security Settings - option enables system settings to "recommended level". Unlike Maximum Security Settings, it lowers the status of DEP and SEHOP to App Opt In, that is, including these settings (by default) only for key system processes.

You can check the status of processes with DEP, ASLR enabled, for example, using Process Explorer, by setting the display of the corresponding columns in the settings. View-> Select Columns-> DEP Status, ASLR Enabled.



EMET allows you to protect the application, including from the following very well-known methods used by exploits:

• ROP is a method well-known and widely used by exploits, which allows using special “code gadgets” on the stack to achieve the execution of the required code sequence, bypassing so. DEP.
• SEH overwrite - SEH blocks (the next, address of the handler) are located on the stack and can be overwritten, for example, as part of a buffer overflow; accordingly, attackers can use this vulnerability to transfer control to their code through an exception handler.
• Stack pivoting is a method used to move the register of the ESP stack to the desired address for the exploit.
• Heapspray - exploits use this method to allocate a large number of memory areas with the location of the exploit code, which increases the likelihood of transferring control to the code needed by the attacker.

EMET groups these methods, relating some of them to a specific group. Below is a screenshot of the settings for the processes, in which you can see how the mitigation methods are grouped and the methods used by the exploits.



This screenshot shows settings related directly to the memory.

• DEP is implemented by calling a kernel32! SetProcessDEPPolicy in the context of an EMET-controlled process.
• BottomUpASLR - in some way is an ASLR for allocated memory regions on the stack and on the heap (as memory is allocated and in the higher addresses).
• NullPage - see MS13-031 .
• MandatoryASLR - forcibly enables ASLR for dynamically loaded process libraries, i.e. making unpredictable download addresses. Implemented by intercepting the function ntdll! NtMapViewOfSection .
• HeapSpray - allows you to record attempts to heapspraying operations by reserving heap memory.

• LoadLib - tracking LoadLibrary operations to prevent the library from loading into memory along a UNC path, for example, \\ server1 \ share.dll
• MemProt - prohibition of changing the status of stack pages to executable.
• Caller - also refers to ROP and allows you to observe with which instruction the API was called, i.e. control that the function was called using call rather than ret, which is widely used in exploits.
• SimExecFlow - allows you to detect ROP-gadgets after calling the EMET-controlled function.
• StackPivot - allows you to detect stack pivoting situations.

• SEHOP - tracks attempts to exploit SEH handlers. In fact, this feature was introduced in the OS itself, starting with Vista SP1. EMET allows you to use this feature on systems below Vista SP1.
• EAF (Export Address Table Access Filtering) - prohibits any operations of accessing the memory page on which the module export table is located, depending on the code that is trying to access it. That is, it allows access to it only for code that belongs to a known loaded module. It is used by exploits (and not only) when manually parsing the export table of the module in order to obtain the address of the desired function.

To perform all these operations, EMET uses the well-known inline code patching method, which is graphically presented in the screenshot below (process controlled by EMET).



EMET has additional advanced features for applications that are available from the Application Configuration.

• Deep Hooks - to protect critical APIs, EMET will not only intercept these functions themselves, but also those functions (other APIs) that will be called from among them.
• Anti Detours - blocks the actions of exploits that skip the first bytes of the API (usually the prologue) and transfer control to the instructions following them.
• Banned Functions - prohibits calling API functions from a special list. In the 4th version, only the ntdll! LdrHotPatchRoutine function is present in this list.

Specify the action that EMET will perform when one of the operating conditions occurs. The options are: Stop on exploit (blocking the action with the display of a special message and the completion of the process) and Audit only (notification of the action).



What should EMET protect?



Please note that EMET has a list of processes for which it will be enabled by default. These processes include: MS Internet Explorer web browser, Adobe Acrobat, Java, MS Office. You can see the list of processes in the Apps window.
We highlight the following features regarding application security using EMET:

• Consider enabling EMET for Skype processes (or other messenger you use), as well as your browser. Since these components can be operated remotely.
• Note that EMET is not fully compatible with all applications , not to mention debuggers and other system tools. Therefore, if you are an administrator, do not turn on EMET for all the necessary processes on the network at once, better test compatibility with these applications separately.
• A list of possible incompatibilities and their discussion, see here .

List of incompatibilities of EMET mechanisms with various applications.

Microsoft EMET Guide [PDF] here .
EMET presentation on RECon'13 from one of the developers here .