Archive for February 19th, 2009

As we already noticed, 2008 had not been a great year for Internet Security, and especially for SSL and HTTPS. Today, web sites relying upon encryption and certified identity got another blow: at the Black Hat DC 2009 conference, independent researcher Moxie Marlinspike demonstrated how to defeat HTTPS, successfully impersonating a "secured" site over a proxied, public or otherwise hostile network.

The proposed attack, performed with a tool called "sslstrip”, is very interesting and clever, involving forced redirections, "secure UI" simulation and a smart homograph trick which makes the final attacker-controlled page look identical and as secure as the original, so I strongly recommend to take a look at these slides.

The danger is far from being theoretical:

To prove his point, he [Marlinspike] ran sslstrip on a server hosting a Tor anonymous browsing network. During a 24-hour period, he harvested 254 passwords from users visiting sites including Yahoo, Gmail, Ticketmaster, PayPal, and LinkedIn. The users were fooled even though SSLstrip wasn't using the proxy feature that tricks them into believing they were at a secure site. Sadly, the Tor users entered passwords even though the addresses in their address bars didn't display the crucial "https."

Browser vendors are already trying to figure out ways to mitigate this scary stuff, especially the homograph stunt which shows you a "secure" page from an address (as displayed on the location bar) like https://www.paypal.com╱login╱abcdef.g54321.cn: this definitely appears to be a legitimate Paypal login page, but is really an evil phishing bait from the

g54321.cn

Chinese domain. The "╱" character is not a true slash, but a different unicode character looking like (i.e. homograph of) a slash and valid as an IDN subdomain part.

However, for the full attack to succeed, the target site must allow its entry point (e.g. the home page or the login box) to be initially served over HTTP (not encrypted), even if it correctly exchanges login credentials and other sensitive data over HTTPS (encrypted). Unfortunately, this is too much a common scenario (as the 254 password collected in 24 hours testify): various Google services, social networks, financial institutions like Bank Of America, Wachovia and even my own bank (Fineco), all do suffer of this flaw.

Good news: once again "unexpectedly", a NoScript feature can protect you, if correctly configured:

  1. Open NoScript Options|Advanced|HTTPS|Behavior.
  2. Locate the text area labeled "Force the following sites to use secure (HTTPS) connections" and add there the sites you want to protect, space separated. For instance twitter.com *.wachovia.com *.bankofamerica.com *.paypal.com and so on.
  3. ...
  4. Profit... loss, for the cybercrooks! :)

Update

As commenter Fantomas hinted, you can deploy a band-aid countermeasure against the homograph exploit by forcing Firefox to always show punycode for IDN address. If you do so, the https://www.paypal.com╱login╱abcdef.g54321.cn address will be displayed in your location bar as https://www.paypal.xn--comloginabcdef-d29if.g54321.cn/, which is obviously much less effective as a disguise. Of course this was just the "final touch", albeit impressive, of this multi-faceted attack: in facts, the 254 passwords have been harvested without this trick! So be sure you configure force HTTPS as well, and always type your sensitive addresses or, much better, use bookmarks...

Bad Behavior has blocked 951 access attempts in the last 7 days.