[iwar] FW: CERT Advisory CA-2000-05 Netscape Navigator Improperly Validates SSL Sessions


From: Robert W. Miller
To: ,
From: snooker@iex.net
To: htcc@onelist.com,

Fri, 12 May 2000 20:44:13 -0600


fc  Fri May 12 19:45:14 2000
Received: from 207.222.214.225
	by localhost with POP3 (fetchmail-5.1.0)
	for fc@localhost (single-drop); Fri, 12 May 2000 19:45:14 -0700 (PDT)
Received: by multi33.netcomi.com for fc
 (with Netcom Interactive pop3d (v1.21.1 1998/05/07) Sat May 13 02:45:07 2000)
X-From_: sentto-279987-353-fc=all.net@returns.onelist.com  Fri May 12 21:44:31 2000
Received: from fk.egroups.com (fk.egroups.com [208.50.144.73]) by multi33.netcomi.com (8.8.5/8.7.4) with SMTP id VAA12436 for ; Fri, 12 May 2000 21:44:31 -0500
X-eGroups-Return: sentto-279987-353-fc=all.net@returns.onelist.com
Received: from [10.1.10.35] by fk.egroups.com with NNFMP; 13 May 2000 02:44:37 -0000
Received: (qmail 9263 invoked from network); 13 May 2000 02:44:36 -0000
Received: from unknown (10.1.10.142) by m1.onelist.org with QMQP; 13 May 2000 02:44:36 -0000
Received: from unknown (HELO mail.iex.net) (192.156.196.5) by mta3 with SMTP; 13 May 2000 02:44:36 -0000
Received: from oemcomputer (p12-s8.cos1-ras.iex.net [209.151.65.108]) by mail.iex.net (8.9.1/8.9.1) with SMTP id UAA27924; Fri, 12 May 2000 20:34:13 -0600 (MDT)
To: , ,
        "Cfid List Member" 
Message-ID: 
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
From: "Robert W. Miller" 
MIME-Version: 1.0
Mailing-List: list iwar@egroups.com; contact iwar-owner@egroups.com
Delivered-To: mailing list iwar@egroups.com
Precedence: bulk
List-Unsubscribe: 
Date: Fri, 12 May 2000 20:44:13 -0600
Reply-To: iwar@egroups.com
Subject: [iwar] FW: CERT Advisory CA-2000-05 Netscape Navigator Improperly Validates SSL Sessions
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

*** PGP Signature Status: unknown
*** Signer: Unknown, Key ID = 0x84DF0FD5
*** Signed: 5/12/00 12:42:57 PM
*** Verified: 5/12/00 8:32:28 PM
*** BEGIN PGP VERIFIED MESSAGE ***

CERT Advisory CA-2000-05
Netscape Navigator Improperly Validates SSL Sessions

   Original release date: May 12, 2000
   Source: ACROS, CERT/CC

   A complete revision history is at the end of this file.

Systems Affected

     * Systems running Netscape Navigator 4.72, 4.61, and 4.07. Other
       versions less than 4.72 are likely to be affected as well.

Overview

   The ACROS Security Team of Slovenia has discovered a flaw in the
way
   Netscape Navigator validates SSL sessions.

I. Description

   The text of the advisory from ACROS is included below. It includes
   information CERT/CC would not ordinarily publish, including
specific
   site names and exploit information. However, because it is already
   public, we are including it here as part of the complete text
provided
   by ACROS.

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


======================================================================
===
   ACROS Security Problem Report #2000-04-06-1-PUB
   -------------------------------------------------------------------
------
   Bypassing Warnings For Invalid SSL Certificates In Netscape
Navigator

======================================================================
===
   FULL REPORT
PUBLIC

======


   Affected System(s): Netscape Navigator & Communicator
              Problem: Bypassing Warnings For Invalid SSL Certificates
             Severity: High
             Solution: Installing the Personal Security Manager or
                       Installing the newest Netscape Communicator
(v4.73)
           Discovered: April 3, 2000
      Vendor notified: April 4, 2000
          Last update: May 10, 2000
            Published: May 10, 2000


SUMMARY
=======

Our 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.


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 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.


PROBLEM
=======

There is a flaw in implementation of SSL certificate checks in
Netscape
Navigator.


The Flaw
--------

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.


DEMONSTRATION
=============

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.


EXPLOIT
=======

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 (e.g. http://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.


Notes
-----

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.
We 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.


SOLUTION
========

Netscape has (even prior to our notification - see the Acknowledgments
section) 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/


WORKAROUND
==========

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.


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 Navigator users relying on its SSL protection.


Users of web services
---------------------

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) 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 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).


TESTING RESULTS
===============

Tests were performed on:

Communicator 4.72 - affected
Communicator 4.61 - affected
Navigator 4.07 - affected


ACKNOWLEDGMENTS
===============

We would like to acknowledge Netscape (specifically Mr. Bob Lord and
Mr.
Kevin Murray) for prompt and professional response to our notification
of
the identified vulnerability and their help in understanding the flaw
and
"polishing" this report.

We would also like to acknowledge Mr. Matthias Suencksen of Germany,
who
has discovered some aspects of this vulnerability before we did (back
in
May 1999).


REFERENCES
==========

Netscape has issued a Security Note about this vulnerability under a
title
"The Acros-Suencksen SSL Vulnerability" at:

http://home.netscape.com/security/notes/index.html


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

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:

- BugTraq mailing list
- NTBugTraq mailing list
- Win2KSecAdvice mailing list
- 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]=====

II. Impact

   Attackers can trick users into disclosing information (potentially
   including credit card numbers, personal data, or other sensitive
   information) intended for a legitimate web site, even if that web
site
   uses SSL to authenticate and secure transactions.

III. Solution

Install an update from your vendor.

   Appendix A lists information from vendors about updates.

If you are a DNS administrator, maintain the integrity of your DNS
server

   One way to exploit this vulnerability, described above, relies on
the
   ability of the attacker to compromise DNS information. If you are a
   DNS administrator, making sure your DNS server is up-to-date and
free
   of known vulnerabilities reduces the ability of an intruder to
execute
   this type of attack. Administrators of BIND DNS servers are
encouraged
   to read

   http://www.cert.org/advisories/CA-2000-03.html

Validate certificates at each use

   Despite the existence of this flaw, it is still possible to guard
   against attempted attacks by validating certificates manually each
   time you connect to an SSL-secured web site. Doing so will
   substantially reduce the ability of an attacker to use flaws in the
   DNS system to bypass SSL-authentication.

Appendix A. Vendor Information

iPlanet

   Information about this problem is available at
   http://home.netscape.com/security/notes/index.html

Microsoft

   None of our products are affected by this vulnerability.

   _________________________________________________________________

   The CERT Coordination Center thanks the ACROS Security Team of
   Slovenia (Contact: mitja.kolsek@acros.si), for the bulk of the text
   in this advisory.

   _________________________________________________________________

   Shawn Hernan was the primary author of the CERT/CC portions of this
   document.

______________________________________________________________________

   This document is available from:
   http://www.cert.org/advisories/CA-2000-05.html

______________________________________________________________________

CERT/CC Contact Information

   Email: cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.

   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) /
EDT(GMT-4)
   Monday through Friday; they are on call for emergencies during
other
   hours, on U.S. holidays, and on weekends.

Using encryption

   We strongly urge you to encrypt sensitive information sent by
email.
   Our public PGP key is available from

   http://www.cert.org/CERT_PGP.key

   If you prefer to use DES, please call the CERT hotline for more
   information.

Getting security information

   CERT publications and other security information are available from
   our web site

   http://www.cert.org/

   To be added to our mailing list for advisories and bulletins, send
   email to cert-advisory-request@cert.org and include SUBSCRIBE
   your-email-address in the subject of your message.

   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.

______________________________________________________________________

   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the
Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed
or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon
University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
     _________________________________________________________________

   Conditions for use, disclaimers, and sponsorship information

   Copyright 2000 Carnegie Mellon University; portions Copyright 2000
   ACROS, d.o.o., Slovenia.

   Revision History
   May 12, 2000:  Initial release


*** END PGP VERIFIED MESSAGE ***


------------------------------------------------------------------------
Remember four years of good friends, bad clothes, explosive chemistry
experiments.
http://click.egroups.com/1/4051/11/_/595019/_/958185877/
------------------------------------------------------------------------

------------------
http://all.net/