Slashdot Mirror
Null Character Hack Allows SSL Spoofing
eldavojohn writes "Two researchers, Dan Kaminsky and Moxie Marlinspike, came up with exact same way to fake being a popular website with authentication from a certificate authority. Wired has the details: 'When an attacker who owns his own domain — badguy.com — requests a certificate from the CA, the CA, using contact information from Whois records, sends him an email asking to confirm his ownership of the site. But an attacker can also request a certificate for a subdomain of his site, such as Paypal.com\0.badguy.com, using the null character \0 in the URL. The CA will issue the certificate for a domain like PayPal.com\0.badguy.com because the hacker legitimately owns the root domain badguy.com. Then, due to a flaw found in the way SSL is implemented in many browsers, Firefox and others theoretically can be fooled into reading his certificate as if it were one that came from the authentic PayPal site. Basically when these vulnerable browsers check the domain name contained in the attacker's certificate, they stop reading any characters that follow the "\0 in the name.'"
\0\0ps.
Give me Classic Slashdot or give me death!
The lower-cost automated ones don't care. It's all handled by software; at no point in the process (on the CA side) is a human involved. And I'm betting that if the browsers aren't catching it, neither are the CAs.
If not, the CA should not have issued the cert in the first place. Which CA was it?
Go green: turn off your refrigerator.
CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol, so why should anyone be allowed to register a domain certificate with something that is not allowed.
I miss pascal strings, where the first byte was the length of the string. It had lots of cool advantages in situations like this over C's null terminated strings.
“Common sense is not so common.” — Voltaire
Most CAs will grant you a certificate for anything if you pay them the going rate.
*sigh* Why is anyone still using null-terminated strings? It's almost a shame that Pascal didn't become dominant...many of these bugs would simply not occur.
TODO: Something witty here...
Come over to C++ - we have it all!
No sig today...
Go do something else for a while. If it were not for you we all would be safer !!
All we have to do is get the CAs to pay attention to the certs they issue, correct?
Uh-oh. We're screwed.
A thousand pounds of wood moving at 300 feet per minute. Don't get in the way.
If you ask me, networks of trust such as PGP are far more difficult to compromise than a central authority. Anything centralized is going to have only a handful of people, who are easy to find, and being private citizens, easily compromised. On the other hand, an integrated cryptographic interface where anyone can vouch for the authenticity of a site, ie; a reputation-based evaluation schema, would be (relatively speaking) more secure.
I have a reputation amongst my friends and family of being "tech savvy". They trust my advice on technology. If that advice could be included in a database an integrated directly into the browser, then others they know that are also "tech savvy" (and trust) could inform their browsing actions much more than a single profit-orientated organization. I could, for example, add "l0pht industries" to my list of trustees, or "Bruce Schneider"... Or even "Rob Malda", and those people would become part of the trust network that my friends would then rely on. This is where the technology should go -- but because it conflicts with monied interests and in a capitalist society it is only the dollar value of a thing that makes our institutions protect it, it probably never will.
Trust is really the central issue, not cryptography. Cryptography enables us to extend our trust relationships into the digital world.
#fuckbeta #iamslashdot #dicemustdie
This isn't really a browser issue.
The browser is going "Show me that this cert is valid for paypal.com" and the CA is going "Here it is, for paypay.com" , at least as far as the browser is concerned.
This is no more a flaw then if the CA just started letting anyone buy certs for paypal.com.
Having multiple CAs (and cheap CAs) is a good thing, but we're only ever secure with ssl as the least secure CA.
I put on my robe and wizard hat..
Idiots? I think not. Put yourself in the shoes of programmers in the 70s. Could you have come up with a better idea that did all these?
Sure, today, C strings might seem like a poor decision today, in this age of virtual memory, C++ classes, and sophisticated optimizing compilers. But at the time, C strings were the least bad of the available alternatives.
\0 isn't a legal character in DNS protocol
Say, that's a pretty good idea. Start by limiting the input to DNS-valid characters.
Geez.
For anyone who thinks "Well, I guess there might be some bad CAs out there," please keep in mind that it only requires one of the CAs (or their delegates) that your browser recognizes to make a mistake and you're hosed. Now go look at how many CAs are listed in your browser.
Damnit, it's time to flog this again:
Every time this topic comes around I feel like I should share this thing I've run across:
Perspectives.
Basically, "network notaries". Decentralization of (a kind of) authentication.
This is one thing that makes self-signed certs viable for a popular audience.
Someone would just get a certificate that managed to put the ".badguy.com" part starting at byte 255 of some string.
Null is not a legal character in a domain name, even if you're using UTF strings. It shouldn't be allowed in a certificate.
The summary really explained what it's all about, rather than sound like a newspaper who want's you to read more. This is great! Too few summaries are like this. Editors, you should make sure every story get such a good presentation on Slashdot.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
Well, it did say "the null character \0". That seems pretty obvious. It's the null character, and we're calling it \0 because it's unprintable.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
I don't get it.
Isn't this just the same company?
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Yes, the CAs should have clear standards on what they can and cannot issue a certificate for.
However, browser makers need to assume some CAs will issue non-compliant certificates.
They should also assume some compliant certificates will be confusing to end users, whether it is because of a look-alike character, such as 1/l/!, 0/O, or many such UNICODE pairings. This applies not just to certificates but also second-level domains where an authoritative server run by badguy.com might return an address for a domain that uses characters that are supposedly illegal.
In any case, web browsers need to flag these things and make it obvious the address or certificate isn't what it appears to be.
Finally, end-user need to be educated that login.paypal.com is not the same as login.paypal.com\0.badsite.com or !ogin.paypa!.com or 1ogin.paypa1.com.
Somehow I think the latter may be a lost cause with some people.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Tim Callan, vice president of product marketing at VeriSign, responds (in more detail) to these 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.
It's a shame that the Microsoft BSTR didn't become the dominant form of string, then these problems wouldn't be occurring.
A Microsoft BSTR is simply a length-prefixed string, which are themselves older than Microsoft.
CAs should be fixed to not allow garbage in the domain. \0 isn't a legal character in DNS protocol, so why should anyone be allowed to register a domain certificate with something that is not allowed.
Exactly. My mind is totally blown by this. They're issuing SECURITY certificates and they don't VALIDATE USER INPUT?!?!? Isn't that the very first thing they cover when talking about how to design apps securely? This is would take, what, a one-line regular expression to catch? God help them if Bobby Tables wants a cert.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
Mr Marlinspike gives a more comprehensible breakdown of why this works in an interview he gave with Jeff Moss at Blackhat 09 that looks at SSL vulnerabilities in a broader light.
of the day I found a similar exploit in IE6. During a pentest I noticed that a company had a password reset site with a url like "passwordedit.info.example.com" so I regestered "passwordedit.info" and sent e-mails to some employees saying "your password will soon expire, please go to passwordedit.info.example.com and change it". However the 'e' in "example" was a Unicode character thet looked/displayed like ASCII 'e' but was not.
The trick was that IE stopped parsing the url at the bogus 'e' and went to "passwordedit.info" (my site) while displaying "passwordedit.info.example.com" in the url bar.
My site recorded the new passwords while forwarding the change request to the real site
IE6 was fixed and no press release was made (we are discreet)
domains and URLs have been changed to protect the guilty
The problem is that the certificate, being written in ASN.1 format, does use a Pascal-style length-delimited string, whereas the browser is using C-style strings. When the ASN.1 string is converted into a C-style string the early NUL terminator is preserved, truncating the domain, and this truncated domain is then used to verify that the certificate matches the URL. This wouldn't be an issue if the same string format was used in both places, whether Pascal-style or C-style.
There are multiple aspects to this vulnerability. No certificate should have been issued for an invalid domain name (NUL characters are not permitted in DNS identifiers). Given the sensitivity of the field, the domain name should not have been converted from ASN.1 format to a C-style string without some runtime verification that the resulting string is equivalent to the original, including the length. Finally, it would have made more sense to store and compare the domain name starting from the TLD; that way, if the name somehow did get truncated, the part which was verified would be the most important part and not some arbitrary subdomain.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Would this mean that there's a similar site out there called Slashnaught.org?
Or would that be Slashdot's good twin?
If you can read this, I forgot to post anonymously.
Moxie's presentation was very enlightening. Out of all the presentations I saw over the last two days, his was easily the most interesting.
First, he went over his last presentation- that due to CA sloppiness, it is possible for an attacker to issue valid SSL certificates as an intermediary CA. No hack involved.
Second, the null character exploit. This was the bulk of his presentation, and he went into detail why this works, and why Firefox pre-3.5 plus a bunch of other SSL stacks are vulnerable. Dont want to get a cert for every site you want to spoof? Get a wildcard \0 cert.
Third, it is possible to defeat OCSP with the number 3.
Fourth, he demonstrated how, due to these bugs in SSL and OCSP, it is possible to deploy your own "software updates" whenever Firefox or other program attempts to auto-update.
I hope he puts his presentation up sometime soon.