In the light of the recent release of version 5.0 of Microsoft’s Enhanced Mitigation Experience Toolkit (EMET) on July 31, it seems to be more than appropriate to talk a bit about the new features and some general things to take into account when using EMET (for the new certificate pinning feature of EMET 4.0, see Friedwart’s comment). For all of you who don’t know EMET, in short, it’s a free mitigation tool for Windows developed by Microsoft, helping the user by preventing vulnerabilities in software from being successfully exploited. The tool works by protecting applications via a number of security mitigation technologies, vastly extending Windows operating system mitigation capabilities as Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR).
New features in version 5.0 of EMET are mainly Attack Surface Reduction (ASR) and Export Address Table Filtering Plus (EAF+). ASR most of all focuses on security related plug-ins like Java or Flash. With the right EMET configuration, Internet Explorer Java plugins can only be used in the intranet, and Word can be prohibited from automatically loading Flash content. EAF+ is not a new feature but one that is further extended in its capabilities. EMET restricts calls to Windows APIs by filtering access to the Export Address Table (EAT) and thus allowing or disallowing the read /write access based on the calling code. In EMET 5.0, this protection is extended to “kernelbase.dll” and it also includes black-listing capabilities for specific DLLs.
Recalling past incidents like the spear-phishing attack on RSA Security in March 2011, it becomes apparent, that software like EMET could have prevented a successful attack. In this case an Excel spreadsheet with an embedded Flash movie exploiting an Adobe Flash Player vulnerability was send to several employees, allowing the attackers to compromise several internal systems and steal sensitive data.
Having used EMET for quite some time myself, I would like to focus briefly on some obstacles you may encounter – not only in EMET 5.0 – and I will give some hints for resolving these problems.
Losing hours of work is never fun, but it is even worse if it happens without a warning. This scenario happened while using raw2vmdk, a tool written in Java to automatically create a VMDK file corresponding to a raw image file, so it becomes bootable in a virtual machine. As soon as the application was executed, an EMET message appeared warning about a potential exploit and its mitigation and the EMET Reporter popped up asking to send a report to Microsoft. Although being a false positive, not only did EMET closing the EMET Reporter window, it deleted the application itself, _and_ also the complete 250 GB hard drive image. This is not part of EMET’s functionality and seems to be a bug in the EMET Reporter. A quick Google search reveals, that other people report the same problem. This behavior was observed with EMET 4.0 running on Windows 8.1 64-bit, with EMET 5.0 the same scenario could not be recreated and this bug seems to be fixed. While apparently being a rare occurrence, the possibility for data loss should be kept in mind when using EMET. A quick and dirty workaround for this problem was to deactivate the Early Warning option in EMET. This disables only the reporting function while still mitigating potential exploits.
Another aspect to keep in mind, is the application compatibility of the various security features of EMET. During a Pentest we did, I came upon CheckPoint Media Encryption on a test system. A software used for the forced encryption of removable media in corporate environments. (By the way, we did a security research on CheckPoint’s Full Disk Encryption solution). Being not able to disable the application, it had to be used to transfer data from the system. While the encryption of a USB flash drive on the test system was completed without complication and data could be copied onto it, the problems started when I connected it to my own notebook. The “Unlock.exe” (of the Removable Media Encryption) had to be started to decrypt the data, but instead of the anticipated information I got the typical message along the lines of “Unlock.exe has stopped working. Do you want to report this to Microsoft?”.
Through comparison to other systems (on which the application worked) and some testing, the culprit could be identified. Setting the Data Execution Prevention in EMET to “Application Opt Out” prevents the CheckPoint software from starting, while with “Application Opt In” the application runs just fine. Thus a quite curious fact became apparent: Only setting DEP to “Opt In” allowed the full functionality of CheckPoint’s Media Encryption, it was not enough to disable EMET’s security features for this particular application or remove it completely from the list of protected software. Defining an exception in the Data Execution Prevention tab in System Properties of Windows also didn’t lead to success. As of now, it could not be verified why this application behaves this way.
Nevertheless, while doing some research on this topic, I found some things to keep in mind when dealing with DEP:
- EMET’s configuration, as well as Windows own system-wide configuration of DEP, are congruent in their functionality and they both change the “nx” parameter in the Boot Configuration Data (BCD). The value can be set to OptIn, OptOut, AlwaysOn or AlwaysOff. The status of the parameter can be checked with the command line tool “bcdedit”.
- DEP is always enabled for 64-bit applications. While it is possible to selectively disable DEP for individual 32-bit applications with an active “Opt Out” setting, this is not possible for 64-bit software (“Unlock.exe” is a 32-bit application).
Having said that, EMET is no universal remedy and, as you have seen, comes with its own side effects, but it is still a great addition to the overall security of every Windows-based system and – as we are noticing – enterprises are becoming aware of this fact.
For more information on Windows hardening, see our Newsletter Nr. 40.
Have a great day,
Heinrich Wiederkehr.