SSL: Not so secure for website authentication

[General Zod]

http://www.wired.com/threatlevel/2009/07/kaminsky/

LAS VEGAS — Two researchers examining the processes for issuing web certificates have uncovered vulnerabilities that would allow an attacker to masquerade as any website and trick a computer user into providing him with sensitive communications.

Normally when a user visits a secure website, such as Bank of America, PayPal or Ebay, the browser examines the website’s certificate to verify its authenticity.

However, IOActive researcher Dan Kaminsky and independent researcher Moxie Marlinspike, working separately, presented nearly identical findings in separate talks at the Black Hat security conference on Wednesday. Each showed how an attacker can legitimately obtain a certificate with a special character in the domain name that would fool nearly all popular browsers into believing an attacker is whichever site he wants to be.

The problem occurs in the way that browsers implement Secure Socket Layer communications.

“This is a vulnerability that would affect every SSL implementation,” Marlinspike told Threat Level, “because almost everybody who has ever tried to implement SSL has made the same mistake.”

Certificates for authenticating SSL communications are obtained through Certificate Authorities (CAs) such as VeriSign and Thawte and are used to initiate a secure channel of communication between the user’s browser and a website. 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.

More significantly, an attacker can also register a wildcard domain, such as *\0.badguy.com, which would then give him a certificate that would allow him to masquerade as any site on the internet and intercept communication.

Marlinspike said he will be releasing a tool soon that automates this interception.

It’s an upgrade to a tool he released a few years ago called SSLSniff. The tool sniffs traffic going to secure web sites that have an https URL in order to conduct a man-in-the-middle attack. The user’s browser examines the attacker’s certificate sent by SSLSniff, believes the attacker is the legitimate site and begins sending data, such as log-in information, credit card and banking details or any other data through the attacker to the legitimate site. The attacker sees the data unencrypted.

A similar man-in-the-middle attack would allow someone to hi-jack software updates for Firefox or any other application that uses Mozilla’s update library. When the user’s computer initiates a search for a Firefox upgrade, SSLSniff intercepts the search and can send back malicious code that is automatically launched on the user’s computer.

Marlinspike said Firefox 3.5 is not vulnerable to this attack and that Mozilla is working on patches for 3.0.

With regard to the larger problem involving the null character, Marlinspike said since there is no legitimate reason for a null character to be in a domain name, it’s a mystery why Certificate Authorities accept them in a name. But simply stopping Certificate Authorities from issuing certificates to domains with a null character wouldn’t stop the ones that have already been issued from working. The only solution is for vendors to fix their SSL implementation so that they read the full domain name, including the letters after the null character.

It's almost downright terrifying how easy this exploit sounds. How many people out there are using browsers that are vulnerable for it again?

[Beowulf]

My desktop is immune (Firefox 3.5 is not vulnerable).

[Darth Wong]

I use FF3.5 too. Nevertheless, this is another good reminder that the only way to reach a secure site is by using your bookmarks or directly typing the URL. You never click on a third-party link to go to a login page for anything important, like anything related to personal finance.

[Dooey Jo]

But yeah, score another hole from C's pathetic arrays!

I thought Firefox was supposed to be written in C++, although I've never taken a look at the code. Many people use the "C/C++" language, which usually means "plain old C, maybe with iostreams, but definitely using char* strings".

[phongn]

(In C, a string keeps going until it encounters that nul character, at which point it stops. This has been the source of SO many security bugs. And performance problems too, but the security is the huge problem. Fucking stupid design from the 70's still pwning people to this day!)

The design owes to memory limitations on computers of the era. I'd hardly consider it a "stupid decision" - though certainly an obsolete one.

I wonder how much ass would get kicked if you did a well crafted unicode string too?

IETF actually implemented using Unicode strings for URLs but promptly ran into the problem where people could craft URLs that were visually identical but semantically different. Great idea, unfortunately most browsers had to disable that for security reasons.

Odds are: every last one of us.

Annoyingly, the SSL guys should be scrubbing their inputs against a whitelist and throw an error for crap symbols in a domain. Client data is never trusted, after all.

I use FF3.5 too. Nevertheless, this is another good reminder that the only way to reach a secure site is by using your bookmarks or directly typing the URL. You never click on a third-party link to go to a login page for anything important, like anything related to personal finance.

A DNS poisoning attack could make it so that even if you went to the proper site by typing the URL (or using your bookmark) you'd be in trouble. SSL certificates are supposed to be another defense against this (not that people pay attention to certificate issues anyways).

[Dooey Jo]

The design owes to memory limitations on computers of the era. I'd hardly consider it a "stupid decision" - though certainly an obsolete one.

It's a really stupid decision to do it today, when we actually can afford an extra whopping 4 bytes per string. Especially if the code is supposed to be used in a really insecure environment.

[phongn]

The design owes to memory limitations on computers of the era. I'd hardly consider it a "stupid decision" - though certainly an obsolete one.

It's a really stupid decision to do it today, when we actually can afford an extra whopping 4 bytes per string. Especially if the code is supposed to be used in a really insecure environment.

Today, yes, but also consider that the Mozilla codebase is fairly old. In addition, it was not until probably the early-mid 2000s that C++ compilers really matured, especially for things like the STL. I mean, Microsoft was essentially forced to write MFC due to C++'s immaturity.

The memory cost is very small, even if you're assuming a tiny amount of memory. If you have so little memory that that one byte is a big deal, how many strings longer than 127 bytes will you have in the first place?

Memory just isn't a convincing argument, even in the context of the early 70's.

Well, given your example: you could do tricks like manipulations like that but then your complicate the implementation there (plus now you have to check all the time to handle your various cases). CPU cycles aren't quite that cheaper, either, at the time. It was probably either C-style or Pascal-style - and C-style was more efficient for the limitations of the era.

In the context of today's machines (or even those of 15 years ago)? There's just very little reason to keep it that way. Burn the extra word to store the length (or pointer to the end of the string if you prefer).

Well, yes, now we have languages with mature string implementations (e.g. C++, .NET, Java, etc) - though many of the high level languages at the time (e.g. Lisp) didn't have serious trouble, but they were a hell of a lot slower on hardware of the era.

I love C. It is a nice little language. But it is a dinosaur, causing a lot of problems.

That's clear, but it remains a nice, tight language that everyone "knows". More importantly, it's very mature and implementations are mature.