[NT] Internet Explorer SSL Vulnerability

From: support@securiteam.com
Date: 08/10/02 

From: support@securiteam.com
To: list@securiteam.com
Date: Sat, 10 Aug 2002 23:18:20 +0200 (CEST)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

When was the last time you checked your server's security?
How about a monthly report?
http://www.AutomatedScanning.com - Know that you're safe.
- - - - - - - - -

  Internet Explorer SSL Vulnerability
------------------------------------------------------------------------

SUMMARY

Internet Explorer's implementation of SSL contains a vulnerability that
allows for an active, undetected, man in the middle attack. No dialogs are
shown and no warnings are given.

DETAILS

Vulnerable systems:
 * Internet Explorer 5 and 5.5
 * Internet Explorer 6

Immune systems:
 * Netscape 4.x and Mozilla.

In the normal case, the administrator of a web site might wish to provide
secure communication via SSL. To do so, the administrator generates a
certificate and has it signed by a Certificate Authority. The generated
certificate should list the URL of the secure web site in the Common Name
field of the Distinguished Name section.

The CA verifies that the administrator legitimately owns the URL in the CN
field, signs the certificate, and gives it back. Assuming the
administrator is trying to secure www.thoughtcrime.org, we now have the
following certificate structure:

[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign
/ Subject: www.thoughtcrime.org]

When a web browser receives this, it should verify that the CN field
matches the domain it just connected to, and that it is signed using a
known CA certificate. No man in the middle attack is possible because it
should not be possible to substitute a certificate with a valid CN and a
valid signature.

However, there is a slightly more complicated scenario. Sometimes it is
convenient to delegate signing authority to more localized authorities. In
this case, the administrator of www.thoughtcrime.org would get a chain of
certificates from the localized authority:

[Issuer: VeriSign / Subject: VeriSign] -> [Issuer: VeriSign / Subject:
Intermediate CA] -> [Issuer: Intermediate CA / Subject:
www.thoughtcrime.org]

When a web browser receives this, it should verify that the CN field of
the leaf certificate matches the domain it just connected to, that it is
signed by the intermediate CA, and that the intermediate CA is signed by a
known CA certificate. Finally, the web browser should also check that all
intermediate certificates have valid CA Basic Constraints.

You guessed it Internet Explorer does not check the Basic Constraints.

Exploit:
So what does this mean? This means that as far as IE is concerned, anyone
with a valid CA-signed certificate for ANY domain can generate a valid
CA-signed certificate for ANY OTHER domain.

As the unscrupulous administrator of www.thoughtcrime.org, we can generate
a valid certificate and request a signature from VeriSign:

[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign
/ Subject: www.thoughtcrime.org]

Then we generate a certificate for any domain we want, and sign it using
our run-of-the-mill joe-blow CA-signed certificate:

[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign
/ Subject: www.thoughtcrime.org] -> [CERT - Issuer: www.thoughtcrime.org /
Subject: www.amazon.com]

Since IE does not check the Basic Constraints on the www.thoughtcrime.org
certificate, it accepts this certificate chain as valid for
www.amazon.com.

Anyone with any CA-signed certificate (and the corresponding private key)
can spoof anyone else.

Severity:
We would consider this severe. Any of the standard connection hijacking
techniques can be combined with this vulnerability to produce a successful
man in the middle attack. Since all you need is one constant CA-signed
certificate (and the corresponding private key), an attacker can use that
to generate spoofed certificates for other domains as connections are
intercepted (on the fly). Since no warnings are given and no dialogs are
shown, the attacker has effectively circumvented all security that an SSL
certificate provides.

There is some level of accountability, though, since a user who randomly
chooses to view the certificate of the web site she is visiting will see
the attacker's certificate in the chain. However, by that point the damage
has already been done. All "secure" data has already been transmitted.

When VeriSign issues certificates, usually they leave out the CA Basic
Constraint information all together. Thawte tends to explicitly put in a
Basic Constraint CA = FALSE with the critical bit set to TRUE.

When the CA Basic Constraint on the middle certificate is explicitly set
to false and marked as critical, IE 6 does not follow the chain. When it
is not mentioned at all, IE 6 follows the chain and is vulnerable.

This just means that an attacker needs to use a VeriSign-issued
certificate to exploit IE 6.

ADDITIONAL INFORMATION

The information has been provided by <mailto:moxie@thoughtcrime.org> Mike
Benham.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages