COMMAND
IE
SYSTEMS AFFECTED
Internet Explorer
PROBLEM
Following is vased on a ACROS Security Problem Report
#2000-07-22-2-PUB. Their 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, ACROS has 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.
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).
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.
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
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, ACROS have set up a web server (www.test.com),
installed a valid SSL key+certificate and enabled Basic HTTP
authentication. They have also written a script (variables.cgi),
which displays the contents of HTTP authentication data
(username:password) received by the browser.
Then, they opened Internet Explorer, typed
"https://www.test.com/variables.cgi" and they 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 their 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!) they 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.
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 <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 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:
<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 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.
By knowing the user's username and password, the attacker can
login to the sensitive system, assuming the user's identity.
SOLUTION
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.
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".
Internet Explorer 5.5 - not affected (according to Microsoft).