[Forum] [tomd@sacefcu.org: FW: CERT Advisory CA-2000-05]

From: Morten Liebach <morten@hotpost.dk>
Date: Mon May 15 2000 - 19:32:44 CEST

Hejsa

Denne mail er fra misc@openbsd.org mailinglisten, og da det er et ret seriøst exploit synes jeg lige alle skulle se det, særligt fordi jeg lige selv er ved at skifte til den webbaserede homebanking hos DDB ;-)

Læs og forstå, det er spændende...

                Morten

----- Forwarded message from Tom DeSot <tomd@sacefcu.org> -----

Envelope-to: morten@localhost
Delivered-To: liebach@mail1.stofanet.dk
From: Tom DeSot <tomd@sacefcu.org>
To: "'misc@openbsd.org'" <misc@openbsd.org>
Subject: FW: CERT Advisory CA-2000-05
Date: Mon, 15 May 2000 10:45:37 -0500
X-Mailer: Internet Mail Service (5.5.2650.21)
Precedence: bulk
X-Loop: misc@openbsd.org

Thought I would forward this since the bulk of us are using Netscape in one
fashion or another.

Tom

> -----Original Message-----
> From: CERT Advisory [mailto:cert-advisory@cert.org]
> Sent: Friday, May 12, 2000 3:11 PM
> To: cert-advisory@cert.org
> Subject: CERT Advisory CA-2000-05
>
>
> -----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-----
>

----- End forwarded message -----

-- 
UNIX, reach out and grep someone!
Morten Liebach <morten@hotpost.dk>
Homepage at http://home1.stofanet.dk/liebach
Received on Mon May 15 19:34:36 2000

This archive was generated by hypermail 2.1.8 : Tue Jul 19 2005 - 16:01:05 CEST