Security Research & Defense

Information from Microsoft about vulnerabilities, mitigations and workarounds, active attacks, security research, tools and guidance

September, 2011

  • 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

  • Is SSL broken? – More about Security Bulletin MS12-006 (previously known as Security Advisory 2588513)

    On January 10th, Microsoft released MS12-006 in response to a new vulnerability discovered in September in SSL 3.0 and TLS 1.0. Here we would like to give further information about the technique used to exploit this vulnerability and workaround options Microsoft has released if you discover a compatibility issue after installing the update.

    Is SSL broken?

    Yes and no. Yes means that under certain circumstances, the attacker can decrypt the encrypted SSL traffic. No means that there are significant mitigating factors that would make the attacks difficult or impossible. By default, SSL 3.0 and TLS 1.0 are enabled on Windows operating systems.

    What does the update do?

    The update modifies the way that the Windows Secure Channel (SChannel) component sends and receives encrypted network packets. This addresses the vulnerability affecting WinHTTP and provides the possibility to enable the protection system-wide. However, in order to be protected from the web-based attack vector through Internet Explorer for this vulnerability, customers must install both MS12-006, and the Cumulative Security Update for Internet Explorer (2618444), MS11-099.

    Attack vector

    In the advisory, it is mentioned that the vulnerability could allow the attacker to decrypt the SSL 3.0/TLS 1.0 encrypted traffic. While the affected component is a Windows component, the primary vector is to attack the browser’s use of the HTTPS protocol to intercept sensitive information, such as the session cookie of the HTTPS session.

    Mitigation

    Based on our current investigation, the following are mitigating factors that would make any potential attack via currently known exploit vectors difficult or impossible:

    • The HTTPS session must be actively attacked by a man-in-the-middle; simply observing the encrypted traffic is not sufficient.
    • The malicious code the attacker uses to decrypt the HTTPS traffic must be injected and run within the user’s browser session.
    • The attacker’s malicious code needs to be treated as from the same origin as the HTTPS server in order to it to be allowed to piggyback on an existing HTTPS connection. Most likely it requires the attacker to exploit another vulnerability to bypass the browser’s same origin policy.

    Therefore, if the user closes all existing HTTP tabs and untrusted HTTPS tabs, then browses to the trusted HTTPS site, such as the log-in page of hotmail.com in a new browser session, and logs out of that HTTPS session before browsing any other HTTP sites or untrusted HTTPS sites, the user will NOT be at risk for this attack.

    Workaround

    One workaround we would encourage the web server administrators to do is to give a higher priority for the RC4 Cipher Suite than CBC since the attack only affects cipher suites that use CBC. By giving a higher priority for RC4 on the server, RC4 instead of CBC will be used in the security communication since all of windows clients support RC4, unless put in FIPS compliant configuration. Please refer to this MSDN article to learn how to perform this operation via group policy. It is an effective option for web server administrators using Windows Vista or Windows Server 2008 and later platforms.  We recommend putting TLS_RSA_WITH_RC4_128_SHA as the top of the priority list, as indicated in the following image:

    We would also encourage users and web administrators to enable the newer security protocols, such as TLS 1.1, on both the client side and the server side. By default, these are disabled (more below). If the browser and web server both enable TLS 1.1, the HTTPS traffic uses TLS 1.1 protocol instead of SSL 3.0/TLS 1.0, and thus won’t be affected by such attacks. TLS 1.1 protocol is supported in Windows 7 and Windows 2008 R2.

    Automated FixIt Options:

    Microsoft has released several FixIts to help automate enabling TLS 1.1 and a workaround FixIt to disable the functionality of the update if you find a compatibility issue that you need immediate ability to rollback without uninstalling.

    To ENABLE TLS 1.1 for Internet Explorer and other WinINET-based applications running on Windows 7 and Windows Server 2008 R2, please click here: 

    To ENABLE TLS 1.1 for server-side components running on Windows 7 and Windows Server 2008 R2, click here: 

     

    If you would like to revert the changes made by these FixIt's, you can find a corresponding DISABLE Fixit for both the client side and server-side changes at http://support.microsoft.com/kb/2588513.

    To temporarily DISABLE the security update to confirm a compatibility issue without having to uninstall it, click here: 

     

    To re-enable the security update, click here: 

     

    Why TLS 1.1 is not enabled by default?

    The main reason to not enable TLS 1.1 by default is due to compatibility problems. We need more servers to implement HTTPS protocols correctly so we can enable TLS 1.1 by default in the client in the future versions of IE. We will work hard to drive adoption of TLS 1.1 or TLS 1.2 as an industry-wide effort.

    Special thanks to Nasko Oskov and Eric Lawrence.

    Update Sep 27 - Mitigating factors list applies to all currently known attack vectors.  Thanks for the suggestion to clarify, Juliano.

    Update Mar 14, 2012– Renaming to reflect release of MS12-006 and adding links for additional FixIt items. Special thanks to Kevin Ledman. 

    - Chengyun Chu, Jonathan Ness and Mark Wodrich from MSRC Engineering