Null Character Hack Allows SSL Spoofing 280
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.'"
Re:Is the null character valid in a domain name? (Score:1, Informative)
The CA issued a malformed Cert. The browser (firefox) did not catch the malformation. Who is to blame? Both I would think.
Re:Are CA's that stupid? (Score:4, Informative)
\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. [cmu.edu]
Basically, "network notaries". Decentralization of (a kind of) authentication.
This is one thing that makes self-signed certs viable for a popular audience.
Re:And we trust CAs *why* again? (Score:3, Informative)
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.
Really? It seems to me that with a centralized system, you have one entity controlling trust. If you want to subvert that, you have to convince that entity that you are trust worthy. If you have a decentralized system, you could have 1000 entities controlling trust. That's 9999 more chances you have to trick someone.
Decentralized systems are at first glance more appealing, but I don't think they are safer in this case. The problem in this case is that the CAs aren't incentivized to ensure trust. They make money based on the number of certificates they sell, not the trustworthiness of those certificates. CAs should be non-profit, or at least heavily penalized for issuing false certificates, if this is going to work.
Re:If we were using pascal strings... (Score:5, Informative)
It's actually rather amusing that people here proclaim Pascal-style strings as the solution to all our woes.
It's because certificates use ASN.1 [wikipedia.org], essentially a modern-day Pascal string, that these vulnerabilities are possible. If certificates instead were encoded using C-style strings, NULLs wouldn't be an issue.
Re:\0wned (Score:1, Informative)
Re:And we trust CAs *why* again? (Score:3, Informative)
The problem is the same with Moody's, actually: the central issue is that the people doing the auditing are being paid by the people they're auditing. Simply having browser users pay CAs (or investors pay rating agencies) would put the economic incentives in the right place, but that idea doesn't sit well with a lot of people.
So instead, we're left with imperfect and leaky regulation. CAs really should be subject to more regular audits, and their trust bits should be removed by browser vendors when they are abused.
By the way: I remove Comodo root certificates from any browser I use. Comodo allows its affiliates to issue certificates to anyone without verification [theregister.co.uk], and therefore I do not trust Comodo.
Re:And we trust CAs *why* again? (Score:4, Informative)
I'd rather add "Bruce Schneier" to my list of trustees, but your friend "Bruce Schneider" may be okay too.
I'm really not trying to be a smartass. I just want people to get his name right; he deserves it.
Re:Paypal.com versus Badguy.com (Score:5, Informative)
P.S.
Obligatory explanation: In the early 2000s, paypal.com was arbitrarily closing customers' account and keeping the money for themselves. (You can read more detail at paypalsucks.com) After a couple of years of this, the Bush adminstration's FTC investigated, found paypal guilty, and required paypal.com to refund all the money they had taken. Some people received full refunds while others received flat payouts. I was one of those who received a $50 check.
So long story short - Paypal.com and Badguy.com are synonymous for many people.
Another action Bush's FTC took was against record companies. They found the companies had created an illegal cartel to pricefix retail sales of CDs (gee what a surprise), and the companies agreed to settle the case by issuing refunds. I received an $18 check, ditto my brother, ditto my mom, and ditto my two nieces. It might take-awhile but eventually the law catches-up to illegal corporate activities.
Defense-in-depth (Score:2, Informative)
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.
VeriSign Responds to Black Hat (Score:4, Informative)
Re:MS BSTR and null terminated strings (Score:3, Informative)
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.
Re:Are CA's that stupid? (Score:4, Informative)
Re:Only as secure as the gate-keeper. (Score:3, Informative)
You could argue that but I might argue that NULL in not a valid character in an FQDN. It is by extension not a valid character in the CN attribute of a certificate issued for an FQDN. I have not looked at the code but the cert parser probably decrypts the certificate looks at the length of the string copies that many bytes into some other data structure null character inclusive, as well as everything beyond it just like it should.
Then some other code looks at the data obtained from the SSL cert now stored in that internal struct which contains pointers to null terminated strings, a perfectly correct, perfectly common practice in C,C++ and loads of others. There is no checking of those strings for embedded NULLs because there should never be one, as stated above. I would say for a security function this classifies as a bug. They only reason I say that is in a security function one has to assume the input will in fact be malicious much of the time and violate all sorts of standards, rules, and conventions.
So yes firefoxes SSL validation should be more rigorous in its input validation and toss out a cert as bad if it contains characters that would not be permissible in any given attribute.
Really the problem lies though with the CA. They should also be doing that input checking, and not issuing certificates no permissible characters for any given attribute. A CA is after all supposed to be authenticating that this entity really is who they claim to be. If they claim to be something that can't exist, because it has an illegal name as in this case, then they must by definition be false and should have been rejected.
It comes do to who was responsible for what. The browsers job is really only to verify that the certificate is valid. It was it has a valid signature from the CA. The CA job was to validate the information on the certificate before issuing it, they failed.
Moxie at Black Hat (Score:4, Informative)
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.