Black Hat 2009: Breaking SSL with null characters

Update: The video of [Moxie]’s presentation is now online.

[Moxie Marlinspike] appeared on our radar back in February when he showed sslstrip at Black Hat DC. It was an amazing piece of software that could hijack and rewrite all SSL connections. The differences between a legitimate site and the hijacked ones were very hard to notice. He recently stumbled across something thing that makes the attack even more effective.

If you apply for a certificate, the certificate authority looks at the common name on the form and contacts the domain owner. The CA ignores the subdomain. The trick is to drop in a null character in the subdomain. If you register,[null character], the CA will contact the owner of and issue the cert. When clients like Firefox use NSS to verify the cert, the null character causes them to think the certficate is valid for because they stop at the null character. Even if the person examines the cert in their browser, it will show

Wildcards work as well. You could get a certificate for *[null character] and appear as any site you want. [Moxie] has worked out ways to prevent certificate revocation and browser updates too. This new code will be part of sslsniff 0.6.

[Apologies for the odd notation. WordPress apparently strips null characters…]

25 thoughts on “Black Hat 2009: Breaking SSL with null characters

  1. The sslstrip “hack” is nothing more than a very basic MITM, that’s been automated to rewrite https:// URLs. This isn’t new, nor is it particularly innovative. It automates and packages functionality that other hackers might’ve written into a python or perl module on an ad hoc basis. There is no new technique or technology here.

    Also, the null certificate problem isn’t new either, it’s just not seen very often, for a variety of reasons. Not all CAs are vulnerable, nor are all browsers.

  2. plaid: Strange that both Moxie and Kaminsky think the null byte problem in SSL certs is novel if it isn’t really. They both are pretty neck deep in the SSL space.
    Any references you can point to that back up your claim of prior knowledge? I work in the web security space and was unaware of that particular bug…

  3. plaid is obviously talking about the original software piece. His comment had nothing to do with the new information in this entry.

    That is a really interesting bug, and kinda scary to be honest.

  4. It allows an attacker to spoof SSL certificates. From what I’ve read. You’d also have to use a URL vulnerability in most cases to do successful phishing with it though.

    If the user didn’t pay attention to the URL in the browser or couldn’t see it then you could phish any high security e-commerce site successfully.

    It’s scary because everything uses SSL in e-commerce to do encrypted transactions. The only data reveled from a perfect attack with this would be user input. You only get their public key. You add a URL vulnerability though and it could escalate way out of control.

  5. tjhooker: No URL vulnerability required if you can do a MITM attack using, for example, a malicious open WiFi network.

    Imagine the user tries go get an HTTPS connection to You redirect the request using iptables rules on outbound port 443 to your server, which responds to the client with a[NULL] certificate, which the browser accepts for, and then send along any page of your choice, including you could just act as an intercepting transparent proxy for the real paypal site.

    Yes, indeed this is a serious vulnerability, but the browser can easily be fixed just by rejecting\properly checking all certificates containing nulls.

  6. tjhooker:
    This one is worse then that. If a SSL Certificate Authority will give you a cert with a null byte in it, you can apply for a cert like *[null byte] A browser that is vulnerable will only see to the *, and match on all sites.
    This lets a Man In The Middle(MITM) have a valid SSL connection for any domain name. You can become a MITM with a variety of well known attacks like arp poisoning the local wifi, DNS attacks, routing attacks, etc.
    This really means that if your broswer is affected, you can’t trust SSL. Period. The cert authorities will fix their processes soon if they haven’t yet, but this attack is cheap and easy, unlike the last MD5 SSL break which required a (still fairly cheap) supercomputer and good planning.

  7. Steve, I’m a network security professional myself. I first saw a PoC NULL hack about three months ago, when it was demoed by another white hat I consult with occasionally. Previously, I’ve seen similar usage of the NULL to break certificate chaining in vulerable browsers, but this particular attack was several years ago.

  8. @steve&oliver: Yeah that would work too, but the way I figured it is it’ll most likely get used by organized crime off of botnets to harvest credit information. They’d probably integrate it with single or double flex dns techniques and propagate via social engineering.

  9. And the never ending conga line of null terminated string exploits continues.

    It was known 60 years ago that terminators and mixing data & addresses on the same stack were fundamental design flaws, yet here we are with x86 & C still trying to build skyscrapers out of jello blocks.

  10. what’s a stack? were computers around 60 years ago? what we have here is a failure of communication. or a failure of a failure of communication. credit card fraud is one thing, emptying somebody’s ameritrade account is another.

  11. Well let’s see. Tally sticks, 35,000 BC! lol Abacus, 2400 BC. South Pointing Chariot, 1115 BC. 450 BC Ashtadhyayi, 300 BC logarithm, 100 BC Antikythera Mechanism. Then after year 1, The Equatorium, Planisphere, Astrolabe, Torquetum. 1623, the Calculating Clock! Yay!

    w00t, robots!

    But yeah, until the vacuum tube in 1906, the flip-flop in 1919, the AND gate in 1924, we didn’t even end up with a mechanical version of a binary programable computer until 1938.

    But 60 years is about right, EDSAC in 1949. Or past that, the Whirlwind in 1951. 1959, the integrated circuit. But it’s not really until the 1960s-1970s that we really get going; 1962, Spacewar!, 1964 IBM 360 and DEC PDP8. Or 1965 (1969) packet switching.

    Gotta expect a few null packets tho, these days. I mean, the first known use of zero was over 2500 years ago after all.

  12. ” Yesterday, someone posted a null-prefix certificate for on the full-disclosure mailing list. In conjunction with sslsniff, this certificate can be used to intercept communication to PayPal from all clients using the Windows Crypto API, for which a patch is still not available. This includes IE, Chrome, and Safari on Windows.”

    HA, told you Opera is UNAFFECTED!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.