EMET 4.0's Certificate Trust Feature

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.

• From a clean computer using a trusted internet connection download and inspect the SSL/TLS certificate for the domain that has to be protected with EMET (e.g. https://twitter.com) and find the correct subject name that will be used in the “Protected Websites” tab (e.g. “twitter.com”)

• Lookup the RootCA for “twitter.com” in the “Certification Path” and make note of some significant details related to this RootCA certificate (name, thumbprint, validity, serial number, etc.). For example the current RootCA of “twitter.com” has a VeriSign certificate with the following details:
  • • CN = VeriSign Class 3 Public Primary Certification Authority - G5
  • Thumbprint = 4e b6 d5 78 49 9b 1c cf 5f 58 1e ad 56 be 3d 9b 67 44 a5 e5
  • Validity = From: November ‎7, ‎2006; To: ‎July ‎16, ‎2036

• Open EMET_GUI and click on “Configure”->”Certificate Trust”. In the “Pinning Rules” tab add a new rule (e.g. TwitterCAs) which will be used to import the specific VeriSign RootCA acquired earlier for twitter.com (double check you’re importing the correct VeriSign CA). This pinning rule will be used to create a “one-to-one” pinning, but anytime it is possible to add more RootCA certificates into this rule to create “one-to-many” pinning.

• Go to the “Protected Websites” tab and add a pin that links “twitter.com” to the just created rule “TwitterCAs”.

• Click “OK” to save the settings and restart the browser if needed.

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:

<EMET Version="4.0.4854.22469">
  <Pinning>
    <PinRules>
      <PinRule>
        <ID>{67626c91-5591-4acd-a87f-864593250fff}</ID>
        <Name>TwitterCAs</Name>
        <ReferencedCertificates>
          <UniqueCertificateIdentifier>
            <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>
            <SerialNumber>18DAD19E267DE8BB4A2158CDCC6B3B4A</SerialNumber>
          </UniqueCertificateIdentifier>
        </ReferencedCertificates>
        <Expiration>5/10/2014 4:00:00 PM</Expiration>
      </PinRule>
    </PinRules>
    <PinnedSites>
      <PinnedSite>
        <Domain>twitter.com</Domain>
        <PinRuleMember>{67626c91-5591-4acd-a87f-864593250fff}</PinRuleMember>
        <Active>True</Active>
      </PinnedSite>
    </PinnedSites>
  </Pinning>
</EMET>

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:

• Some websites may use different portal as entry-point for authentication; it’s always good to carefully check the correct domain name to add into the “Protected Websites” tab (e.g. “outlook.com” service is accessed via the “login.live.com” authentication service);
• Each pinning rule has an expiration date that delimits for how long a rule is effective; after the specified date, the rule will no longer be used to check certificates; expiration date can be usually aligned with the expiration date of the certificate included in a pinning configuration;
• Domains cannot be added in the “Protected Websites” tab by using wildcard characters (e.g. *.live.com is not allowed); also, the domain name added into this tab is not the domain name in the URL bar of the browser, but it’s one subject name of the SSL certificate;
• To avoid false positives and to configure less restrictive rules, it is possible to add exceptions on each pinning rule based on three properties of the RootCA certificate: key size, country, and signature hashing algorithm; when a RootCA is not present in the defined trusted set for a specific domain, EMET may allow an exception of the pinning rule if explicitly configured (for example: allows an exception if the RootCA certificate does not use MD5, has a minimum key size of 4096 bits, and is located in USA);
• When EMET detects a suspicious certificate it will be reported with a visible message from EMET Agent, while the important details of the certificates are logged into the Window Events Log; a warning message is a good pointer to examine carefully what’s happening for a SSL/TLS certificate but doesn’t necessary mean that the detected certificate is malicious, few times changes of RootCAs happen also for legitimate reasons;
• The quickest way to test that the Certificate Trust feature is working is to configure a wrong pinning rule that will fail for a test domain; for example, if for twitter.com we configure a different RootCA than the specific VeriSign CA identified earlier, EMET will display the following warning message when browsing with Internet Explorer on “twitter.com”:

Conclusion

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 emet_feedback@microsoft.com. And if you haven’t yet tested EMET 4.0 beta, download it here and try it out!

- Elia Florio, MSRC Engineering