COMMAND
Internet Explorer
SYSTEMS AFFECTED
SSL Certificates In Internet Explorer
PROBLEM
Following is based on ACROS Security Problem Report. Their 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.
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.
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">
</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.
Tests were performed on:
IE 4.0 - affected
IE 4.01 - affected
IE 5.0 - affected
IE 5.01 - affected
Why does the first vulnerability occur? The first vulnerability
occurs because IE doesn't perform all of the expected certificate
validation, if the session was set up in either of two ways.
Under normal circumstances, IE does perform all expected
certificate validation. However, if the connection to the server
is made via either an image or within a frame, IE only verifies
that the certificate was issued by a trusted party.
Why does this pose a security threat? It could help make it
possible for a malicious web site to pose as a different web site
- one that the user trusts. By itself, the vulnerability wouldn't
be sufficient to accomplish this, but it would be an important
part of such an attack. To pose as a trusted site, a malicious
web site operator would need to accomplish two goals: he would
need to be able to convince someone who visited his site that it
was actually a different site. He would need to be able to set up
an SSL session in the guise of the site his is posing as.
This vulnerability could enable him to accomplish the second goal,
because it would allow his site to present a certificate and have
it accepted even if it didn't match the name of his site.
However, accomplishing the first goal would be a separate issue,
requiring that the malicious user either carry out DNS poisoning
or physically interpose his machine in place of the other server.
What is DNS poisoning? DNS (Domain Name Service) is the protocol
by which web addresses (e.g., www.microsoft.com) are translated
into IP addresses (e.g., 207.46.131.30). DNS poisoning involves
providing bogus data to a DNS server in order to misdirect users.
For instance, a malicious user who operated Web Site A but wanted
to pose as Web Site B might mount a DNS poisoning attack in order
to put Web Site A's IP address into the entry for Web Site B.
Users who used the "poisoned" DNS server to locate Web Site B
would then be served Web Site A's IP address.
DNS poisoning is a technically-difficult attack. Even when
successful, the effects are limited to particular DNS servers and
only last for a short period. Thus, even with the vulnerability
in hand, it would be very difficult for a malicious web site
operator to actually carry out an attack using it.
Why does the second vulnerability occur? The second vulnerability
occurs because IE caches certificates that it has validated, and
doesn't revalidate certificates from the same site if a subsequent
SSL session is started with that site during the same IE session.
Consider the following scenario: the user starts IE and
establishes an SSL session with Web Site A He ends the SSL session
with Web Site A and browses some other sites He returns to Web
Site A and establishes a new SSL session. When establishing the
first SSL session, IE would validate the certificate from Web
Site A.
Note that, because of the first vulnerability, there are cases in
which IE would not perform this validation completely. When
establishing the second SSL session with Web Site A, IE would note
that it has previously validated a certificate from that site, and
would simply use the certificate the site presented without
validating it - even if the certificate were completely different.
Why does this pose a security threat? It's easiest to see by
example. Suppose you just completed an SSL session with Web Site
A, and five minutes later decided to start another SSL session
with the same site. Now suppose that during the previous five
minutes, a malicious user had somehow managed to interpose his
server between you and Web Site A, or had carried out a DNS
poisoning attack to masquerade as Web Site A. When you started a
new SSL session with Server B (thinking it was Server A), the
malicious user could send you a bogus certificate. The
vulnerability would cause IE to not try to validate the
certificate, but instead simply use the certificate blindly. The
result would be an SSL session with Web Site B that appeared to be
with Web Site A.
Would you need to return to the same site in order for this
vulnerability to be exposed? Yes. IE correctly validates a
site's certificate the first time it's used (within the limits of
the first vulnerability, discussed above). It's only if you
establish a subsequent session with the same site (or one that
appears to be the same site) that the vulnerability is exposed.
What would happen if I closed IE between the two SSL sessions?
The vulnerability wouldn't be exposed. IE only skips the
certificate validation if it already has a validated certificate
in the cache. The cache is cleared each time you close IE.
Is there a way to manually verify certificates? Yes. At any
point during an SSL session, you can view the server's certificate
by double-clicking on the key icon that appears at the lower right
corner of the screen. This will let you see who the certificate
was issued to, who issued it, the expiration date, and other
details.
In addition, you can configure IE to always request manual
confirmation of a certificate before setting up any SSL session.
Anytime a certificate is submitted that wasn't issued by a
trusted party, IE will display a warning message that lets you
inspect the certificate and decide whether to proceed. If you
want to always make the choice yourself, you can do this by
removing the default trusted certification authorities in IE as
follows:
- Choose Tools, then Internet Options
- Select the Content tab, then click "Certificates"
- Select the tab labeled "Trusted Root Certification
Authorities" and remove the entries.
- Click OK
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
The patch causes IE to correctly validate certificates no matter
how the session was established, and to validate the certificate
before every SSL session, under all conditions.
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.
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)
- other web-based e-commerce systems.
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.
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).