Volker Grassmuck on Mon, 15 May 2000 16:13:13 +0200 (CEST)


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[rohrpost] (Fwd) SSL Vulnerability of Netscape (was: CERT Advisory CA-2000-


are you using Netscape for eBanking and eShopping? Read this!


>Date: Fri, 12 May 2000 16:10:26 -0400 (EDT)
>From: CERT Advisory <cert-advisory@cert.org>
>To: cert-advisory@cert.org
>Subject: CERT Advisory CA-2000-05
>Reply-To: cert-advisory-request@cert.org
>Organization: CERT(R) Coordination Center - +1 412-268-7090
>Status: U
>
>-----BEGIN PGP SIGNED 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
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP for Personal Privacy 5.0
>Charset: noconv
>
>iQCVAwUBORxQsVFO4fmE3w/VAQHszAQAiCWcN/ZKkTBOl+hf5QrLDuHiypBqQ7N5
>TFy/ulrdc6xn25LCWDe1sQ6byXvvdi/Aduv33Zc2pnnciZvDQlF15aq22PcRhA0+
>kcDGwBqu+q19PNrfwFxQtFKwAliwvxxvUc+1vTKgY319LUJJ/lzdESK5DLeFBgmr
>PE77eUoSiAE=
>=Fl82
>-----END PGP SIGNATURE-----

-- 
Prof. Dr. Wolfgang Coy
Humboldt-Universitaet zu Berlin, Institut fuer Informatik
Unter den Linden 6, D-10099 Berlin

Tel (+49) 30 2093-3166 oder/or -3167,
Fax (+49) 30 2093-3168

http://waste.informatik.hu-berlin.de
ftp://trystero.informatik.hu-berlin.de/upload

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   home           http://waste.informatik.hu-berlin.de/Grassmuck/
   mikro          http://www.mikro.org
   Wizards of OS  http://www.mikro.org/wos
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

----------------------------------------------------------
# rohrpost -- deutschsprachige Mailingliste fuer Medien- und Netzkultur
# Info: majordomo@mikrolisten.de; msg: info rohrpost
# kommerzielle Verwertung nur mit Erlaubnis der AutorInnen
# Entsubskribieren: majordomo@mikrolisten.de, msg: unsubscribe rohrpost
# Kontakt: owner-rohrpost@mikrolisten.de -- http://www.mikro.org/rohrpost