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, http://www.paypal.comnull character].thoughtcrime.org, the CA will contact the owner of thoughtcrime.org 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 http://www.paypal.com because they stop at the null character. Even if the person examines the cert in their browser, it will show http://www.paypal.com.

Wildcards work as well. You could get a certificate for *[null character].thoughtcrime.org 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...]

Comments

  1. Smokes says:

    Auch

  2. stevecrozz says:

    yeah, ouch is right

  3. Greg says:

    Now that is something that needs patching very quickly..

  4. Plaid says:

    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.

  5. steve says:

    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…

  6. rasz says:

    im pretty sure Opera is unaffected

  7. TJHooker says:

    interesting.

  8. Spork says:

    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.

  9. smartass says:

    @rasz

    it isnt…

  10. TJHooker says:

    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.

  11. rasz says:

    any PoC link?

  12. 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 http://www.paypal.com. You redirect the request using iptables rules on outbound port 443 to your server, which responds to the client with a http://www.paypal.comNULL.bad.org certificate, which the browser accepts for http://www.paypal.com, 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.

  13. Benny M says:

    Oh. My. GOD!

    JESUS ALLAH ETC ETC HELP US ALL!!!!!!!!!!

  14. steve says:

    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]example.com. 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.

  15. Tim says:

    Erm… why on earth are null characters allowed in domain names?

  16. tiak says:

    @tim
    They aren’t allowed in domain names. Some (but all) certificate authorities just happen not to check for them in the domains they register.

  17. Plaid says:

    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.

  18. AllenKelly says:

    Tim Callan, vice president of product marketing at VeriSign, responds to the Black Hat presentations in his new SSL blogpost:

    https://blogs.verisign.com/ssl-blog/2009/07/busy_day_at_black_hat.php

    He fills some of the holes that Marlinspike and Kaminsky dug.

  19. Antonomasia says:

    Using a NUL byte to get a string misinterpreted is at least as old as this:

    http://insecure.org/news/P55-07.txt

    but it is the first time I’ve seen it done to data supporting SSL.

  20. TJHooker says:

    @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.

  21. MrX_TLO says:

    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.

  22. roboslob says:

    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.

  23. binsbibber says:

    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! http://www.shef.ac.uk/marcoms/eview/articles58/robot.html

    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.

  24. david says:

    does anybody know a legit paypal hack? not a bs one that u just type your info in and it takes your money email me at elitemarine55@yahoo.com thxs

  25. rasz says:

    ” Yesterday, someone posted a null-prefix certificate for http://www.paypal.com 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

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 94,010 other followers