| 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 <[email protected]> >To: [email protected] >Subject: CERT Advisory CA-2000-05 >Reply-To: [email protected] >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: [email protected] > >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: [email protected]), 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: [email protected] > 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 [email protected] 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: [email protected]; msg: info rohrpost # kommerzielle Verwertung nur mit Erlaubnis der AutorInnen # Entsubskribieren: [email protected], msg: unsubscribe rohrpost # Kontakt: [email protected] -- http://www.mikro.org/rohrpost