COMMAND
SSL Certificates In Netscape Navigator
SYSTEMS AFFECTED
Netscape Navigator & Communicator
PROBLEM
Following is based on ACROS Security Problem Report. Their team
has discovered a flaw in Netscape Navigator that allows bypassing
of warning about an invalid SSL certificate. SSL protection is
used in most major Internet-based financial services (e-banking,
e-commerce). The flaw we have found effectively disables 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. Using this flaw, the attacker can make users send
secret information (like credit card data and passwords) to his
web server rather than the real one - EVEN IF THE COMMUNICATION
IS PROTECTED BY SSL PROTOCOL.
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 should display
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 protocol. In
that case, when browser falsely connects to www.e-bank.com at
99.99.99.99 rather than to 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. Well, there is a flaw in
implementation of SSL certificate checks in Netscape Navigator.
Netscape Navigator correctly checks the certificate conditions (*)
at the beginning of a SSL session it establishes with a certain
web server. The flaw is, while this SSL session is still alive,
all HTTPS connections to *THAT SERVER'S IP ADDRESS* are assumed
to be a part of this session (and therefore certificate conditions
are not checked again). Instead of comparing hostnames to those
of currently open sessions, Navigator compares IP addresses.
Since more than one hostname can have the same IP address, there
is a great potential for security breach. This behavior is not
in compliance with SSL specification.
The following will try to demonstrate the flaw. It is assumed
that for redirecting user's web traffic, the attacker will
generally use "DNS poisoning" or reconfiguring routers, while in
our demonstration we will use the HOSTS file on client computer
to get the same effect and make it easier to reproduce the flaw.
In this demonstration, we will make Navigator open Thawte's
homepage over secure (HTTPS) connection while requesting
Verisign's home address at https://www.verisign.com. Thawte's
and Verisign's homepages are used as examples - this would work
just the same on any other secured web sites.
1) First, add the following line to the local HOSTS file on the
computer running the Navigator and save it:
207.240.177.177 www.verisign.com
This will make the computer (and, consequently, the browser)
think that IP address of www.verisign.com (which is actually
205.139.94.60) is in fact 207.240.177.177 (which is actually IP
address of www.thawte.com).
At this point it is important to note that SSL, if correctly
implemented, provides protection against such "domain name
spoofing", because while the browser will connect to the wrong
server, that server will not be able to provide a valid SSL
certificate and the SSL session will not be established (not
without user being warned about the certificate).
2) Close all instances of Navigator to clean any cached IP
addresses.
3) Open Navigator and go to https://www.thawte.com. It works as
it should - Thawte's server provides a valid SSL certificate
for its hostname (www.thawte.com) and so the SSL session is
established.
4) With the same instance of Navigator, go to
https://www.verisign.com. Now watch the Thawte's homepage
appear again WITHOUT ANY WARNINGS!
What happened here? In step 3), Navigator looked up the IP address
for www.thawte.com (from the DNS server) and found 207.240.177.177
It tried to establish a SSL session with that IP address and
correctly checked all three certificate conditions (*) - indeed,
if any of them weren't true, a warning would pop up.
In step 4), Navigator looked up the IP address for
www.verisign.com (this time from HOSTS file, but it could easily
have been from the same DNS server) and found again
207.240.177.177. Now, since there was already one SSL session
open with that IP address, Navigator *INCORRECTLY* decided to use
that session instead of establishing another one.
This exploit will show how the flaw could be used to gather user's
secret information. Assume there is a web bookstore at
www.thebookstore.com. Users go to http://www.thebookstore.com
(via normal HTTP connection), browse the books and add them to
their virtual shopping baskets. At the check-out, they are
directed to a secure order form (e.g.
https://www.thebookstore.com/order_form.html) where they enter
their personal and credit card information which is then submitted
(again via secure HTTPS connection) to the server. This is a
typical web e-commerce concept. Assume that IP address of
www.thebookstore.com is 100.100.100.100.
The attacker sets up his own web server with IP address
99.99.99.99 and installs on it a valid SSL certificate for host
www.attacker.com (he could have purchased this certificate from
e.g. Verisign if he owns the domain attacker.com; he could have
stolen the certificate or he could have broken into a web server
with a certificate already installed). The attacker makes this
web server function as a gateway to www.thebookstore.com - meaning
that all requests are forwarded to www.thebookstore.com, so
virtually this server "looks and feels" exactly like the real
www.thebookstore.com. There is just one difference: the page
before the order form (eg. www.thebookstore.com/basket.html)
contains a small (1x1) image originating from
https://www.attacker.com (secure HTTPS connection).
Then, the attacker "poisons" a heavily used DNS server so that it
will return 99.99.99.99 for requests about www.thebookstore.com
(normally it returns 100.100.100.100).
What happens then? All users of that DNS server who will try to
visit (via normal HTTP) http://www.thebookstore.com will connect
to 99.99.99.99 instead of 100.100.100.100 but will not notice
anything because everything will look just the way it should.
They will browse the books and add them to their shopping baskets
and at check-out, they will be presented with the order form
https://www.thebookstore.com/order_form.html.
But the previous HTML page containing the hyperlink to the order
form will also contain a small (1x1) image with source
https://www.attacker.com/a.gif. Navigator will successfully
download this image and for that it will establish a SSL session
with www.attacker.com. This session then stays open. When the
order form is accessed, Navigator tries to establish another SSL
session, this time to www.thebookstore.com. Since DNS server
claims this server has the same IP address as www.attacker.com
(99.99.99.99), Navigator will use the existing SSL session with
99.99.99.99 and will not check the certificate.
The result: Navigator is displaying a SECURE ORDER FORM that it
believes to be originating from the genuine server
www.thebookstore.com while in fact it is originating from the
fake one. No warning about an invalid certificate is issued to
the user so he also believes to be safe. When user submits his
secret information, it goes to (through) the attacker's server
where it is collected for massive abuse. For users to notice the
foul play they would have to look at the certificate properties
while on a "secure" page https://www.thebookstore.com/... The
properties would show that the certificate used was issued for
host www.attacker.com.
Also, monitoring network traffic would 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.
It should be noted that in the previous exploit, if the users
tried to access https://www.thebookstore.com over secure (HTTPS)
connection from the very start, Navigator would issue a warning.
It is imperative for the exploit to work that some time *before*
the first secure connection to https://www.thebookstore.com a
successful secure connection is made to https://www.attacker.com.
That's why a valid certificate must be installed on
www.attacker.com. Also, it should be noted that Navigator's SSL
sessions don't last forever. Authors of advisory haven't been
able to predict the duration of these sessions (it seems to be
depending on many things like inactivity time, total time etc.)
and we also haven't investigated the possible effects of SSL
session resuming.
Tests were performed on:
Communicator 4.72 - affected
Communicator 4.61 - affected
Navigator 4.07 - affected
SOLUTION
Netscape has provided a Navigator Add-on called Personal Security
Manager (PSM), freely downloadable at:
http://www.iplanet.com/downloads/download/detail_128_316.html
Installation of PSM, as far as we have tested it, corrects the
identified flaw. Netscape Communicator (v4.73) currently includes
the fix for this vulnerability. It is available for download at:
http://home.netscape.com/download/
Navigator/Communicator users who can't or don't want to install
PSM 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 (bottom left corner) or the key icon (in older browsers)
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.
Netscape Navigator/Communicator 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 Personal Security
Manager or upgrade to Communicator 4.73 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 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
Personal Security Manager or upgrade to Communicator 4.73 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.
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).
For RedHat:
intel: ftp://ftp.redhat.com/5.2/i386/netscape-common-4.73-0.5.2.i386.rpm
ftp://ftp.redhat.com/5.2/i386/netscape-navigator-4.73-0.5.2.i386.rpm
ftp://ftp.redhat.com/5.2/i386/netscape-communicator-4.73-0.5.2.i386.rpm
sources: ftp://ftp.redhat.com/5.2/SRPMS/netscape-4.73-0.5.2.src.rpm
intel: ftp://ftp.redhat.com/6.2/i386/netscape-common-4.73-1.i386.rpm
ftp://ftp.redhat.com/6.2/i386/netscape-navigator-4.73-1.i386.rpm
ftp://ftp.redhat.com/6.2/i386/netscape-communicator-4.73-1.i386.rpm
alpha: ftp://ftp.redhat.com/6.2/alpha/netscape-common-4.73-1.alpha.rpm
ftp://ftp.redhat.com/6.2/alpha/netscape-navigator-4.73-1.alpha.rpm
ftp://ftp.redhat.com/6.2/alpha/netscape-communicator-4.73-1.alpha.rpm
sources: ftp://ftp.redhat.com/6.2/SRPMS/netscape-4.73-1.src.rpm
ftp://ftp.redhat.com/6.2/SRPMS/netscape-alpha-4.73-1.src.rpm
For Red Hat Linux 5.0 and 5.1, use the Red Hat Linux 5.2 packages.
For Red Hat Linux 6.0 and 6.1, use the Red Hat Linux 6.2 packages.
As for Caldera Systems, OpenLinux eDesktop 2.4 previous to
communicator-4.73-2 has been found vulnerable. The proper
solution is to upgrade to the fixed packages:
ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/RPMS/
ftp://ftp.calderasystems.com/pub/updates/eDesktop/2.4/current/SRPMS