Information regarding MD5 collisions problem

Today Microsoft released a security advisory (961509) regarding collisions in MD5 hashes on certificates. This specific problem affects the entire industry and is not a Microsoft specific vulnerability. Serious weaknesses in MD5 have been known for many years now; it is because of these weaknesses that MD5 is banned in new code under the Microsoft Security Development Lifecycle (SDL). Software developers are urged to migrate away from using MD4, MD5 and even SHA1 and use SHA-256 and later instead for hashing, signatures and message authentication codes (see slide 22 for more information http://download.microsoft.com/download/8/4/7/8471a3cb-e4bf-442a-bba4-c0c907d598c5/Michael%20Howard%20SDL%20Development%20Practices.ppsx)

The most common type of certificates that Certificate Authorities (CAs) will issue are for three main purposes:

1. Secure Socket Layer (SSL) or Transport Layer Security (TLS)
2. Secure E-mail (such as S/MIME)
3. Code signing (such as Authenticode)

In this context, we believe that the most likely attack scenario will through SSL/TLS (though we have not seen any attacks at this time.) Thus, common web browsers are similarly exposed to this problem since HTTPS uses SSL/TLS to establish the secure connection.

Thus the purpose of this blog post is to explain this problem in more detail as well as highlight mitigations and workarounds when using Internet Explorer.

Lastly, we should note that certificates hashed with SHA1 are not affected by this problem.

Summary of the problem

An MD5 hash collision allows a malicious user to potentially generate a rogue certificate derived from a valid one. This user can then impersonate a valid site or person since both certificates look legitimate because the certificate hashes are the same. An attacker will have to lure a user to initiate an SSL/TLS connection, then the certificate will be validated by the client and it will seem valid. Thus, the user will think that it is establishing a safe connection with site or person when in fact it is connecting with the attacker.

Although any certificate hashed with MD5 and then signed can potentially be manipulated we have not seen any active attacks.

Mitigations & Workarounds

Green filled address bar (IE7 & IE8)

Extended Validation certificates (http://www.cabforum.org/EV_Certificate_Guidelines.pdf) are required to use SHA1 (instead of MD5) Thus, these certificates are not affected by this problem. Internet Explorer 7 and later take advantage of EV certificates by highlighting the address bar in green. See http://blogs.msdn.com/ie/archive/2006/11/07/improving-ssl-extended-validation-ev-ssl-certificates-coming-in-january.aspx for more information. Below is such an example:

In short, if Internet Explorer 7 address bar is highlighted in green then there is no risk against this attack.

Certificate revocation in IE7 & IE8 & OCSP configuration

Certificate revocation allows a Certificate Authority to revoke a specific certificate, after which it is no longer accepted as valid by the user’s browser. While it does not fully help prevent the attack, it improves the ability a certificate authority has to respond to them by allowing them to disable fraudulent certificates.

Certificate revocation is enabled by default for Internet Explorer 7 and later (running on Vista & above) since Online Certificate Status Protocol (OCSP) is used to confirm whether a certificate is valid or not. Thus, in the event that a malicious certificate is being actively used then a Certificate Authority can revoke it and Internet Explorer will automatically block the web-site visited.

Below are the steps needed to configure an OCSP.

Steps to Configure Custom OCSP Responder Location Locally on Vista SP1 and Windows Server 2008:

1. Start the Certificates MMC snap-in
2. 1. Click on the Start button and enter mmc.exe into the Start Search field
3. From the File menu, select Add / Remove Snap-in…
4. Select the Certificates snap-in on the left and click Add
5. Select _Computer account, click Next, then click Finish _to complete the wizard
6. Click OK to dismiss the dialog
7. Configure the snap-in to show Physical Certificate Stores
8. 1. Select the Certificates (Local Computer) node
9. From the View menu, select O_ptions…_
10. Check thePhysical certificate stores _checkbox, then click _OK
11. Select the public commercial root CA you want to configure to use with a custom OCSP responder
12. 1. Select the Certificates (Local Computer) -> _Trusted Root Certification Authorities -> Third Party -> Certificates _node
13. Select the root CA
14. Move the root CA certificate to the _Registry _node
15. 1. Right-click on the root CA certificate
16. Select Cut
17. Select the Certificates (Local Computer) -> Trusted Root Certification Authorities -> Third Party -> Certificates-> Registry -> Certificates node
18. From the Action menu, select Paste
19. Configure the custom OCSP responder location with the root CA certificate
20. 1. Right-click on the root CA certificate
21. Select Properties
22. Select the OCSP tab
23. Enter the URL to the custom OCSP responder in the edit box next to the Add URL button, then click Add URL
24. Click OK

Steps to Configure Custom OCSP from Group Policy

1. Select the Group Policy Object where certificate configuration will be stored
2. From the Group Policy Editor, select the _Computer Configuration -> Windows Settings -> Security Settings -> Public Key Policies -> Trusted Root Certification Authorities _node
3. Add the Root CA certificate to Group Policy. Note: You must remove the root CA certificate from the _Third Party Certification Authorities store _from each computer manually prior to applying this policy
4. 1. Right click on the _Trusted Root Certification Authorities _node and select _Import… _to add the root CA certificate
5. Click Next
6. Enter the file name of the root CA certificate, then click Next
7. Click _Next, _then Finish to complete the wizard
8. Configure the custom OCSP responder location with the root CA certificate
9. 1. Right-click on the root CA certificate
10. Select Properties
11. Select the OCSP tab
12. Enter the URL to the custom OCSP responder in the edit box next to the Add URL button, then click Add URL
13. Click OK

Certificate revocation on IE6

Certificate revocation checking is disabled by default on Internet Explorer 6, as it requires the download of a Certificate Revocation List (CRL) to validate whether a certificate is still marked as valid. On low bandwidth connections, such as dial-up, this may increase latency.

Certificate revocation for Internet Explorer 6 can be enabled following the below steps:

1. On the Tools menu, click Internet Options, and then click the Advanced tab.
2. In the Security area, select the Check for publisher’s certificate revocation and Check for server certificate revocation check box.

See below link for more information:

http://www.microsoft.com/technet/prodtechnol/ie/reskit/6/part2/c06ie6rk.mspx?mfr=true

Reviewing the certificate

Another alternative to verify whether the certificate is using MD5 is to look at the certificate details. It is important to note that the certificate itself and the entire chain (the Certification Path), excluding the root, needs to be reviewed to assess whether a certificate hashed with MD5 has been used. Below are the steps on how to do this in Internet Explorer 7.

1. Click on the lock icon in the address bar:
   
2. The below window will open up:
   
3. Click “View certificates”
4. The below window will open up:
   
5. If the signature algorithm is SHA1 using RSA (sha1RSA) then this certificate is safe from the vulnerability described in this document, if it is MD5 (such as md5RSA) then it could potentially be compromised.

Caveat: If the rogue certificate has misleading information about the CRL then web browsers might not be able to identify the certificate as revoked. In corporate PKI deployments, we recommend configuring a specific OCSP responder in the Windows OCSP configuration. This will allow organizations to revoke certificates that have been fraudulently signed and modified to no longer carry a correct validation location.

We would like to thank the engineers who helped build the above guidance:

• Eric Lawrence from the Internet Explorer team
• Kelvin Yiu and Tom Albertson from the Windows Cryptography team
• Maarten Van Horenbeeck from the Microsoft Security Response Center team
• Michael Howard from the Security Development Lifecycle team

Finally, the link to the Microsoft Security Response Center (MSRC) blog, which discusses this advisory is: http://blogs.technet.com/msrc/archive/2008/12/30/information-on-microsoft-security-advisory-961509.aspx

Update 12/31/08: “Reviewing the certificate” section updated in resposne to e-mail to switech AT microsoft.com.

Damian Hasse, MSRC Engineering Blogger

Posting is provided “AS IS” with no warranties, and confers no rights.