|Submitted by mikeperry on Fri, 09/12/2008 - 03:29|
I've realized that the fact that I'm still getting questions to the effect of "How does this attack differ from Robert Graham's 'Sidejacking' attack?" means I did not do a very good job of classifying what sorts of vulnerabilities a Man In The Middle attacker can exploit over the web, especially with respect to what CookieMonster does that other tools do not (or at least do not automate). This post is an attempt to clarify the situation, and describe the two main classes of cookie stealing Man In The Middle vulnerabilities that popular websites are vulnerable to, depending on their security properties.
Vulnerability 1: No HTTPS Past Login Page/No HTTPS at All
This is the first and most basic vulnerability. Performing HTTPS only upon login is what is known as security theater - providing the illusion of security to a user without actually securing them at all.
All of these sites are vulnerable to exploitation by simple network monitoring tools such as Wireshark, and more tailored tools such as Robert Graham's Hamster, which has been available for over a year now. These tools allow an attacker to grab the authentication cookies used for a user's website session, which are typically all that is needed to impersonate the user. These tools perform what are known as passive attacks, because the attacker is not actively modifying network traffic, only passively monitoring it for interesting data to come along.
With just a little more effort though, an attacker can become substantially more dangerous to these sites. For instance, part of the core logic of CookieMonster is to actively inject images for a list of sites, which cause browsers to transmit their authentication cookies for these sites, and thus allow the attacker to cull cookies from every IP on the network.
Vulnerability 2: HTTPS but Insecure Cookies
This is the vulnerability I announced in my Bugtraq post last year, and the one I featured in my DEFCON talk. Basically, it revolves around the fact that cookies have two modes: secure and insecure. If a cookie is insecure, a browser will transmit it for plain old http connections, and an active attacker can then inject a set of http images for sites that they want cookies for, and the browser will happily transmit cookies for these sites unencrypted, allowing their capture. This attack can even be automated for the majority of sites without the need for a list of targets (though a list of targets can also work just fine against these sites as well, to capture their cookies for every IP on the network). I describe the automated process in both the core logic post, and the original writeup post of CookieMonster.
Removed third class of referrer-based Session ID grabbing attacks. It turns out referers are not transmitted from https->http link traversals, as David Wagner points out below. Woops. Can't win 'em all.