October 06, 2008

Browser Security UI: the horns of the dilemma

One of the dilemmas that the browser security UI people have is that they have to deal with two different groups at the same time. One is the people who can work with the browser and the other is those who blindly click when told to. The security system known as secure browsing seems to be designed for both groups at the same time, thus leading to bad results. For example, Dan Kaminsky counted another scalp when finding back in April that ISPs are doing MITMs on their customers:

The rub comes when a user is asking for a nonexistent subdomain of a real website, such as http://webmale.google.com, where the subdomain webmale doesn't exist (unlike, say, mail in mail.google.com). In this case, the Earthlink/Barefruit ads appear in the browser, while the title bar suggests that it's the official Google site.

As a result, all those subdomains are only as secure as Barefruit's servers, which turned out to be not very secure at all. Barefruit neglected basic web programming techniques, making its servers vulnerable to a malicious JavaScript attack. That meant hackers could have crafted special links to unused subdomains of legitimate websites that, when visited, would serve any content the attacker wanted.

The hacker could, for example, send spam e-mails to Earthlink subscribers with a link to a webpage on money.paypal.com. Visiting that link would take the victim to the hacker's site, and it would look as though they were on a real PayPal page.

That's a subtle attack, one which the techies can understand but the ordinary users cannot. Here's a simpler one (hat-tip to Duane), a straight phish:

Dear Wilmington Trust Banking Member,

Due to the high number of fraud attempts and phishing scams, it has been decided to implement EV SSL Certification on this Internet Banking website.

The use of EV SSL certification works with high security Web browsers to clearly identify whether the site belongs to the company or is another site imitating that company’s site.

It has been introduced to protect our clients against phishing and other online fraudulent activities. Since most Internet related crimes rely on false identity, WTDirect went through a rigorous validation process that meets the Extended Validation guidelines.

Please Update your account to the new EV SSL certification by Clicking here.

Please enter your User ID and Password and then click Go.

(Failure to verify account details correctly will lead to account suspension)

This is a phish email seen in the wild. We here -- the techies -- all know what's wrong with this attack, but can you explain it to your grandma? What is being attacked here here is the brand of EV rather than the technology. In effect, the more ads that relate EV to security in a simplistic fashion, the better this attack works.

To evade this, the banks have to promote better practices amongst their clients, and they have to include the user into the protocol. But they are not being helped, it seems.

On the one hand, a commonly held belief with the security developers is that the user cannot be bothered with security, ignore any attempts, and therefore it is best to not bother them with it. Much as I like the mantra of "there is only one mode, and it is secure," it isn't going to work in the web case unless we do the impossible: drop HTTP and make HTTPS mandatory, solve the browser universality issue (note chrome's efforts), and unify the security models end-to-end. As the group of Internet people who can follow that is vanishingly small, this is a non-starter.

On the other not-so-helpful hand, the pushers of certificates often find themselves caught between the horns of pushing more product (at a higher price) and providing the basic needs of the customers. I recently came across two cases at both extremes of the market: at the unpaid end of the market, the ability of a company to conveniently populate 50,000 desktops is, it is claimed, more important than meeting expectations about verification of contents. The problem with this approach is if people see strong expectations on one side, and casual promises on another equivalent side, the entire brand suffers.

And, at the expensive EV extreme of the market, the desire to sell a product can sometimes lead to exaggerated claims, as seen in a recent advertisement, seen above (hat-tip to Philipp). This advert in the German paper press includes perhaps over-broad or over-high claims. Translating from German to English as:

The latest and best in terms of online security. And also the greens.

Visible security for your site from a company where your customers trust.

It is quite simple: a green address bar means that your site is secure.

These claims are easy to make, and they may help sell certs. But they also help the above phishing attack, as they clearly make simple connections between security and EV.

"EV means security, gotta get me some of that! Click!" FTR, check the translator.

What would be somewhat more productive than sweeping marketing claims is to decide what it is that the green thing really meant.

I have heard one easy answer: EV means whatever the CA/Browser Forum Guidelines says it means. OK, but not so fast: I do not recall that it said anywhere that your site has to be secure! I admit to not having read it for a while, but the above advert seems entirely at odds with a certificate claim.

Further, because that document is long and involved, something clearer and shorter would be useful if there are any pretensions in saying anything to customers.

If you don't want to say anything to customers, then the Guidelines are fine. But then, what is the point of certs?

The above is just about EV, but that's just a foil for the wider problem: no CA makes this easy, as yet. I believe it to be an important task for certificate authorities to come up with a simple claim that they can make to users. Something clear, something a user can take to court.

Indeed, it would be good for all CAs and all browsers to have their claims clearly presented to users, as the users are being told that there is a benefit. To them. Frequently, for years and years now. And now they are at risk, both of losing that benefit and because of that benefit.

What is that benefit? Can you show it? Can you state it? Can you present it to your grandma? And, will you stand behind her, in court, and explain it to the judge?

Posted by iang at October 6, 2008 05:27 AM | TrackBack
Comments

My oft repeated comments were that we had signoff on the webserver to payment gateway ... but we couldn't dictate the webserver to browser .... and almost immediately, merchants found that SSL cut webserver thruput 85-95% and so they dropped back to just using SSL with a payment/checkout button.

so the latest in this

Google's Obfuscated TCP
http://it.slashdot.org/it/08/10/08/0025258.shtml
Obfuscated TCP
http://code.google.com/p/obstcp/

However, SSL was to address two issues

1) validating that the website you think you are talking to, is the website you are talking to

2) hide information

The big problem with conditioning endusers to clicking on buttons from unvalidated sources ... is the validating part is broken.

SSL required the end user understand the relationship between the webserver they thought they were talking to and the corresponding URL ... and then the browser SSL code provided the assurance between the URL and webserver they were talking to. With the checkout/pay paradigm button clicking (provided from a non-SSL validated source), the paradigm degenerated to the webserver is whatever webserver that it claimed to be (since an unvalidated source was providing the URL, not the enduser from validated source).

recent related threads:
http://www.garlic.com/~lynn/2008n.html#96 Wachovia Bank web site
http://www.garlic.com/~lynn/2008n.html#100 Wachovia Bank web site
http://www.garlic.com/~lynn/2008o.html#4 Wachovia Bank web site
http://www.garlic.com/~lynn/2008.html#9 Homebanking authentication methods

Posted by: Lynn Wheeler at October 8, 2008 10:29 AM

The obvious Barefruit attack can be extended to a more subtle attack. When Barefruit pretends to be a subdomain it breaks the browser cookie security model, enabling malicious content distributed by a compromised Barefruit to set cookies for the parent domain, thus enabling cross-site request forgery attacks to penetrate the "value in form element must match value in cookie" defense. Indeed, most web security depends on cookies and therefore on browser cookie rules, which depend in turn on DNS results. Barefruit and all the other MITM advertising servers deliberately break DNS, break the cookie security rules as a side effect, and break website security in consequence.

Posted by: Mark Seecof at October 9, 2008 02:47 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.