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

=========================================================================
ACROS Security Problem Report #1999-12-15-1-PUB

Bypassing Warnings For Invalid SSL Certificates In Internet Explorer

FULL REPORT PUBLIC
======

Affected System(s): Microsoft Internet Explorer
Problem: Bypassing Warnings For Invalid SSL Certificates
Severity: High
Solution: Installing the patch
Discovered: December 14, 1999
Vendor notified: December 16, 1999
Last update: June 5, 2000
Published: June 6, 2000

SUMMARY

Our team has discovered two flaws in Internet Explorer that allow bypassing
of warning about an invalid SSL certificate. SSL protection is used in most
major Internet-based financial services (e-banking, e-commerce). The flaws
we have found effectively disable one of the two basic SSL functionalities:
to assure users that they are really communicating with the intended web
server - and not with a fake one.

INTRODUCTION (skip this section if you already understand how SSL works)

When a web browser tries to connect to a SSL-protected server, a so-called
SSL session is established. At the beginning of this session the server
presents his SSL certificate containing his public key. At this point,
browser checks the certificate for the following conditions (*):

1) Certificate must be issued by a certificate authority trusted by browser
(some are default: Verisign, Thawte etc.)
2) Certificate must not be expired (its expiry date:time must be later than
the current system date:time on the computer browser is running on)
3) Certificate must be for the server that browser is connecting to (if
browser is connecting to www.e-bank.com, the certificate must be for
www.e-bank.com)

All three conditions must be met for browser to accept the certificate. For
every condition not met, browser displays a warning to the user and then
user can decide whether connection should be established or not.
These three conditions combined provide user with assurance that his browser
is really connecting to the correct server and not to some fake server
placed on the Internet by malicious individual(s) trying to trick users to
give them credit card information, passwords and other secret information.

For example, let's take a look at a sample web e-banking system that doesn't
use SSL certificates and requires one-time password tokens for user
authentication. User connects to http://www.e-bank.com. Browser asks DNS
server for IP address of www.e-bank.com and gets 100.100.100.100. Browser
then connects to 100.100.100.100 and user is presented with login form
asking for his username and one-time password. He enters this data and
starts using e-banking services.
A simple attack (called web-spoofing) on this system is to attack the DNS
server and "poison" its entry for www.e-bank.com with attacker's IP address
99.99.99.99. Attacker sets up a web server at 99.99.99.99 that web-wise
looks exactly like the original www.e-bank.com server. User trying to
connect to www.e-bank.com will now instead connect to the attacker's server
and provide it with his one-time password. Attacker's server will use this
password to connect to the real server at 100.100.100.100 and transfer all
of the user's money to his secret swiss bank account.

This attack is successfully disabled by using SSL certificates. In that
case, when browser falsely connects to www.e-bank.com at 99.99.99.99 rather
than at 100.100.100.100, attacker's server must provide a valid certificate
for www.e-bank.com, which it can't unless the attacker has stolen the secret
key and the certificate from the real server. Let's look at three
possibilities:

1) Attacker could issue a certificate for www.e-bank.com himself (on his own
CA). That wouldn't work since his CA is not trusted by user's browser.
2) Attacker could use a stolen expired key and certificate (those are often
not protected as strongly as valid ones since one could think they can't
be used any more). That wouldn't work since browser will notice that
certificate is expired.
3) Attacker could use a valid key and certificate for some other site (e.g.
www.something.org). That wouldn't work since browser will accept only
valid certificates for www.e-bank.com.

It would seem that this problem of web-spoofing is successfully solved with
SSL certificates.

PROBLEM

There are two flaws in implementation of SSL certificate checks in Internet
Explorer:

Flaw #1

Internet Explorer only checks the certificate conditions (*) at the FIRST
SSL connection it establishes with a certain server (first in the "life" of
the particular instance of IE - until it's closed). If the conditions are
met, every subsequent SSL connection with the same server is established
WITHOUT REGARD TO CERTIFICATE CONDITIONS. Obviously IE assumes that if
certificate was OK the first time, it will be OK later, too. This assumption
is critically flawed as will be demonstrated in Example #1.

Flaw #2

Even at the first SSL connection to a certain server Internet Explorer
doesn't check all three certificate conditions (*) in case the first SSL
connection is made through an image (<IMG> tag) or a frame (<FRAME> tag).
In this case, IE only checks for certificate issuer, while it DOESN'T CHECK
FOR EXPIRATION OR SERVER NAME. The potential security consequences of this
will be shown in Example #2.

EXAMPLES

Both examples will demonstrate how a user connecting to
https://www.e-bank.com can be tricked to actually connect to attacker's
server without the browser ever issuing a warning about invalid certificate.
The IP address of www.e-bank.com is 100.100.100.100. In both examples,
attacker sets up his fake web server. This web server looks to its visitors
exactly like server www.e-bank.com - same text, same design, same
functionality - it only has different IP and different SSL certificate. And,
of course, a different owner with very unpleasant plans.

Example #1

Attacker has ability to monitor network traffic and change IP routing
somewhere between user's browser and server www.e-bank.com. He installs ANY
key+certificate on his server and gives the server IP address 100.100.100.100
(the certificate can even be issued by his own CA, it can be expired and it
can be for any server name, although in case of self-issuance it can well be
for www.e-bank.com).
By monitoring network traffic attacker can determine when user is trying to
connect to https://www.e-bank.com. After first SSL handshake with the real
server at 100.100.100.100 he knows that user's Internet Explorer has checked
the server's certificate and that it won't do it again until IE is closed.
Attacker then changes IP routing between user and server www.e-bank.com so
that all IP packets to 100.100.100.100 are routed to his server rather than
to the original one. This way, without user ever noticing it, all subsequent
communication with www.e-bank.com will actually be established with the
attacker's server.

A variant of this attack could be that instead of changing IP routing,
attacker disables (DoS) the real server www.e-bank.com and then sets up his
own with the same IP address 100.100.100.100 somewhere where current IP
routing will make it accessible.

The reader can try this lab example: set up two web servers (A and B) and
install on server A a valid certificate for www.test.com (or whatever you
might have access to) issued by a trusted CA, say Verisign. Install on
server B an expired certificate for www.blah.com (or whatever), also issued
by a trusted CA. Give both servers the same IP address but connect only
server A to your network. Make sure www.test.com resolves to this IP within
your network.
Now, open Internet Explorer on any other machine and connect to
https://www.test.com. As expected, see the default web page from server A
appear.
Then unplug server A from the network and connect server B to the network.
Refresh the page in Internet Explorer and see the server B's default page
appear. You (the attacker) have just successfully switched the real server
with a fake one and the user didn't get any warnings!

Example #2

Attacker has ability to change DNS records on user's DNS server. He could
have legitimate administrative privileges there or he could do it using any
one of numerous known DNS attacks.
Attacker sets up a fake e-bank server at IP address 99.99.99.99 and installs
on it any key+certificate from a trusted CA (it can be for any server name
and can also be expired). He also sets up a web page on some free web
service, for example http://www.geocities.com/attacker/trap.html containing
this HTML code:

<HTML>
<BODY>
<img src="https://www.e-bank.com/whatever.gif&quot;&gt;
</BODY>
</HTML>

(note that whatever.gif doesn't need to exist on www.e-bank.com)

He then changes DNS record for www.e-bank.com from 100.100.100.100 to
99.99.99.99 and using social engineering or one of numerous technical
methods makes the user open the above web-page in his Internet Explorer.
When that happens, IE tries to get the image whatever.gif from
www.e-bank.com over SSL secured connection. www.e-bank.com resolves to
99.99.99.99 which is the attacker's server. When SSL session is established,
IE only checks the certificate issuer and if it is one of the trusted ones,
session is established without checking for expiration date or server name.
After that, IE won't check the certificate on any subsequent connections to
https://www.e-bank.com - until it is closed.
After this "prelude", user can try to connect to https://www.e-bank.com but
will actually connect to the attacker's server - with no way of knowing it -
except for two things:

• inspecting the certificate (double click on the lock icon) will reveal
  invalid data;
• monitoring network traffic will show that the server is not at
  100.100.100.100 where it should be but rather at 99.99.99.99.

It is a very rare practice to check any of these when nothing suspect is
happening.

SOLUTION

Microsoft has provided a patch that disables this vulnerability. It is
freely downloadable from:

http://www.microsoft.com/windows/ie/download/critical/patch7.htm
[Patch for IE 4.x not yet available at the time of this writing]

Installation of this patch, as far as we have tested it, corrects the
identified flaw.

Microsoft has also issued a Security Bulletin and FAQ about this issue,
available at:

http://www.microsoft.com/technet/security/bulletin/ms00-039.asp
http://www.microsoft.com/technet/security/bulletin/fq00-039.asp
[FAQ not yet available at the time of this writing]

WORKAROUND

Internet Explorer users who can't or don't want to install the patch can
use a "manual" method to make sure they are not under attack:

When visiting an SSL-protected site, double click on the lock icon (in
status line) and see whether the certificate used for the connection is
really issued for the correct hostname. E.g. If you visit
https://www.verisign.com, make sure the certificate used is issued for
www.verisign.com and not for some other hostname.

ADVISORY

It is important to emphasize that the flaw presented completely compromises
SSL's ability to provide strong server authentication and therefore poses
a serious threat to Explorer users relying on its SSL protection.

Users of web services

Internet Explorer users who are also users of any critical web services
employing Secure Sockets Layer (SSL) protection to provide secrecy
and integrity of browser-server communication are strongly advised to
install official Microsoft's patch and thus disable this vulnerability.

Main examples of such critical web services are:

• web banking systems (especially the ones using passwords for
  authentication - even one-time passwords),
• web stores (especially the ones accepting credit card data) and
• other web-based e-commerce systems.

Providers of web services

Providers of critical web services employing Secure Sockets Layer (SSL)
protection to provide secrecy and integrity of browser-server communication
should advise their users to install official Microsoft's patch and thus
disable this vulnerability.

Since this vulnerability allows for the type of attack that can completely
bypass the real/original web server, there are no technical countermeasures
which providers of web services could deploy at their sites.

However, to make the attacker's job harder, it is a good idea to make users
enter the secure site directly (writing https://www.securesite.com or
clicking a browser's bookmark), NOT clicking on a hyperlink in an unsecured
(or untrusted) site, commonly http://www.securesite.com for users'
convenience. You can accomplish this by removing all links from your
unsecured [parts of] sites to the secured ones. Please note that this won't
completely neutralize the vulnerability, it will only improve your odds a
bit.

Web services using client SSL certificates for user authentication

This vulnerability does NOT allow the attacker to steal client's SSL key
and thus execute the man-in-the-middle attack on web services using client
SSL certificates for user authentication. It still does, however, allow
the attacker to place a fake server (an exact copy) and collect other
information users provide (including the data in their client SSL
certificates).

TESTING RESULTS

Tests were performed on:

IE 4.0 - affected
IE 4.01 - affected
IE 5.0 - affected
IE 5.01 - affected

Tests were not performed on older versions, but they are very likely to be
affected too.

ACKNOWLEDGMENTS

We would like to acknowledge Microsoft (specifically Mr. Scott Culp and IE
team) for professional response to our notification of the identified
vulnerability and their help in understanding the flaw.

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: [email protected]

DISTRIBUTION

This report was sent to:

• BugTraq mailing list
• NTBugTraq mailing list
• Win2KSecAdvice mailing list
• CERT/CC
• SI-CERT
• ACROS client mailing list

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