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.'"
If not, the CA should not have issued the cert in the first place. Which CA was it?
Go green: turn off your refrigerator.
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..
>>>"I would also like a beer#@a9101gb230b81;kajf3#$B89*#()*13!$%#@$""
When I first read this I thought something was wrong with my modem. This is how online surfing used to appear prior to the advent of error-correction. Random noise could suddenly appear in the middle of your test. ..... Well I think I'm done for the day. Goodbye all!
+++
ATH
bio#OP*qe! B89*#()*13!B89*#()*13!B89*#()*13! (click)
CARRIER LOST
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Java strings!
32bit signed int, max length 2GB.
That ought to be enough for anybody. ;) If you need longer, there's special buffer classes that can go longer.
The string also chooses between ASCII and Unicode when initialized, (you can manually set char encoding, as well) so properly cleaned/trimmed ASCII strings don't waste any memory. (Except for the 3 bytes extra that go into a length int, instead of a null char - but those 3 bytes also give you an amazing speedup when you need to know the length of the string.)
I believe C# implements Strings in a similar way.
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
Isn't that why they charge huge amounts for the certs?
No, I think that's called rampant profiteering. And because competition has driven the price down too low for them (oh no, they can only get away with charging ~50 euros for an automatically-generated chunk of data) they've introduced extended validation certs, where they actually do what they were supposed to be doing in the first place and charge yet more money for it...