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...

30 Responses to “More HTTPS Troubles”

  1. #1 Matt says:

    Would that NoScript feature protect against the issue on slide 92? They use a subdomain with unicode slashes and a wildcard certificate...

    https://www.gmail.com/accounts/ServiceLogin?!f.ijjk.cn

    In that case, the user would be pulling insecure GMail (or paypal/etc) data through another domain.

    I don't even know how a website could begin to protect against that trick, short of using javascript to check its own location.domain property.

  2. #2 CapnCanuck says:

    Something is phishy..
    After first looking at the pdf then your solution, we are missing something. Forcing sites to use a https connection doesn't necessarily mean that the https connection is legit. right?

  3. #3 NM says:

    The URL bar should display the domain name part in a different style than the path part; wasn't there such a proposal before FF 3.0?

  4. #4 Cal-O-Ne says:

    @NM: It was already implemented in an pre-beta build of FF 3, but later on taken out.

  5. #5 Giorgio says:

    @Matt:
    No, the "force HTTPS" thing can't obviously protect you from the homograph trick, and the target site can't protect itself either.
    However the most important anti-phishing rule that all the half-educated users are taught is "never go to your online banking site by following a link", i.e. either use a bookmark or type "www.bankofamerica.com" on the location bar.
    All the first (and most interesting) part of this attack is meant to hijack the address user initially entered on its own (doing his best to protect himself from phishing) and redirect it to the fake homograph.
    This is the preliminary part that forcing HTTPS on your "sensible" sites defeats.

    @CapnCanuck:

    Forcing sites to use a https connection doesn’t necessarily mean that the https connection is legit. right?

    It does if you're the one who typed (or bookmarked) the site (see my answer to Matt), unless the certificate itself has been cloned (but that would be a different story).

    @NM:
    Yes, you're right. It was dropped but now will probably be reevaluated.

  6. #6 CapnCanuck says:

    lol cool thx ma1
    i forgot that i was using Perspectives already ;P.

    At the same Blackhat conference, Kaminsky was talking about DSL vulnerabilities, etc.
    I know that a bandage solution to this would be to use OpenDNS instead of ur ISP's DNS, but i know that this wouldnt last. Whats your take on this?

  7. #7 Ian M says:

    Is that feature in NoScript the same as the HTTPS-only cookies that Google implemented a few months ago for GMail?

  8. #8 Giorgio says:

    @CapnCanuck:

    I know that a bandage solution to this would be to use OpenDNS instead of ur ISP’s DNS, but i know that this wouldnt last. Whats your take on this?

    Of course "the" solution would be every DNS around the world being upgraded to a secure version of the protocol implementation.
    Users have basically two options: either switch to OpenDNS (easiest) or, if you've got the skills and the need, deploy your own djbdns instance.

    @Ian M:

    Is that feature in NoScript the same as the HTTPS-only cookies that Google implemented a few months ago for GMail?

    No, that one is more related to NoScript Options|Advanced|HTTPS|Cookies. The "force HTTPS" thing is orthogonal to secure cookie management, making it more effective.

  9. #9 Basti says:

    As I read about the attack before they was presented I thought it would be a big thing. A man-in-the-middle attack with bypassed SSL. Now I see that this isn't such a big thing... the communication is not encrypted. The user thinks https is used but it's not.

    Don't get me wrong... This is still an attack that is extremely effective, but not for every situation. On highly secured websites or if the service uses confidential information the user will look for signs that indicate that everything is fine. The certificate for example.

    The Favicon thing is nice, but the lock in the statusbar isn't shown.

    There are some addons that
    - make the addressbar yellow again (FF3) or any other color.
    - show a certificate in the addressbar and in statusbar
    - maybe there are more useful things that let you notice a safe site (https)

    Directly accessing the https site also helps, because the attack can be performed on unencrypted sites. If you do not visit the unencrypted site to follow a link you can't be attacked.

    To say it again this is good work and really efficient if you want to steal some login-data for social-network sites, mail accounts and somehow even online-banking sites.

    It is really a bad time for internet safety... it needs to be a safer place... NoScript helps in this case and in many others too.

  10. #10 Giorgio says:

    @Basti:
    notice that the homograph trick is meant to offer you a "legitimate", "secured" and "encrypted" HTTPS site (albeit fake), where the favicon and other UI-related tricks are unneeded.
    The slides are a bit confusing because they propose different techniques which can either be combined or used alternatively.

  11. #11 Funtomas says:

    Just set network.IDN.Whitelist.cn to false and network.IDN.showpunnycode to true. Hope, it'll help.

  12. #12 Tom T. says:

    Giorgio, please correct the spelling of "Wachovia" in your article, as one common phishing method is to offer a very close misspelling that the user doesn't notice. Thanks!

    Question: I already use a Hosts file to block evil sites. It's my understanding that the browser looks in the local machine Hosts file before doing any dns lookups, correct? If so, then if I add the known (correct) IPs of my bank logins, etc., to the Hosts file, wouldn't that defeat this attack entirely? (assuming the hosts is not corrupted, which is another issue altogether)

  13. #13 Giorgio says:

    @Fantomas:
    Updated my post, thanks for the hint. Your countermeasure is very important to have until the IDN character blacklist is updated by Mozilla. Sadly, though, it's not enough to defeat the whole attack: the 254 passwords have been harvested without the homograph trick.

    @Tom T.
    Sorry, DNS hijacking is not the only way to control your non-HTTPS destination.
    Hostile networks (a corporate proxy, a public WI-FI hotspot, a corrupted ISP, TOR...) can rewrite your unencrypted traffic on the fly, even if end-point hosts are not compromised and the domain name translation is correct.

  14. #14 Tom T. says:

    @Giorgio: Thanks for the reply. I made the suggested changes, went to an insecure bank site, and magically, the exact same site was delivered, but this time, secured! Kudos!

    However, please go to www.wachovia.com. You will indeed be changed to the https equivalent, but with the warning message (assuming you have this message enabled), "You have requested an encrypted page that contains some unencrypted information (etc.)". Will the unencrypted information on the page defeat the purpose of your countermeasure?

    Strictly an academic question, because if I were a Wachovia customer, I would always log in at https://onlineservices.wachovia.com/auth/AuthService?action=presentLogin&url=https%3a//onlineservices.wachovia.com/NASApp/NavApp/Titanium%3faction=returnHome , which is indeed secure. But it would be good to know about "mixed" pages.

    p. s. Maybe you, or someone else with some standing, can convince these stupid banks to upgrade from RC4-128 to AES-256?

  15. #15 Giorgio says:

    @Tom T.:
    Wachovia imports some CSS files and images from Akamai over hardcoded HTTP.
    This can't be exploited for this specific attack (not in Firefox at least), but could be exploited by a man-in-the-middle to read your credentials as you type them, using a technique developed by my friend Sirdarckcat (it's much easier on IE, though).
    Unluckily at this moment NoScript doesn't force HTTPS on non-document requests (such as stylesheets or images), but it will do it soon. At that point, you'll just need to add *.akamai.net to your "force HTTPS" list.

  16. #16 Tom T. says:

    Excellent, will be looking forward to that announcement. Off-topic: I've wanted to donate for a long time, but despise PayPal for its many insecurities and privacy violations. I can get an international draft in euros from my bank. Would you like it sent to informaction address on that page, or somewhere else? Or do you have a U.S. bank account, which I would greatly recommend -- increase your donations by making it easier for US-ians!

    btw, instead of typing www.bankofamerica.com, you can save nine keystrokes with www.bofa.com. :-)

  17. #17 Basti says:

    @Giorgio: The homograph trick is the worst thing. That is a "good" way to fool the user without having negative impact. This bad thing is so good if you are a bad guy. It's seems so effective.

    Use a filter-addon that is used for childs. Most use a white-list no one can view sites that are not listed there. Very uncomfortable, but safe. Or even safer do not visit any site ;)

  18. #18 Aerik says:

    Can we use wildcards in the force https feature, or was that just for emphasis on this blog post?

  19. #19 Giorgio says:

    @Aerik:
    You can use literals, glob wildcards and even regular expressions.

  20. #20 Aerik says:

    Oh here's something I do. When I'm going to use a site that uses sensitive data, I use the extension BlockSite, put it in white list mode, and only accept the exact page ranges I want to visit. Else users could use blocksite in blacklist mode and blacklist all .cn domains or something.

  21. #21 Giorgio says:

    @Aerik:
    sound like a smart strategy.
    It will be made much less painful by ABE.

  22. #22 Aerik says:

    I do think it's smart strategy, because I was toying with blocksite in whitelist mode when I discovered something very interesting.

    I use the extension "twittytunes" to post to twitter. A very simple interface. What's interesting is that in whitelist mode, blocksite will cut off this extension's connectivity to twitter if I do not whitelist http://twitter.com/* . Even ReqestPolicy isn't that powerful.

    This means (I think): blocksite in whitelist mover overcomes Bug 431782 "HTTP redirects can bypass content policies."

  23. #23 Steven Andrés says:

    @NM: I think the Firefox feature you're talking about is one of my favorites and one that I really wish was a default:

    http://kb.mozillazine.org/Browser.identity.ssl_domain_display

    I have mine set to level "2" which shows the entire CN of the certificate in the address bar in blue. It's a really big attention-getter and looks almost as in-your-face as the Extended Validation green-bar UI. I try to flip this setting on all my friends/family/users Firefox installs so they have a strong visual feedback of non-EV certificates and hopefully would be able to catch on to an attack.

  24. #24 Tom T. says:

    Loophole: if you are lazy and type wachovia.com, the suggested changes will not work. Normally, your browser would add the www prefix when the shortened URL doesn't work; however, wachovia and one of my local credit unions are configured so that typing without the www still takes you to the same (unencrypted) login page. Solution: add to the "Force HTTPS" list the following, without wildcards: http://wachovia.com or any other site that shows this behavior when www. is not typed. Or don't be lazy, and type the www. Or bookmark it. Or even better, put the correct URL in Password Safe, free and open-source from Bruce Schneier www.schneier.com/passafe.html.

  25. #25 SSLStrip pone las fallas de SSL al descubierto « says:

    [...] REFERENCIA: hackademix.net [...]

  26. #26 Paul says:

    It seems to be that anywhere offering a secure site should _only_ offer https services.
    Users won't be so exposed to this if they only have https urls in their bookmarks/history/autocomplete. The window of exposure is reduced to the first time they type in the addresses.
    It may not be feasible to drop http completely for sites used by the general public (but may be in many cases for private applications).
    In that case the http site could do nothing but issue a redirect permanent to the https site. That would make bookmarks secure and possibly (depending on browser behaviour) history/autocomplete safer.

    I suppose some sites will be navigated to via weblinks rather than accessed directly as above so it's not a total solution, but that is probably true of the problem in general, it's one you can minimise your exposure too rather than magically fix for all situations.

  27. #27 CapnCanuck says:

    @ Paul: Thats a great idea, there shouldnt be any reason for secure sites to only operate on the HTTPS protocol. But from my understanding, https is an extension of http, so therefore you cant have https without http..i think

  28. #28 Aerik says:

    Good suggestion Paul.

    If you don't need a www in a domain then eliminate it.

    I suggest incorporating this into your use of BlockSite.

    Know what else I do on sensitive sites? I put network.http.redirection-limit to 0, or at most 1. I think the default value for this preference should be 1 anyways. That's generally all that's ever necessary on sites that use a redirect to serve content of some kind, or on forums that redirect you to your post in the thread after you post a reply. The current default, 20, is ridiculous.

    Finally, it's a good idea to open noscript's options and set "forbid active web content unless it comes from a secure (HTTPS) connection:" to "always" when on a sensitive site.

    And set noscript.forbidXHR to 3 except when it absolutely must be lowered.

    Then do your sensitive stuff in private browsing mode.

    In fact you should probably create an entire firefox profile just for doing this sort of stuff, with all these suggestions employed.

  29. #29 AndrewM says:

    An update: Bug 479336 (https://bugzilla.mozilla.org/show_bug.cgi?id=479336) added some more characters (including the one used in the example above) to the blacklisted IDN characters in network.IDN.blacklist_chars (full list: http://kb.mozillazine.org/Network.IDN.blacklist_chars). So a fix for this should be in Firefox 3.0.9.

    I was also impressed to see that IE8 and Chrome 1.0.154.53 are already protected against this.

    Also, the link to Password Safe in comment 24 needs an extra 's' in it, so it's:

    http://www.schneier.com/passsafe.html

  30. #30 SSLStrip pone las fallas de SSL al descubierto | Geekotic says:

    [...] Hackademix.net, sitio del autor de la extensión NoScript para Firefox, donde explica además como usarla para protegerse de estos exploits. [...]

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