The truth about new SSL attacks

Security researchers at Black Hat demonstrate new attacks for defeating SSL

The Blackhat security conference kicked off today and in true fashion several allegedly zero-day exploits and other nastiness were revealed by security researchers. Several of today's security talks at Blackhat 2009 here in Vegas focused on newly found security vulnerabilities in the digital certificate controlled SSL encryption process as it exists today. SSL is the cryptographic technology used to secure millions of website transactions globally. Every time you login to your banking, trading, shopping, etc. website you are using SSL to encrypt and secure your Internet session with them. Several security researchers presented ways to hack the most trusted of security protocols, SSL, using varying techniques of compromising the certificates that SSL relies upon for security. However, It seems that all of the security vulnerabilities being discussed need for the attacker to be man-in-the-middle of an SSL session to work. Gaining man-in-the-middle (jumping into the data stream between you and the website you're talking to) is not a straightforward, easy thing to do. But if they were to gain this type of access the researchers say they can hack into any SSL encrypted web session no matter where it is to.

Several techniques were discussed at Blackhat, almost all relied on compromising the X.509 standard used to issue and validate certificates. Digital certificates work like passports. A country issues passports with a photo of you. When you go to enter a country they verify that the passport is real and then if the photo matches your face. If both match, then you get in. Digital certs work the same way in cyber space. A website hands you their certificate. Your browser validates that the certificate is real/valid by asking a trusted source called the root certificate authority (CA). If the certificate is real then it looks to see if the certificate common name matches the website domain name that sent it to you. If that is a match then your browser will accept the certificate and use it to encrypt your web traffic to that site.

Let's go through an example given by security researchers on how they have purported compromised SSL security (man-in-the-middle is still required).
When SSL x.509 certificates are parsed a null character is interpreted to be a stop processing indication. This is because the certificate parsing code was written in C and C interprets a null to signify end of a string. So if a hacker requests a certificate with the name of www.bigcompany.com/0www.hackersite.com (/0 signifies a null char) of a site (www.hackersite.com) that they legitimately own the root CA may issue it to them since most CA's only verify that you are the owner of the root site hackersite.com. CA's, according to the researchers, typically don't look beyond that to verify if a cert should be issued to the requester. In almost all cases this makes sense right, if you want to obtain a certificate for your business called www.business.com or portal.business.com or whatever. Business.com, the CA really shouldn't care what prefix you want. The CA is traditionally concerned about just verifying that you have the right to request a cert for the base domain name of business.com.

So the hacker get issued the certificate for www.bigcompany.com/0www.hackersite.com by a valid root CA. The hacker gains man-in-the-middle access to the victim's data stream. The victim goes to www.bigcompany.com to login. The hacker intercepts the request and send the victim their new certificate www.bigcompany.com/0www.hackersite.com instead. Normally you would expect the victims browser to set of alarms indicating that the certificate does not match and is invalid. However, according to researchers, the issue is that the C code written to validate the certificate will stop parsing the string when it reaches the null character. Therefore, according to the browser the certificate came from www.bigcompany.com and is signed by a valid CA. This means that the victims browser will not pop any warnings and trusts the hacker cert. In fact, even if the victim goes to look at the details of the certificate they will only see the www.bigcompany.com listed and not the www.bigcompany.com/0www.hackersite.com making it very hard to detect the intrusion.

Researchers went on to say that the problem with the above example is that it requires you to have a certificate named correctly for every site the victim goes to. Not very practical right? Well, according to the researchers, the C code that parses certificates for the browsers also honors the grouping and wildcard symbols native to C. This means that a certificate like companyAsite|companyBsite|companyCsite|/0www.hackersite.com would be valid for any of the company websites listed in the certificate common name (CN) grouping. A wild card certificate like */0www.hackersite.com would also be valid for any website the victim goes to since C parses * as a wildcard "any" value. It is the equivalent of a "master" certificate.

Given that the hacker can now intercept and decrypt all SSL sessions from the victim the researchers looked at how to also turn this into a remote exploit that would put code on the victims PC. One of the ways purported to work for this is the built-in update function found in some browsers. Apparently the browser update function relied solely on the security of the SSL tunnel that carries the update code and thus did not sign any of the update code given back to the browser for install. This means that the browser would install anything that the update server sent it. This includes browser updates as well as browser add-on updates. According to researchers, the browser also relies on the update server to tell it whether to alert the user of the update via a message or to install the update silently. When you put all of these things together it means that if a hacker is able to jump into a victims ssl session it would be able to send the browser, via the update mechanism, any code they wanted to the victim and it would be installed silently. This would include sending down a malicious browser add-on for example.

The 2 talks that I attended on this subject where Moxie Marlinspike: More Tricks for Defeating SSL and Dan Kaminsky, Len Sassaman: Something to do with Network Security? According to the researchers some of the vulnerabilities they described have been patched by CA's and browser vendors in their latest code (like firefox 3.5). It was not clear if IE has been patched or even was vulnerable to the above attacks to begin with. Even so, with due diligence theses new attacks should be able to be patched readily.

The opinions and information presented here are my PERSONAL views and not those of my employer. I am in no way an official spokesperson for my employer.

More from Jamey Heary:
* Credit Card Skimming: How thieves can steal your card info without you knowing it
* Cisco enters the crowded AV and DLP client market
*Cisco's new ASA code allows you to securely take your Cisco IP Phone with you anywhere
* Cisco targets Symantec, McAfee with its new antivirus client
* Google's Chrome raises security concerns and tastes like chicken feet a>

Go to Jamey’s Blog for more articles on security.

• Cisco
• E-commerce
• Security
• certificate authorities
• Dan Kaminsky
• defeating ssl
• Heary
• Jamey Heary
• moxie marlinspike
• security
• SSL
• ssl attacks
• ssl vulnerabilities