COMMAND
Netscape
SYSTEMS AFFECTED
Netscape
PROBLEM
Kevin Fu found following. This vulnerability defeats SSL server
authentication in Netscape 4.73 and earlier versions. This is a
new vulnerability unrelated to:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/nscape64.html
However, it has a similar devastating effect: destroying SSL
server authentication. Under certain conditions, users can no
longer trust the authenticity of SSL server certificates in
Netscape.
This new vulnerability makes Netscape's SSL implementation as
insecure as DNS. If you are victimized by this attack, then you
may unknowingly divulge private information such as credit card
numbers, personal data, passwords to online financial services,
or other sensitive information to an adversary masquerading as
what you think is a trusted SSL server.
Within one Netscape session, if a user clicks on "continue" in
response to a "hostname does not match name in certificate," then
that certificate is incorrectly validated for future use in the
Netscape session, REGARDLESS of the hostname or IP address of
other servers that use the certificate.
Exploit? Your web server has a certificate signed by a trusted
certificate authority. For the purposes of this exploit, the
example web servers below share the same certificate and private
key.
Official name: snafu.mit.edu
Host address: 18.152.0.102
Official name: snafu.fooworld.org
Host address: 18.152.0.102
Official name: www.nscl.org
Host address: 18.152.0.131
1. Play the part of the innocent user. Visit
https://snafu.mit.edu/ with any version on Netscape (minus the
Personal Security Manager). When the dialog warning appears,
you click continue because you do not intend to give private
information to this web server. You just want to access the
page with confidentiality enabled, whether or not the server is
authentic. Note that you have asked to accept this certificate
for this hostname, snafu.mit.edu, even though the certificate
belongs to snafu.fooworld.org.
2. Now play the part of the adversary. Simulate DNS poisoning.
Add an entry to /etc/hosts (UNIX), c:\windows\hosts.sam
(Windows98), or c:\winnt\system32\drivers\etc\hosts (Windows
NT) that reads:
www.the-site-you-want-to-spoof.com 18.152.0.131
This will redirect your www.the-site-you-want-to-spoof.com
requests to another server, www.nscl.org. The www.nscl.org
server happens to use the same certificate as snafu.mit.edu.
3. Schach. Time to switch back to playing the innocent user.
Visit https://www.the-site-you-want-to-spoof.com/. If your
browser allows you to visit this site without a warning, you
have been duped into believing you are talking to a trusted
SSL web server.
If the ILOVEYOU virus has taught us anything, it's taught us that
the general user population can be easily fooled by seemingly
innocent requests. This vulnerability is a prime example. By
following a link to an SSL server that has a certificate with an
incorrect hostname, all future SSL connections in the Netscape
session are made no more secure than DNS.
It seems that the "Certificate Name Check" warning will mark a
certificate as valid for any hostname or IP address in the
future. In this way, if an adversary tricks a user into accepting
an invalid certificate at a seemingly benign site, the user can
then be tricked if he/she ever visits a malicious site using the
same certificate.
A benign "continue" click on https://snafu.mit.edu/ might end up
taking away server authentication from visiting
https://www.a-site-that-you-give-private-info.com/ that has
poisoned DNS. Note, Kevin has only tested this with server
certificates signed by a certificate authority trusted by
Netscape. This attack may be less powerful if the malicious
server certificate is merely self-signed.
Furthermore, the security community has many examples showing that
DNS is not secure at all. For instance, a teenager recently
defaced the RSA.COM site by an attack against a DNS server. It
should be trivial to attack targeted individuals and not difficult
to attack general users at large.
Here are some imagined but unimplemented ways that might fool a
user into accepting an invalid certificate:
* Javascript/Java which references an HTTPS URL.
* Users just clicks.
* Hide the warning window with a pop-up window.
* Email with embedded HTTPS.
* Embed HTTPS images in a web page.
* VBS ILOVEYOU variant virus attachment that appends to
hosts.sam and adds certificate to browser's certificate
database.
Here are some ways one might affect DNS:
* Add a fake DNS entry for the target server in a compromised
DNS server.
* Respond to DNS requests since UDP responses are easily
forged.
* Modify /etc/hosts via a known root vulnerability on a UNIX
machine. Or on Windows, append to c:\windows\hosts.sam or
on NT c:\winnt\system32\drivers\etc\hosts
Verified as vulnerable:
- Linux Netscape 4.73
- Windows 98 Netscape 4.73
- Macintosh Netscape 4.73
Verified as not vulnerable:
- Linux Netscape 4.73 + PSM
- Windows 98 Netscape 4.73 + PSM
- Windows 98 Microsoft Internet Explorer 5.00.2614.3500
Check
http://snafu.fooworld.org/~fubob/netscape-ssl.html
for updates to this advisory.
SOLUTION
There is a limited software solution if you run Linux, Solaris, or
Windows95/98/NT. Otherwise, you will have to manually inspect
server certificates in Netscape. The CERT CA-2000-8 advisory
better explains the non-software solution.
If you run one of the above operating systems, then you must
install BOTH Netscape Communicator (v4.73) and the iPlanet
Personal Security Manager (PSM) for the full fix. PSM appears to
manage certificates more securely. Note, several people have
reported problems installing PSM. iPlanet's PSM does not yet
exist for the Macintosh.