InputOutput.io

2009’s Beating on SSL, Round One

Hot on the heels of the Microsoft Crypto API patch comes another SSL vulnerability. The last round of attacks on SSL relied on a problem with the deployment of SSL on the web, as the research of Moxie Marlinspike shows. To sum up the crucial point in their research in a nutshell: just because the x509 protocol in web certificates accepts strings such as www.paypal.com\0.thoughtcrime.org without terminating the string, that doesn’t mean your web browser will do the same. We’re able to actually create a certificate signing request (.csr) with www.paypal.com\0 as the subdomain to a domain which we genuinely control. Because of the automated nature of today’s domain (and subdomain) verification process, this will go unnoticed by most Certificate Authority signing processes. Once we get the certificate back from the CA, we’re able to pose ourselves as a man-in-the-middle. Until recently, most browsers would terminate the string at the null character, leaving “www.paypal.com” as the domain for which we’ve been authenticated. Not only is this a theoretical possibility, but Moxie has released tools for it, available at thoughtcrime.org, which are probably still quite effective for unpatched systems.

Round Two: The K.O.

Whereas the null character vulnerability was an issue with web deployment of SSL and certificate chaining, the latest flaw (released on November 5th) seems to be a severe problem with the protocol itself. While there’s been a fair degree of hype surrounding a number of supposed vulnerabilities in SSL, this seems to be the real deal. Specifically, the flaw is in SSL 3.0/ TLS 1.0 – and has something to do with inserting unverified traffic into the renegotiation process of SSL sessions. Marsh Ray of PhoneFactor discovered the vulnerability, which seems to be severe, and “In certain circumstances this flaw could be used in MITM attacks, allowing an attacker to inject attacker-chosen plain text prefix into a secure session of the victim.” The bug has been being worked on for several months, and OpenSSL has released a patch to deal with the bug in its 0.9.8l release, available at www.openssl.org. Again, this is not a problem with deployment, or (as with last year’s Debian SSL vulnerability) distribution-specific forking, it is a fundamental problem with the way SSL renegotiates sessions. Also unlike last year’s Debian vulnerability, which can be retroactively exploited, this exploit requires foreknowledge of the vulnerability and situating oneself as a man-in-the-middle. Exploits are in the wild as of this writing. Kudos to OpenSSL for releasing a patch so quickly.