Last week, we decided to take a look onto the EMET library provided by Microsoft. This library is intended to introduce several security features to applications which are not explicitly compiled to use them.
It also adds an additional layer to protect against typical exploiting techniques by filtering library calls, preventing usage of dangerous functions/components and inserting mitigation technologies.
As EMET is already a target for many researchers, we currently only started to get an overview of it’s structure and how the different components are interacting with each other. Today we would like to share some of our results with you.
Table of Contents
After installing EMET 5.51 (SHA1 (EMET Setup.msi) = 98f0cb46df42bdd5ff8b92f87cad728e9373fe97), we were presented with the following new files:
- Program Files
- EMET 5.5
- Group Policy Files
- Protection Profiles
- Popular Software.xml
- Recommended Software.xml
- Privacy Statement.rtf
- EMET 5.5
To get such a list of installed files you’ll have multiple options:
- Extract the Setup package
- Guess the installation dirs
- Use snapshot tools
Each of them has it’s pros and cons. Option 1 would give you all files which are contained in the setup,
even if they are not going to be installed, but may miss files which are generated dynamically. Option 2
may be the easiest, but also the most error prone one, as you’ll never know if files are stored at different places.
Option 3 gives you an overview of all files which are generated between two states of the filesystem, this is the most accurate one,
but also produces the most data.
As we liked to go with option 3 to miss no files, we created snapshots with “InstallWatch Pro” (there was no special reason for this tool,
it was just the first one which seemed to fit our needs) and diffed them to get all created/changed/deleted files and registry entries.
The most relevant files are located in the C:\Program Files\EMET 5.5 and C:\Windows\AppPatch folders. While the first one primarily stores the applications for interacting with EMET, the second one contains the actual EMET libraries (in a 64bit system you’ll also find a EMET64.dll in there). This folder is used by the operating system to store so called SHIM libraries. Such libraries are injected by the application loader between the application and the operating system APIs. This is done by setting the entries of the import table to the shim library instead of the actual library provided by the operating system. As this is immediately done when the application loads, such shim libraries are able to get access to the majority of the function calls occurring during the application startup (including loading of required libraries etc.). As such, shim libraries typically act as proxies or filters, they are completely transparent to the application and the operating system. Each of those components thinks that they are interacting directly with each other whilst they are actually talking to a library between them.
EMET consists of multiple interfaces to configure the protected applications. The first (probably most used) one is the GUI tool EMET_GUI.exe. This application is written in .Net and uses no obfuscation techniques, therefore it is fairly easy to look at. It’s responsible for showing the administrator (requires an UAC privileged elevation) the current protected applications and also allows him to add new, delete old and configure the protection mechanisms for existing ones. The second application is the EMET_Conf.exe. It’s also written in .Net and provides a command line interface to the EMET configuration. The last option to configure EMET is by using group policies, which are stored in the Deployment subfolder.
Some applications are configured by default to be protected by EMET when it is installed for the first time on the OS. These applications can be seen in the configuration panel of EMET GUI and as an example of such applications/processes: Microsoft Internet Explorer, Java and Adobe.
However, when a user would like to configure an additional application to be protected by EMET, the user will usually interact with EMET from the GUI. The steps as depicted in the below diagram starts with choosing the application to be protected, then the EMET will update the Shim DB “.sdb” file that will be used by the OS to decide whether to inject the EMET.dll into the process of the application or not, and in parallel the EMET application also creates the relevant registry keys to be used by the EMET when the process of the application is started.
After the above steps are done and the configuration is saved, the protected process of the configured application will be injected with EMET.dll by the Windows OS after checking the Shim DB. Additionally, after the process is started, EMET.dll will take over the reset by checking which EMET protections do the application have by consulting the relevant registry keys, and hence apply the required checks accordingly.
The first really interesting application is the EMET_Service.exe. This application is a windows service which runs as local system and exposes a named pipe to all users under the path \\pipe\EMET_Service.
This service is responsible for generating log events in behalf of the EMET library and verify if a certificate chain contains a pinned certificate and, if so, checks them for validity.
The communication to this service is done through XML messages, which are sent by the EMET library to the service and then parsed by the service to execute the responsibly handlers.
As XML parsing is notoriously error prone, we checked the used parser and the set configuration. It turned out that the developers of this service seemed to be aware of the problems arising with using XML as they have used the System.Xml.XmlReader class provided by .Net with settings which disable the processing instructions of engine and they also disabled the support of doctypes (this one is actually done implicit as this is the default on .Net). Those settings prevent most of the general XML attacks as they are based on doctype parsing or processing instructions. The only remaining ones would be special vulnerabilities solely to this XML implementation (which we are not aware of) or Denial-of-Service scenarios by sending a large amount of XML data (as only an authenticated user itself is able to talk to the named service, this is also very unlikely).
For documentation purposes you’ll find the three different types of messages in the following listings.
The first one is a message triggered by the EMET_CE.dll and is used to validate a certificate chain against the stored certificate pinning list of EMET. It contains a list of certificates (Request/Certificate/Chain), encoded as hex, and some information about the application which is requesting the validation:
It has to be mentioned that if the validation fails (which only happens if a part of the chain is inside the pinned list and this part is invalid, either in general (e.g. expired) or if it’s fingerprint does not match the entry in the list), the EMET_CE.dll is not able (or at least doesn’t tries) to prevent the connection to the server sending those chain. Instead a log event is created and a notification is shown to the user by the agent application.
The next message is used to generate a general log event in the EMET namespace. The sender of this message is able to choose the critically level of the message and also it’s content by setting the appropriate values in the Event element.
The last one is responsible to generate an explicit event for exploit detections. It contains information about the name of the process in which the detection was triggered, the message to be included in the event log, the files responsible for the trigger and some url which is also included in the log message.
While most of the data is simply included in the log message, the App element and the Files/File elements have some additional impact. The paths contained in the file array were read by the service (with local system rights) to calculate MD5 checksums based on their content. The App content is later used by the agent (user rights) to create a Windows Error Report if the user confirms that it is allowed to do so.
This means that while you are able as an unprivileged user to generate MD5 sums of protected files, you still can’t access their content as the latter collection is done by the agent with lower privileges.
As we mentioned before, there is also an application called EMET_Agent.exe which is running in the context of the current desktop user. This agent is responsible for generating error reports and showing notifications to the user. This is done by opening a named pipe in the format \\pipe\EMET_Agent_<session nr>, where <session nr> is the id of the current windows desktop session. If the previously mentioned service got a message to log an exploit event, it will connect to this pipe and tells the agent to show a notification to the user and ask him to generate a error report for telemetry purposes.
The notification command is also used in case of a failing certificate pinning verification.
The main implementation of the protection mechanisms are done in two (or four in case of 64bit) libraries:
The EMET.dll contains the main protections against memory corruptions and filters for possibly harmful library calls. This is also the library which is injected into the process via the shim framework.
The EMET_CE.dll is responsible for the certificate pinning. It’s primarily used in the internet explorer to check the certificate chains. As it’s using the Microsoft certificate stores and libraries, it doesn’t check certificates applications which have their own libraries like Mozilla Firefox.
EMET was first introduced late 2009 with few mitigation techniques, which provided the application with a protection against overwriting the Structured Exception Handling (SEH), executing code on regions like stack and heap by using Data Execution Prevention (DEP), and finally prohibiting the Heap Spray attacks by disallowing writing to well-known address ranges. Currently, the latest version of EMET is 5.5.1, which already has many new features improvements over the previous versions.
Despite the fact that EMET was mainly developed to minimize and prevent the possible attack surfaces for an application, it has been practically proven over the years that a skilled attacker could bypass the different protection techniques, which are employed by EMET.
In this section we briefly mention some of the recent techniques that were used to bypass EMET. As described by the author of [BYPASS-EMET-ROP], EMET 3.5 was successfully bypassed, because the KernelBase.dll and its functions were mistakenly left unprotected, so the attacker in this case can find the “dll” base address, through which he can use VirtualProtect function to defeat DEP.
As explained by the guys at Offensive Security in [DISARM-EMET], [DISARM-EMET5.0] and [DISARM-EMET5.1], EMET 4.1 update one, EMET 5.0 and EMET 5.1 were successfully disarmed by targeting a global variable that controlled the Return Oriented Programming (ROP) protection in these versions. The used technique for this bypass mechanism is slightly different among the three affected versions. In version 4.1 the bypass was performed by locating the global variable at a fixed location that points to a switch in “.data” section of the EMET.dll and then overwrites it with zero. In version 5.0 and 5.1 the global variable was not pointing directly to the switch but rather to an encoded pointer to a structure called CONFIG_STRUCT, from which the global switch was retrieved at a fixed index.
Early this year in Black hat USA 2016, FireEye researchers unveiled the vulnerability that they discovered in EMET 126.96.36.199, which was used to completely disable the hooks deployed by EMET.dll. As explained in their research paper in [DISABLE_EMET16], the main cause of this vulnerability was because the Microsoft EMET team overlooked the presence of the functionality of unloading the EMET.dll using DLLMain Windows API.
About a month ago the Director of Research at Blue Frost Security GmbH introduced in HITB Singapore a bypass of the Attack Surface Reduction (ASR) feature in EMET 5.5 as a part of his talk “Look Mom, I don’t use Shellcode” [LOOK-MOM]. In this bypass the author used similar technique that was used by Offensive Security, but instead of finding the switch that disables the ROP protection, the aim was to find the switch that is used to check if the ASR feature is enabled or not. It is worth mentioning that the researcher mentioned that Microsoft currently does not have plans to address the bypass, which was used in his attack.
We hope you enjoyed reading our post.
Ali Hardudi & Timo Schmid