fscked.org

This past weekend I gave a talk at DEFCON 16 describing a very common vulnerability with many SSL-secured websites (slides are here). It actually all started last year when I began development on The Torbutton Firefox Extension and agreed to speak at Black Hat USA 2007 and DEFCON 15 on my findings with respect to Tor Security. In that talk, I announced that many sites used over Tor were not setting the 'Encrypted Sessions Only' bit on cookies they set over https. This is the case with GMail, addons.mozilla.org, most Drupal sites, Facebook, Amazon's purchase history, Yahoo mail, Hotmail/MSN, many many online merchants, and a few of my friends' banks.

It turns out an adversary able to position themselves in between you and a website is able to inject arbitrary http-based content elements for domains that do not set the 'Encrypted Sessions Only' property of their cookies, and thus cause your client to transmit these cookies via clear text, intercept them, and impersonate you. The important thing to note is that they can do this when you visit ANY website. You do not ever have to leave SSL for the vulnerable site.

I described this attack in detail in a post to BugTraq and notified Google a year ago, but unfortunately, my announcement was largely overshadowed by Robert Graham's 'SideJacking' demonstration at Black Hat. His tool was simply a sniffer that just gathered cookies for sites as users on the local network visited them. The attack I described was much more flexible, much more powerful, and just as automated, but without a tool and a demonstration to back up my claims, nobody listened.

How an Automated HTTPS Cookie Hijacking is Performed

This attack can happen via a number of mechanisms, including via the local wired or wireless network, via Dan Kaminsky's DNS hijack attack, via the Tor network, or via the cable modem network (though this would require a custom modem). The steps are as follows:

1. Cache all DNS responses on the network to obtain a mapping of what host name clients are resolving, so you know the host they are using for server IPs.

2. When a client IP connects to a server IP using https (port 443), look up what hostname they resolved in the DNS cache to get this IP.

3. Add this domain as a target for that client IP.

4. When that IP then connects to ANY http website, look up what targets it has accumulated, and optionally add on a list of custom targets for completely insecure sites such as mail.yahoo.com and mail.live.com. Inject images for each of these into that TCP connection.

5. When the browser fetches these images, it will transmit any insecure cookies for that domain and path. Record the resulting cookies (and any others we happen to see while we're at it) to a Firefox-compatible cookies file.

The key property to notice here is that the tool automatically targets ALL insecure sites, not just Gmail. It does not require configuration for the common case. This means you do not get to hide behind obscurity! Just because no one has heard of your dinky little SSL site does not mean you are secure if your cookies are not set to be.

Furthermore, the additional optional list of completely insecure sites to always hijack (even if their users never visit them during the attack session) means that popular sites that completely refuse to implement SSL are now incentivized to do so.

It is for both these reasons that I have opted to wait another two weeks after my talk before releasing this tool, because I figured these facts would take the longest to sink in. It is possible to cobble together a tool that targets specific sites in a couple hours or maybe a weekend (depending on how well you leverage existing tools, and how extensible the result is). In fact, a site-specific tool has already been released by Enable Security.

However, doing the additional work to fully automate the process is probably another weekend or two worth of work, and its work that would be done in secret without people realizing the seriousness of the vulnerability. In fact, despite it taking a year for me to grow impatient enough to opt for a full disclosure shitstorm, coding the tool itself only took 2-3 weekends of my time and about one of Damon McCoy's (who helped make sure it didn't break on his more exotic and heterogeneous wireless test lab network).

How to Tell if Your Sites are Secure

Since so many sites are likely vulnerable, the actual reporting process is probably going to fall on the shoulders of users. To check your sites under Firefox, go to the Privacy tab in the Preferences window, and click on "Show Cookies". For a given site, inspect the individual cookies for the top level name of the site, and any subdomain names, and if any have "Send For: Encrypted connections only", delete them. Then try to visit your site again. If it still allows you in, the site is insecure and your session can be stolen. You should report this to the site maintainer.

Note that some sites do janky things like requiring a random Session ID in the URL, referrer information to be correct, or hidden form elements to be present during navigation. This may end up preventing the above simple test from allowing you in, despite having insecure cookies.

These approaches may or may not be secure, depending upon how they implemented it (and why), and really should be considered a "worst practices" sort of thing for protection for this particular attack. For instance, the randomized session ID in the URL may have been specifically designed to protect against CSRF attacks, with no thought whatsoever put into the fact that it can be transmitted on the local network in the 'referrer' string as soon as you navigate to an insecure page (ie, the "about", "routing info", and "help" links of many banks are http, not to mention off site links they might provide).

Because of this, is probably best to contact these sites anyway, since hacks like these are homebrew solutions (and potentially designed to defend against completely different attacks) and are much more likely to be failure prone than the tried and tested existing browser security model.