=====[BEGIN-ACROS-REPORT]=====
=========================================================================
ACROS Security Problem Report #2000-07-22-1-PUB
-------------------------------------------------------------------------
Remote Retrieval Of IIS Session Cookies From Web Browsers
=========================================================================
PUBLIC REPORT
Affected System(s): Internet Information Server (all versions) and other
web servers using "unsecured" session ID cookies
Problem: Session ID cookies can be retrieved remotely from web
browsers
Severity: High (for critical systems only)
Solution: (see "Advisory" section)
Written: July 22, 2000
Last update: October 23, 2000
Published: October 23, 2000
SUMMARY
=======
Our team has analyzed how popular web browsers could be tricked to reveal the
session ID cookies and discovered a way how this can be done by a remote
attacker even when SSL is used to protect this data while in transfer over
insecure channels like Internet.
As a result, we have identified a weakness in Microsoft's Internet
Information Server. However, it *should not* be assumed that only this
product is affected but rather all vendors of web servers and HTTP session
management solutions are urged to review their products for the identified
vulnerabilities.
Note: We have put quite some effort into notifying these other vendors.
Unfortunately, we got very little response so we are unable to provide the
status of their products in this report.
The purpose of this report is to describe a security problem in IIS's session
management and also to provide a workable scenario for exploiting this, and
similar, vulnerabilities.
INTRODUCTION (same as in ASPR-2000-07-22-2)
============
So you have launched your new web-based e-banking system and protected it
with 128-bit SSL. Your users logon to it through their browsers, providing
their usernames and one-time passwords, then cryptographically strong random
session cookies are computed and sent to their browsers for session
authentication. Entire communication is protected with SSL so there's no way
anyone could intercept the sensitive cookies.
You feel safe; you trust SSL to do its job protecting your users and your
system. Their session ID cookies are secure.
Or are they?
We will show that it could be possible to retrieve the session cookies from
your user's web browser with little or no user's cooperation, even when due
care was taken to protect the communication between browser and server with
SSL. *
(*) We'll put all client scripting issues aside for the time (including
cross-site scripting, which is by the way very suitable for stealing
cookies). We'll also put all bugs in various SSL implementations aside and
assume SSL is working as specified.
SESSION ID COOKIES
==================
Most "stateful" web-based systems are using session ID cookies for
maintaining sessions. A session ID cookie is generated on the server in such
a manner that a potential attacker could not guess (or calculate) its value.
Usually (and preferably), strong cryptographic algorithms are used for this
purpose (BTW, several vulnerabilities have already been identified in various
session mechanisms as a result of not using them). Server only provides the
user with a session ID cookie when he has proved his identity (by providing
username and password, for example).
Cookies are generally transmitted between browser and server in plaintext in
HTTP headers. For protection against network sniffing and traffic
redirection, SSL is often deployed to encrypt and authenticate the
communication.
Note: While it is generally clear that username:password pairs are indeed
authentication data and therefore sensitive, it is many times not clear that
session ID cookies are also frequently used for authentication. Numerous
web-based financial systems we have seen are using some (stronger) form
of authentication for initial login (like one-time passwords or SSL client
certificates), while throughout the session they rely entirely on users'
presentation of correct session ID cookies. Obviously, for the attacker,
stealing such a cookie would mean a successful takeover of user's identity.
Hence the notion that in critical systems, session ID cookies are just as
sensitive as passwords (effectively they are equivalent to username:password
pairs).
Note: There may be other kinds of sensitive data contained in cookies (e.g.
credit card data). We are confident that competent system developers will be
able to extrapolate our findings to their systems in such cases and act
accordingly.
ANALYSIS
========
Throughout the analysis it is assumed that the attacker is capable of the
following:
1) Listening to network traffic between client and server
2) Generating fake (spoofed) network traffic between client and server
Note: These assumptions are only a part of the assumptions stated in
the SSL Specification. SSL was developed for the purpose of protecting
against this (and much stronger) type of attacker.
For this analysis, we have set up IIS 5 web server (www.test.com), installed
a valid SSL key+certificate and written a script (login.asp) that sets a
(native IIS) "session ID cookie" when accessed by browser. We have also
written another script (cookies.asp), which displays the contents of all
cookies sent by the browser.
Then we opened a browser, typed "https://www.test.com/login.asp" which
executed the script login.asp and our browser was "marked" with the session
ID cookie. The cookie was sent between client and server over an encrypted
SSL connection, preventing anyone listening from intercepting them.
Then, by opening the page "http://www.test.com/variables.asp" (no SSL here!)
we could observe session ID cookie being transmitted to the server over an
unencrypted link, thus making it interceptable for a network listening
attacker.
The conclusion is that even though a session cookie was sent to the browser
over an encrypted connection (and would be normally - in a real-life system -
sent back to the server over an encrypted connection too), it is also sent to
the same server over an unencrypted connection if the browser establishes
one. While normally, the browser wouldn't establish such a connection (except
in a badly designed web application), this opens an opportunity for the
attacker to *make* any user's browser do so.
EXPLOITATION (same as in ASPR-2000-07-22-2)
============
For the purpose of exploitation, there are at least two ways of making the
user's browser connect to an arbitrary URL:
Malicious E-mail Technique
--------------------------
The first one is (very popular in examples) sending the user a "malicious"
e-mail message including a hyperlink to the attacker's web page, which
contains a hidden tag opening an unencrypted connection to the affected
web-based system. When the user clicks on the link in the attacker's e-mail
message, the attacker's web page is opened in the browser and the
tag
causes the browser to send its session ID cookie to the critical web-based
system, over an unencrypted channel.
But surely, a serious attacker can't go relying on the user clicking a link
in his e-mail message while his browser still holds the session ID cookie.
He needs a more effective technique.
Active Network Technique
------------------------
This technique assumes the attacker has the ability to both listen to and
generate fake (spoofed) network traffic between browser and server.
We will assume a web-based system at "https://www.sensitive.com" using
session ID cookies for session authentication.
Phase 1: The HTTPS waiting phase
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
First, the attacker listens to the communication between the user (his
browser) and server to determine when the user connects to www.sensitive.com
on port 443 (HTTPS port). This is an indication that the user has started a
session on the sensitive server. After some amount of data is exchanged
between the two (due to encryption the attacker can't observe much more than
the amount of exchanged data), attacker can assume that the user has
successfully authenticated to the server and his browser has received the
session ID cookie.
Note: Actually, network traffic analysis can give pretty reliable hints
whether the HTTP authentication was successful or not, especially when the
attacker had the ability to observe a controlled session beforehand and learn
the sizes of various server's responses.
Phase 2: The HTTP waiting phase
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After the "HTTPS waiting phase" is over, the user's browser has the session
ID cookie in its memory.
Now, what the attacker would like to see is the user's browser connecting to
www.sensitive.com over (unencrypted) HTTP protocol on port 80. To force that,
he waits for the browser to send a HTTP request to ANY server, for example
"http://www.yahoo.com/index.html".
Phase 3: Cached authentication data retrieval
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When this happens, the attacker sends a fake response from "www.yahoo.com"
to the browser, containing the following document: