Cupfighter.net

The background: In the past, basic constraints where not properly checked, so any client certificate could be used to create  another client certificate that would actually validate.

Moxie wrote the tool SSLSNIF is that is able to do a man in the middle attack on  an SSL connection based on this vulnerability to proof to Microsoft that it could be exploited, contrary to what Microsoft said.

Even tough Microsoft and others fixed the vulnerability, the tool is still useful, mainly because people don’t pay attention to certificate warning. Also when the guys that made the fake CA certificate by means of the the MD5 collision use SSLSNIFF to actually exploit is.

But there are more ways to attack SSL then doing a man-in-the-middle attack; SSL Stripping

SSLSTRIP actually attacks SSL before we get there by doing a MitM attack on http. Most https links are not typed, but clicked on or redirected to. SSLStrip watches the http traffic go by and modifies links to https sites to links to http, but it still does the https connection in the backend.

The server thinks is everything is normal because it is receiving valid https requests, the client does not display any warnings, but they are missing lock, but because the user is trained to pay attention to negative feedback and not look for positive feedback, this is not a big issue.

Where do we need to go next?

SSL needs to provide Secrecy, Authenticity and Integrity in order to be effective.

One of the issues is that today there are no people involved anymore with SSL certificates. Just domain validation which is based on a Whois lookup of root of the subject. This provides an email address or phone number to send a token to.

The standard for the DN has totally broken down. Most implementations just look at the CN= part. The CN is stored as a ASN1 string in memory, so they are basically Pascal strings, which means that the actual string is prepended by a byte representing the length. The null character is a valid part of CN string. However if you use the C routine Strcmp() it will actually regard www.paypall.com\0evil.org the same as www.paypall.com.

This bug exists in most web browsers, mail clients, chat clients and SSL vpn solutions like Citrix.

SSLSNIF 6.0 supports this.

Drawback of this attack: It needs to be targeted

Most of these products use NSSto do their certificate validation. If you look at the size and structure of the CN comparison code, there must be a bug in there somewhere.

There is: a certificate for *\0thoughtcrime.org will actually work. This is better then a CA certificate. *~thoughtcrime.org will work as well for some strange issue. As will grouping. CN=(www.paypal.com|www.google.com|www.bankofameric.com)\0.thoughtcrime.org actually works as well.

Also there is a flaw in the code thas actually remotely exploitable: (AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\0OVERWRITE).foo.com. And the good thing is, the certificate does not even need to be signed.

Wildcard support is in SSLSNIF as well.

It does fingerprint the clients as well to see if they are SSN clients.

Two measures work against these attacks: Revocations and software updates.

These days most revocations are checked via OCSP. The OSCP response “try later”, the number 3, does not need to be signed. Most SSL implementations will assume a cert is valid if a “try later” rsponse is sent.

This is now also in SSLSniff.

Updates

Most software has an auto update function, e.g. take Firefox or Thunderbird. Unfortunately, these update mechanisms themselves could be a problem. Actually, Firefox/Thunderbird update files are not signed and they totally rely on TLS for their security.

This is also included in SSL Sniff

Stripping the NULL character is not the solution. Some CA’s are vulnerable sitekey.ba\0nkofamerica.com becomes sitekey.bankofamerica.com.

http://www.thoughtcrime.org

When asked, Moxie confirmed that Firefox 3.5 is NOT vulnerable.

moxie@toughtcrime.org