the other IE cookie stealing bug (MS01-055)

[Marc Slemko <marcs () znep com>]

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/bulletin/MS01-055.asp
   7. http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/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