=====[BEGIN-ACROS-REPORT]=====



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

   ACROS Security Problem Report #2000-07-22-2-PUB

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

   Remote Retrieval Of Authentication Data From Internet Explorer

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

   PUBLIC REPORT







   Affected System(s): Internet Explorer used in web-based systems with HTTP

                       Basic authentication

              Problem: Usernames and passwords can be retrieved remotely

                       from Internet Explorer

             Severity: High

             Solution: (see "Advisory" section)

              Written: July 22, 2000

          Last update: October 13, 2000

            Published: October 13, 2000





SUMMARY

=======



Our team has analyzed how popular web browsers could be tricked to reveal the

cached username:password pairs 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 Explorer.

However, it *should not* be assumed that only this product is affected but

rather all vendors of web browsers are urged to review their products for

the identified vulnerability.



Note: We have put quite an 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 IE's handling

of cached BASIC authentication data and also to provide a workable scenario

for exploiting this, and similar, vulnerabilities.





INTRODUCTION

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



So you have launched your new web-based e-purchasing system and protected it

with 128-bit SSL. Your users logon to it through their browsers, providing

their usernames and passwords. Entire communication is protected with SSL so

there's no way anyone could intercept their authentication data.



Or maybe your web admin is remotely administering your web server through

some remote admin app (like IISAdmin) and you're relying on SSL to encrypt

the HTTP "Basic" authentication when it's going through the Internet.



You feel safe; you trust SSL to do its job protecting your users and your

system. Their passwords are secure.



Or are they?



We will show that it could be possible to retrieve the cached authentication

data 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 bugs in various SSL implementations aside and assume SSL

is working as specified.





CACHED AUTHENTICATION DATA

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



For the purpose of this report, we'll define "cached authentication data" as

static username:password pairs which the client application (web browser)

needs to provide to the server in order to get his requests processed. We

will only deal with username:password pairs for HTTP BASIC authentication,

which is one of the authentication mechanisms that Internet Explorer

provides. Arguably, BASIC authentication is the only browser-integrated

authentication that is supported by both Internet Explorer and Netscape

Navigator so chances are that every public web-based system that pops up

a dialog window requesting a username and password at login, is using this

type of authentication.



Our definition of cached authentication data is not to be mistaken for

"Password Caching", a feature of Internet Explorer which allows users to

store their passwords in Explorer's storage so that they are never again

asked for them (even after IE is closed and rerun). However, using this

feature users are clearly making the attack we describe below even easier

to work.





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 a web server (www.test.com), installed

a valid SSL key+certificate and enabled Basic HTTP authentication. We have

also written a script (variables.cgi), which displays the contents of HTTP

authentication data (username:password) received by the browser.



Then, we opened Internet Explorer, typed "https://www.test.com/variables.cgi"

and we were presented with an authentication dialog asking us for username

and password. When these were entered correctly, the script variables.cgi was

executed which displayed our username and password.



The username and password were 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.cgi" (no SSL here!)

we could observe the authentication data being transmitted to the server over

an unencrypted link, thus making them interceptable for a network listening

attacker.



The conclusion is, that even though username and password were sent to the

server over an encrypted connection, they are also sent to the server over a

subsequent, 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* the browser do so.





EXPLOITATION (same as in ASPR-2000-07-22-1)

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



For the purpose of exploitation, there are at least two ways of making the

user's browser connect to an arbitrary URL:



Social Engineering 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 authentication data 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. 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

HTTP BASIC 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

just the amount of exchanged data), attacker can assume that the user has

successfully authenticated to the server and his browser has cached the

authentication data.



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 username

and password 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

authentication data 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 authentication data for the sensitive server.



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. However, in the case of Internet Explorer, there is an

easier way for making it send the authentication data over HTTP: by

"planting" a request for "http://www.sensitive.com:443/image.gif". This way,

the connection will be established to the (naturally open) port 443 and when

the server responds that it is there, the browser sends its request

(including username and password). Then, of course, the connection hangs

since a HTTP client is trying to talk to a HTTPS server, but that's no

problem since the sensitive data was already retrieved and the page will

reload in one second, that's long before a timeout would occur and possibly

alert the user.





Identity theft

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



By knowing the user's username and password, the attacker can login to the

sensitive system, assuming the user's identity.





ADVISORY

========



Microsoft has issued a patch for IE, available at:



http://www.microsoft.com/windows/ie/download/critical/q273868.htm



This patch changes the behavior of Internet Explorer so that it never sends

the cached authentication data over an unencrypted connection if it was

initially sent over an encrypted connection.



Users of Internet Explorer are advised to install the patch.



Managers of sensitive web-based systems using BASIC authentication are

urged to advise their users to install the patch.



Also take a look at Microsoft's Security Bulletin regarding this issue at:

http://www.microsoft.com/technet/security/bulletin/MS00-076.asp



and the FAQ at:

http://www.microsoft.com/technet/security/bulletin/fq00-076.asp





It is important to note that our limited testing only covered two web

browsers: Internet Explorer and Netscape Navigator (which isn't vulnerable).

There are many other web browsers that could be potentially affected by the

identified vulnerability.





WORKAROUND

==========



Users of web browsers can destroy cached authentication data 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 cached authentication data)



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:



Communicator 4.72 - not affected

Communicator 4.73 - not affected

Internet Explorer 4.01 SP2 - affected

Internet Explorer 5.01 - affected

Internet Explorer 5.5 - not affected (according to Microsoft)





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

- CERT/CC

- 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]=====