Three weeks ago, we released a beta version of EMET 4.0 to get feedback on the new EMET features and to get more real-world testing before the official release. We have been amazed and so grateful for the thousands of downloads and hundreds of emails with feature suggestions, bug reports, questions about the new features, and kind words cheering us on. Thank you (!!) to those of you who are helping us make EMET 4.0 a great release. Seeing how much the community of defenders cares about this product drives and motivates us to make it awesome! With this blog post, we want to give you an update on the EMET schedule and walk through the steps to leverage EMET 4.0’s new Certificate Trust feature.
Official release delayed two weeks to May 28, 2013
We have acted on and addressed a number of bug reports and points of feedback already. One of the most important was a vulnerability first reported by TK of NSFocus where having EMET loaded made exploitation of system vulnerabilities easier – that is fixed. We also received the “Agent not running” bug report several times and that is addressed for the final release of EMET 4.0. We are fixing several application compatibility issues reported that we otherwise would be unlikely to have discovered on our own pre-release. Your feedback is making EMET 4.0 a better product – thank you!
We want to make product changes to address more of the feedback before we release EMET 4.0 to the world. So we decided to postpone the release of final version of EMET 4.0 by two weeks, to May 28th, 2013. We are sorry if this decision may interfere with your future plans of deploying EMET, but we prefer to take some extra time to work on all the feedback received and to release a product as reliable and safe as possible.
EMET and certificate pinning
As you may know EMET 4.0 implements a new protection feature known also as “certificate pinning” which in its simplest form could be described as a method of associating an X509 certificate (and its public key) to a specific Certification Authority (root or leaf).
Certificate pinning and certificate cross-validation became two very popular topic in recent years because of the major incidents and fault happened in the PKI space; in fact the current PKI and Certification Authorities model has demonstrated some limits and shown critical issues when scaled to a globalized and fully interconnected world where it’s not entirely safe to assume that every CA in the world is immune from breach, errors or poor practices as clearly showed by the table below which summarizes the most significant PKI issues seen so far. On the other hand the reason why users should care about certificate pinning is the fact that the numbers of CA across the world and located in multiple countries has grown significantly in recent years and the entire PKI model works with the assumption that all these CA will always operate with the same level of trust and confidence.
For this reason EMET 4.0 decided to take a little step far from the traditional exploit mitigation area and introduces a new feature called Certificate Trust to allow anyone to create pinning rules for any SSL/TLS website certificate, giving the ability to detect Man-In-The-Middle attacks leveraging untrusted certificates. EMET 4.0 comes with Certificate Trust enabled by default, including a set of pre-configured websites for the most common domains used by Microsoft online services; nevertheless, since we believe that certificate pinning is a useful tool to detect MITM attacks targeting any domain and not just Microsoft services, we designed Certificate Trust totally configurable, in order to allow any user to configure custom pinning rules that will be enforced when browsing the web with Internet Explorer.
Since we received a lot of feedback about this new feature and a lot of users sent inquiries on how to properly use it, we are publishing this blog to explain how to configure and test Certificate Trust.
Introducing the Certificate Trust feature
EMET 4.0 has a main switch button in the system mitigation panel that can be used to activate or de-activate Certificate Trust. Once enabled, users have to specify which certificates and Root Certificate Authorities to trust. Users can verify that the Certificate Trust feature is activated from the EMET GUI by checking that the system status of this mitigation is “Enabled” and that Internet Explorer process (iexplore.exe) is in the list of configured apps (with or without memory mitigations enabled). This configuration allows EMET to inject into the protected process a new small module (EMET_CE.DLL) that will operate only within Internet Explorer to enforce the certificate pinning protection.
EMET pinning model is based on two simple types of metadata: Pinning Rules and Protected Websites. Users can define custom “pin” relationships between subject name(s) seen in SSL certificates and a set of trusted Root Certification Authorities. EMET supports the creation of “one-to-one” pinning rules (one domain pinned to one specific RootCA) or “one-to-many” (one domain pinned to a set of specific RootCAs), and gives the ability to define minor exceptions for each rule.
For example, let’s consider the domain “login.live.com”, which is configured and protected by default by EMET 4.0 Beta. EMET has a specific pin rule for the subject name of “login.live.com” which is linked to two RootCAs. One of these RootCAs is VeriSign RootCA, which is visible when manually inspecting the certificate for that domain. Any certificate seen by Internet Explorer for “login.live.com” and originated from a RootCA different than the two configured in EMET will be detected and reported as suspicious.
Configuring Certificate Trust: an example
In order to understand the exact steps required to create a custom pinning rule, we are providing a step-by-step configuration guide for Twitter. This guide can be used as reference to configure any other online service (e.g. webmail, social networks, file sharing, online banking, etc.) or any corporate portal that uses SSL/TLS connections (e.g. webmail.mycompany.com, fileshare.mycompany.com, etc.), and take advantage of EMET’s Certificate Trust feature.
The Certificate Trust configuration can be exported as XML file and later imported on a different machine or distributed to a corporate environment to be imported using the EMET_conf command line utility. For the Twitter example used in this blog, the exported XML configuration file is shown below:
<Issuer>CN=VeriSign Class 3 Public Primary Certification Authority - G5, OU="(c) 2006 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US</Issuer>
<Expiration>5/10/2014 4:00:00 PM</Expiration>
Notes about Certificate Trust configuration
After evaluating the initial feedback received and some questions from users regarding the Certificate Trust feature, we think it’s also important to share some additional notes and guidelines for users dealing for the first time with certificates and pinning rules:
We hope you are as excited about using the final release of EMET 4.0 as we are about releasing it. If you have any questions about EMET 4.0, specifically about the Certificate Trust feature detailed in this blog post, please email us at firstname.lastname@example.org. And if you haven’t yet tested EMET 4.0 beta, download it here and try it out!
- Elia Florio, MSRC Engineering