Following up on the comparison of EMET and Chrome implementations of certificate pinning, this post looks at applying the Chrome rules into EMET.
MSFT has recently published an update on the certificate trust functionality in EMET. The TechNet piece describes how additional settings can be imported. It also includes an example configuration file for Twitter. (Note that the example appears to have been created from scratch based on the existing Twitter certificate chain. There is an actual Twitter pin rule in Chrome but it is much more complex than the sample rule.) By default EMET only contains pins for three MSFT websites: login.live.com, login.microsoftonline.com and skype.live.com. That does not include any of the pins defined in Chrome. Luckily the import capability allows defining new rules, and in particular carrying over the constraints that have been shipping with Chrome for some time. But first they need to be translated into the appropriate XML format accepted by EMET.
One word of caution: the semantics for pinning rules are similar but not identical between IE and Chrome, as described at length in the earlier post. Exact translations are not always possible. For example Chrome allows whitelisting based on subordinate CAs (intermediary CAs appearing between the leaf and root) while EMET rules are based on the root only, as confirmed by experiment. Similarly EMET allows defining exceptions based on country and key-size, provisions that Chrome lacks.
When such details are lost in translation, the effect can be a more or less strict policy than original intent. For example inability to declare trust in an intermediary means that the corresponding EMET rule will flag a certificate chain as forgery, when it was permissible according to the original. Going in the opposite direction, Chrome also permits explicitly blacklisting a CA; its existence anywhere in the certificate chain invalidates the chain. Because EMET can not express that, it may green-light a certificate chain that would have been rejected by Chrome. These are not hypothetical situations: Google pins in Chrome reference both intermediate CAs and explicitly blacklist certain issuers.
Behind the scenes, EMET options are stored in the Windows registry, under HKLM\Software\Microsoft\EMET. The certificate trust settings in particular reside in two subkeys under _settings_\Pinning. After a default install, there are only three pinned sites and one rule as expected. All three of these sites use the same pin rule identified by a GUID, white-listing 2 certificate authorities. Looking at the details of that rule, we can see that whitelist itself is stored as a multiline registry value, with the distinguished name and serial number for each CA listed in separate lines. In principle then we pinning rules can be configured by directly manipulating the registry. Of course there is nothing developers hate more than end users doing this type of under-the-covers manipulations of application state.
Fortunately there is an “officially sanctioned” import method, avoiding any direct mucking with implementation internals. Located in the EMET installation directory is a command line utility named emet_conf for administering different mitigations available. This can be viewed as the counterpart to emet_gui which provides a more user-friendly graphical interface for doing many of the same tasks. Once the rules from Chrome converted into suitable XML format defined by EMET, they can be imported into EMET to also protect Internet Explorer users.
To that end, here is an approximate translation for one subset of sites: [zipped XML file].
- This configuration is provided as-is; use at your own risk.
- It contains the pinning constraints for Google websites only. Chrome also ships with rules for other groups such as Tor and Twitter.
- For reasons noted above, the conversion can in principle introduce false positives– flagging valid chains as forgeries– as well as false negatives– failing to warn about incorrect certificate chains.
Configuring EMET requires administrator privileges– not surprisingly, since changing the settings involves a write to the HKLM section of the registry. As such this operation must be executed from an elevated shell:
C:\> emet_conf --import google_pins.xml EMET is importing configuration, please wait... Processed 0 entries
The import functionality seems buggy in the current beta release. A good way to observe this is by running the above command line under a debugger such as windbg, with CLR exception handling enabled to inspect uncaught managed exceptions. The command reports zero entries processed even when the operation is successful. One hopes these bugs will ironed out in the final release. Until then, the registry is a better way to confirm that rules were imported correctly. Refreshing registry editor view reveals the appearance of new subkeys under certificate trust settings. Sure enough the EMET configuration GUI also confirms that story: both protected websites and the pinning rules are populated with new entries.
As a sanity check, we can try visiting a Google website and intercepting SSL connections using Fiddler. Fiddler performs this feat by executing a “friendly” man-in-the-middle attack, using a forged certificate. Doing that now triggers the EMET certificate warning because the observed certificate chain for the website is rooted in the local Fiddler “certificate authority” instead of one of the whitelisted CAs enumerated in the pinning rule.