=====[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:











" target="_new">http://www.sensitive.com/image.gif">







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.





Identity theft

--------------



By knowing the user's session ID cookie, the attacker can hijack his current

session, assuming his identity.





ADVISORY

========



Microsoft has issued a patch for IIS, available at:



http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25233 (IIS 4.0)

http://www.microsoft.com/Downloads/Release.asp?ReleaseID=25232 (IIS 5.0)



This patch makes it possible for IIS to mark its session cookies as "secure"

thus preventing them from being sent over unencrypted connections.

Administrators of IIS-based critical systems (e.g. web-banking) are advised

to install the patch and configure the appropriate registry options

accordingly.





It is important to note that our limited testing only covered one web server.

There are many other web servers and various session management server

add-ons that could be potentially affected by the identified vulnerability.





WORKAROUND

==========



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".





TESTED SYSTEMS

==============



Tests were performed on:



Internet Information Server 3.0 - not tested, but its session ID generation

                                  is so weak that it is definitely not usable

                                  for critical systems even if it's not

                                  affected

Internet Information Server 4.0 - affected

Internet Information Services 5.0 - affected





It is important to note that both Internet Explorer and Netscape

Communicator *refuse* to send cookies that are marked as "secure" over

unencrypted connection - which is a good thing and in our opinion the correct

behavior even though RCF 2109 is not sufficiently specific about it. We

haven't tested other browsers but have notified their vendors.





ACKNOWLEDGMENTS

===============



We would like to acknowledge Microsoft Security Response Center for prompt

and professional response to our notification of the identified

vulnerability.





SUPPORT

=======



For further details about this issue please contact:



Mr. Mitja Kolsek



ACROS, d.o.o.

Stantetova 4

SI - 2000 Maribor, Slovenia



phone: +386 41 720 908

e-mail: mitja.kolsek@acros.si

web: http://www.acros.si



PGP Key available at PGP.COM's key server.

PGP Fingerprint: A655 F61C 5103 F561  6D30 AAB2 2DD1 562A





DISTRIBUTION

============



This report was sent to:



- ACROS client mailing list

- ASPR Mailing List (see http://www.acros.si/aspr_mailing_list.html)

- BugTraq mailing list

- NTBugTraq mailing list

- Win2KSecAdvice mailing list

- SI-CERT



This distribution is governed by our ASPR Notification And Publishing Policy

(http://www.acros.si/aspr_policy.html).



Find our other reports on our ASPR page (http://www.acros.si/aspr.html).





DISCLAIMER

==========



The information in this report is purely informational and meant only for

the purpose of education and protection. ACROS, d.o.o. shall in no event be

liable for any damage whatsoever, direct or implied, arising from use or

spread of this information.

All identifiers (hostnames, IP addresses, company names, individual names

etc.) used in examples and exploits are used only for explanatory purposes

and have no connection with any real host, company or individual. In no

event should it be assumed that use of these names means specific hosts,

companies or individuals are vulnerable to any attacks nor does it mean that

they consent to being used in any vulnerability tests.

The use of information in this report is entirely at user's risk.





COPYRIGHT

=========



(c) 2000 ACROS, d.o.o., Slovenia. Forwarding and publishing of this document

is permitted providing all information between marks "[BEGIN-ACROS-REPORT]"

and "[END-ACROS-REPORT]" remains unchanged.



=====[END-ACROS-REPORT]=====