Overview of Web MITM Vulnerabilities

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.

Note that this active attacker can also do things like inject Javascript into a page to do nasty things like download an entire inbox and send it somewhere, or perform arbitrary actions on behalf of the user.

I have a feeling there will be several sites that attempt custom hacks such as ActiveX controls or hidden form fields that can cause regular cookie hijacking to fail, allowing them to appear secure, when in fact they are not. To deter these types of security theater "fixes", I will be adding the ability to inject arbitrary Javascript for a list of sites to the CookieMonster in the near future.

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.

Update: 9/19/2008

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.

Referer not sent on HTTPS->HTTP transition

Thanks for your work identifying and explaining these vulnerabilities!

Regarding the example scenario with Referer: headers in Vulnerability 3:

I'm under the impression that browsers don't send a Referer header when transitioning from HTTPS to HTTP. In other words, suppose I've loaded a page over HTTPS, and that page includes a link to a "http:..." URL, and I click on that link. I had the impression that browsers will not send a Referer header in that case. Is that correct?

I had the impression that the Referer header is only sent for HTTPS->HTTPS links. If I load a page over HTTPS, and it includes a link to a "https:..." URL, and I click on that link, then my impression is that the browser will send a Referer: header in this case, even if the link is to a different domain than where the page came from. But this only applies in case the originating page and the destination page both use HTTPS. In this case the Referer: header will be sent over the SSL channel, and so normally would not be visible to eavesdroppers, but it would be visible to the linked-to site.

Did I get that right?

It sounds like you are saying Vulnerability 3 could be exploited by eavesdroppers with no other special access. Based on the above, I don't see how that would work. Can you explain?

I have a suspicion that I've probably misunderstood something. Where did I go wrong?

does this only apply to open networks?

For the passive attack in Vulnerability 1 do you assume that clients are connected to an open network (i.e., connected to a base station with no security)? Otherwise, how can they eavesdrop on the cookies, even if they are sent in the clear?

Re: does this only apply to open networks?

No. While CookieMonster as currently written only targets open and WEPed wireless networks (WEP keys can be cracked in minutes nowadays, btw), this vulnerability can be exploited via a number of different vectors. On the local wired network, you have ARP poisoning. On the Internet at large, for a while there you had Dan's DNS exploit, and you still have issues with BGP hijacking, and just general issues with unpatched core and consumer routers. On your local cable modem/DSL network, an attacker with a custom cable modem can potentially inject packets as well with custom hardware.

So no, it's not really just open wifi. That's just the easiest vector you can use to impress girls.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options

This question is for testing whether you are a human visitor and to prevent automated spam submissions.
 __        __  _   _      _     __     __  _     
\ \ / / | | | | / \ \ \ / / | |
\ \ /\ / / | |_| | / _ \ \ \ / / | |
\ V V / | _ | / ___ \ \ V / | |___
\_/\_/ |_| |_| /_/ \_\ \_/ |_____|
Enter the code depicted in ASCII art style.