Cookies are often used to identify and authenticate users to a website. If an attacker can steal a user's cookies, then they can impersonate that user. The completeness of the impersonation and the actions the attacker can perform as that user depend on how the particular site uses the cookies.
This bug in Internet Explorer allows an attacker to, if he can convince the user's browser to load a given URL, steal their cookies for any given domain. It does not require that active scripting is enabled in the browser, and can be done with something as simple as an image tag, allowing for hassle free use in HTML email, web based email services, etc.
I discovered another bug a year or so ago in IE, that has since been patched, that has similar implications, although it did require active scripting to exploit. Someone else discovered a similar bug around the same time that the bug described in this document was discovered. I would not be at all surprised if other bugs of this nature were found in the future. When I discovered this bug, I decided to sit down and look for a bug of this nature, and it only took me 15 minutes of experimentation to find it. Why didn't Microsoft pro-actively audit their code for such things, especially after similar bugs were found in the past?
The take-away message is that cookies can be stolen. It is critical that any application that depends on cookies does so with an understanding of this fact, and takes appropriate measures to limit the damage that can be done using stolen cookies.
Cookies are the mechanism used by most websites to identify and authenticate a user. If you can steal someone's cookies, you can trick the server into thinking you are them. Exactly what this gains you depends on the application and how it is designed. It may gain you very little, or it may gain you a whole lot (eg. Microsoft Passport to Trouble). For more information about cookies, see The Unofficial Cookie FAQ.
Cookies are set with a specific hostname or a domain, so that they are only sent to that host or domain, with an exception or two that I won't go into here. They can also be set with a specific path, or with the secure flag, which means they will only be sent if the connection is a SSL connection. Normally, this should mean that only the server that set the cookie, or others it is operating in cooperation with (eg. in the same domain) can read it.
Internet Explorer has a bug that lets you bypass this protection and steal cookies for any domain. This is quite similar (although different behind the scenes) to a bug I found about a year ago, hence the "#2".
The details are very trivial. Why am I writing up this big document
anyway? Hmm. Loading a URL such as:
http://passport.com%20.sub.znep.com/cgi-bin/cookies
...will cause IE to connect to the hostname specified, but send the cookies to the server based on the hostname before the "%20", in this case passport.com. The "%20" is the URL encoded version of a space character. "%20" isn't the only character that works, there are a variety of others that are also misparsed.
For this to work, the hostname "passport.com .1005795014.sub.znep.com" must be resolvable as a hostname by the client. In this case, I did this by creating a wildcard A record for *.sub.znep.com, so any hostname under sub.znep.com will get resolved to a particular IP address. This attack does require that the attacker have access to configure a DNS server in such a way, however gaining such access anonymously or pseudo-anonymously is trivial.
Also note that this exploit will not work from behind some or most proxies, since it results in IE generating a malformed request that any HTTP server should feel free to reject. Some versions of Apache will also reject requests when used as the cookie-stealing server due to the malformed Host: header that gets generated. And, last but not least, this attack does not appear to work to steal cookies with the secure flag set.
An example exploit is
available. Very straightforward. The numerical part of the
URL is not a critical part of the exploit, it is there only to
introduce some variance into the URL to avoid some odd caching
issues that pop up sometimes.