ACROS-2000-04-06-1-PUB

`=====[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]=====  
`