ev certs are not so ev

Last week at CanSecWest, Alex Sotirov and Mike Zusman showed how extended validity (EV) certificates don't really provide much additional help to securing a site with SSL. To sum-up a couple of their conclusions:

1. It's not hard to get a regular cert for an interesting domain.
2. An EV-certified site can load data from any other SSL-encrypted locations, regardless of the cert.
3. Rogue cert + MITM + EV-site = arbitrary attack code execution on EV-site.

It seems to me that the problem is rooted in a slight but pervasive misunderstanding of what EV certs do: they provide a more rigorous check to ensure that the entity serving data through the EV certified channel is actually who they claim to be. They don't currently give proof to a site's visitor that the site has not been compromised.

Having said that, if an attacker can prey on the way the site serves content, it doesn't matter whether or not the EV entity is actually who they claim to be; an attacker can just piggyback on their session, serving some cleverly crafted data with a rogue cert. This can be done by playing man in the middle with third-party content embedded on the EV site, or by playing tricks with the browser's cache.

Easy fix: In order to display the green bar (EV badging) require all the stuff on a web page to be served with the same EV cert. This is not attractive for many reasons, including ad syndication and distributed content serving -- both highly desirable uses may cross the fully-qualified domain border and thus require non-EV certs or multiple different EV certs. (EV certs are not allowed to have wildcard domain matching, so any difference in domain name will cause the cert to be invalid).

A more desirable fix, in my opinion, will take a look at the problem from a base level and figure out why EV breaks in these mixed-content or mixed-cert scenarios--then fix EV. The EV cert says "trust my subject at domain.com." What we really need is a way to say "trust this site."

More to come.

Cheers to Sotirov and Zusman for this excellent discovery and PoC man-in-the-middle script.

iphone's ambiguous http-auth

I'm a little disappointed at Apple. While I think the iPhone is a pretty nice piece of work and their browser is pretty nice too, I don't like the way it handles HTTP-AUTH. (There are other gripes I have, like no "find" feature in safari or the mail app, but we'll stick with a security problem for now). Most browsers are kind enough to display on the "safe" pop-up login box which which website requested the authentication. This is not so with iPhone Safari.

Not only does the pop-up "enter your password" box fill the whole screen (a rather necessary evil), but it doesn't display the domain, URL or any information about the website where you're sending your credentials. If I had some free time, I would hack together a quick demo to show how, using iframes (suitably) or images, I can make you think you're logging into one site but you are actually sending your password to another one entirely. It does indicate whether you are sending your password in the clear or if the connection is secured with TLS/SSL, but in a subtle gray font under the login boxes.

I want to know where my password goes!

bad security assumption

Good assumption:

My domain (DNS) name is not safe from forgery. Bad people might "hijack" it and use it to pretend they are me.

Bad assumption:

If my domain name is hijacked or spoofed, then I lose control of all the subdomains too. This means that if someone else pretends to be sidstamm.com then they will also take control over blog.sidstamm.com, mail.sidstamm.com and ohcrap.sidstamm.com.

Bad: DNS spoofing is done on the record level, and since each subdomain happens to be a different record, an attacker might control one subdomain and let you retain control over the rest.

Consequence of this: The same-origin policy enforced by most browsers says this: scripts served by one host cannot access, execute or change data served by another host. In this case b.a.com and a.com are considered different hosts.

There is one exception to the rule: a website may change its "document.domain" property to a suffix of what it currently might be. For example, a page served by b.a.com may set its domain to a.com AFTER it is served. In this case, b.a.com can play with a.com's data.

Your data is no longer safe, unless you control all of your subdomains. The case used to be simpler: a phisher or pharmer must create a complete duplicate of a site to fool with it. Now, he just creates a parasite frame, and watches you interact with the real thing. Beware of visiting update-security.yourbank.com.

Scary.

(Link to Abe Fettig's explanation)
(Link to Same-Origin Policy info)