Protecting yourself from attacks that leverage fraudulent DigiNotar digital certificates

Last week, we released Security Advisory 2607712, notifying customers that fraudulent digital certificates had been issued by certificate authority DigiNotar. We’d like to follow up on that notification in this blog post by explaining more about the potential risks and actions you can take to protect yourself from any potential attacks that would leverage those fraudulent certificates.

• Scope of the risk
• Vulnerable configurations
• What Microsoft is doing to protect you
• What you can do to protect yourself
• Additional protections built-in to Windows Update

Scope of the risk

Digital certificates issued by a trusted Certificate Authority (CA) establish the identity of a computer. Protocols that assure your privacy, such as SSL (HTTPS) and TLS, leverage a server’s digital certificate to ensure that no third party can eavesdrop on or tamper with conversations between a client and the server. Clients and servers establish their identity via a digital certificate. Clients make a decision to trust the identity of the server because they trust that a CA verifies the legitimacy of the person or company requesting the certificate. If a trusted CA were to be compromised or tricked into issuing fraudulent certificates, a malicious attacker could potentially request and be granted a digital certificate that would allow the attacker to participate in HTTPS conversations, snooping on or tampering with the contents.

For an attack to be successful, an attacker must have been issued a digital certificate for the server or domain to which the client is initiating a connection. Also, the attacker must be able to tamper with the conversation in progress. Practically speaking, this tampering can happen in one of three ways:

• The attacker is on your local network (open wireless network, for example);
• The attacker owns or operates the network infrastructure between the victim client and the listening server; or
• The attacker controls the DNS server used by your ISP, or can influence your choice of DNS server via DHCP responses if a client gets DNS settings via DHCP.

Without this type of “man-in-the-middle” access, an attacker would be unlikely to be successful in carrying out an attack.

In this particular case, we were originally aware of fraudulent certificates issued by DigiNotar for *.google.com and have since become aware of fraudulent certificates issued for *.microsoft.com, *.windowsupdate.com, www.update.microsoft.com, and a number of other domains for which conversation privacy is extremely important. Windows Update is a special case addressed later in the blog; however, suffice it to say that if the attacker had one of those certificates and had man-in-the-middle access to your network traffic, they could potentially snoop on (or change the contents of) conversations between you and any of those domains.

Vulnerable configurations

All versions of Windows are affected by this attack. However, when a user initiates an HTTPS SSL connection via Internet Explorer on Windows Vista, Windows 7, or Windows Server 2008 and encounters a new root certificate, the Windows certificate chain verification software checks a list of valid root certificates, which is hosted on Windows Update. As of August 29th, this Certificate Trust List (CTL) on Windows Update has been revised to remove DigiNotar from the list of trusted Certificate Authorities so that any certificates issued by DigiNotar are no longer trusted for HTTPS conversations.

Windows XP and Windows Server 2003 do not have the same Windows Update check mechanism. Instead, these versions of Windows rely on a static list of trusted root certificate authorities. This list is updated through the non-security update “Update for Root Certificates (KB 931125)”. DigiNotar was not initially included as a trusted root certificate in Windows XP, so if you have never installed this update, you are not vulnerable to any certificates issued by them.

However, any Windows XP or Windows Server 2003 system that installed this update as of November 2008 or later would have DigiNotar added as a trusted root certificate. Administrators of these systems can follow the steps in the “What you can do to protect yourself” section below to take proactive actions to remove DigiNotar as a trusted root Certificate Authority until Microsoft releases an update that fully addresses this problem.

Windows Phone devices are unaffected. No Windows Mobile devices have a DigiNotar certificate in the Trusted Root Certificate Store.

What Microsoft is doing to protect you on Windows Vista and later platforms

Microsoft has updated the Certificate Trust List (CTL) hosted on Windows Update to remove DigiNotar as a trusted root Certificate Authority. Attacks targeting Internet Explorer users on Windows Vista and later platforms any time after August 29th will likely fail. However, we should note that systems having previously encountered DigiNotar certificates may have cached DigiNotar as a trusted root Certificate Authority. This cached list is updated client-side every seven days. Therefore, the last date on which any attack targeting Internet Explorer users on Windows Vista and later platforms might possibly be successful is September 5th.

What Microsoft is doing to protect you on Windows XP and Windows Server 2003

We are currently preparing an update for Windows XP and Windows Server 2003 platforms which will add DigiNotar to our Untrusted Certificate Store. This update will be available soon.

What you can do to protect yourself

First, as indicated in the security advisory, we recommend keeping Microsoft software updated. If you’re able to do so, opt into Automatic Updates to automatically get the Windows XP and Windows Server 2003 updates when they become available.

Second, you can choose to delete the DigiNotar root from the root store manually. You might consider doing this if you believe the risk to your network or system is urgent and you would like to take action before the Windows XP and Windows Server 2003 update becomes available. After doing this, you’ll also need to clear the local cache. The steps for both removing the DigiNotar root from the trusted root CA store and clearing the cache are listed below.

Step 1: Remove the DigiNotar Root from the trusted root CA store

• Click Start, click Start Search, type mmc, and then press ENTER.
• On the File menu, click Add/Remove Snap-in
• Under Available snap-ins, click Certificates, and then click Add
• Under This snap-in will always manage certificates for, click Computer account, and then click Next
• Click Local computer, and click Finish
• If you have no more snap-ins to add to the console, click OK
• In the console tree, double-click Certificates
• Double-click the Trusted Root Certification Authorities store and click on Certificates to view all certificates in the store
• Select the two DigiNotar Root CA certificates. You can confirm the right certificates by checking their thumbprints which should be “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c” and “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”
• Right-click the certificates and select Delete

To perform the above steps from the command-line, you can use the certutil.exe tools as follows:

• certutil -delstore authroot “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c”
• certutil -delstore authroot “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”

If you distribute roots in your enterprise using group policy, follow the instructions to remove a root across an enterprise network via group policy - http://technet.microsoft.com/en-us/library/cc786148(WS.10).aspx. In step 3 of those group policy instructions, choose the root CA in question here - DigiNotar Root CAs with thumbprints “c0 60 ed 44 cb d8 81 bd 0e f8 6c 0b a2 87 dd cf 81 67 47 8c” and “43 d9 bc b5 68 e0 39 d0 73 a7 4a 71 d8 51 1f 74 76 08 9c c3”.

Step 2: Clear the cache to remove any older cached CTL

The simplest way to do so is to use “certutil –urlcache * delete”. This will clean up the cache for the current user. You can find further documentation on this step, including a Microsoft Fix It package to clean up the cache, at http://support.microsoft.com/kb/2328240

--

As indicated above, most customers on Windows Vista and later platforms are already protected due to the updated Certificate Trust List on Windows Update, which is checked when Windows encounters a new root Certificate Authority. To ensure that DigiNotar has not been cached locally as a trusted root CA, you can clear the local cached CTL as explained above. A fresh CTL will automatically be downloaded the next time Windows encounters a new root CA.

There is one final edge case to consider that will not be automatically protected:

• If you are an enterprise customer having Windows Vista and later workstations; and

• If you have disabled the auto root update mechanism via the group policy option; and

• If you have manually added DigiNotar as a trusted root authority –

  Then you likely will want to add the DigiNotar roots to the Untrusted Certificate Store via group policy.

Additional protections built-in to Windows Update

Attackers are not able to leverage a fraudulent Windows Update certificate to install malware via the Windows Update servers. The Windows Update client will only install binary payloads signed by the actual Microsoft root CA certificate, which is issued and secured by Microsoft. Also, Windows Update itself is not at risk, even to an attacker with a fraudulent certificate.

Thanks to Yogesh Mehta, Shain Wray, Charles Anthe, and Mark Wodrich for the help with this blog post.

Updated Sept 5: Added certutil.exe command line example. Thanks Uwe Wizovsky for the tip.

- Jonathan Ness, MSRC Engineering