COMMAND
IIS
SYSTEMS AFFECTED
IIS 4, 5
PROBLEM
Following is based on a ACROS Security Problem Report
#2000-07-22-1-PUB. This 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, ACROS has identified a weakness in Microsoft's IIS.
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. 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.
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].
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). ACROS is confident that
competent system developers will be able to extrapolate our
findings to their systems in such cases and act accordingly.
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, A. 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. ACROS has also written another script
(cookies.asp), which displays the contents of all cookies sent by
the browser.
Then they 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.
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 <img> 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 <img> 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:
<html>
<head>
<meta http-equiv="refresh" content="1; URL=index.html">
</head>
<body background="http://www.sensitive.com/image.gif">
</body>
</html>
What this document does is (1) try to load "image.gif" from server
"www.sensitive.com" over unencrypted HTTP protocol (thus
transmitting session ID cookie for this server in cleartext) and
(2) reload the page after one second. This (second) time, the
attacker lets the real "www.yahoo.com" server answer the request
so that the user gets what he requested (user friendliness above
all. Meanwhile, by sniffing the network traffic, the attacker has
retrieved the user's session ID cookie for the current session.
Note: The file "image.gif" doesn't need to exist on
"www.sensitive.com".
Note: If the "www.sensitive.com" server doesn't have port 80
(HTTP) open, the attacker can make a fake response on its
behalf, convincing the browser that the port is open.
By knowing the user's session ID cookie, the attacker can hijack
his current session, assuming his identity.
SOLUTION
Users of web browsers can destroy session ID cookies by closing
all instances of their browsers immediately after logging out of
critical web-based systems - that's before accessing any other web
site. Also, between logging in and logging out of such system,
they shouldn't visit any other web site - not even web sites they
trust. Basically, for connecting to critical web-based systems,
every user should:
1) Close all instances of the browser (if there are any) to
prevent possible JavaScript attacks
2) Launch the browser
3) Log in to the system
4) Use the system
5) Log out of the system
6) Close all instances of the browser (to delete session
cookies)
The above procedure could also protect users from various other
vulnerabilities inherent to web-based systems and should in our
opinion be used as a "best practice".
The original version of patches for IIS 4.0 Alpha and the IIS 5.0
systems did not install correctly. The IIS 4.0 x86 version of the
patch does install correctly.
Patch availability:
- IIS 4.0: x86 platforms: http://www.microsoft.com/ntserver/nts/downloads/critical/q274149
Alpha platforms: Available from Microsoft Product Support Services
- IIS 5.0: http://www.microsoft.com/Windows2000/downloads/critical/q274149
Note: The patch installs support for secure Session ID cookies,
but does not enable it for reasons of application compatibility.
As discussed in the Knowledge Base article, it can be enabled or
disabled on a site-by-site basis.
The IIS 4.0 version of this patch can be installed on Windows NT
4.0 systems running Service Pack 6a, and will be included in
Service Pack 7.
The IIS 5.0 version of this patch can be installed on Windows
2000 systems with or without Service Pack 1, and will be included
in Service Pack 2.