Message-ID: <85E1899C32F29743A449CA71324DF441016FFAC9@y6003a.umb.corp.umb.com>
From: Bill.Clark at umb.com (Clark, Bill W.)
Subject: IE SSL Vulnerability

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

Internet Explorer SSL Vulnerability 08/05/02 
Mike Benham <moxie@...ughtcrime.org> 
http://www.thoughtcrime.org <http://www.thoughtcrime.org/>
<http://www.thoughtcrime.org <http://www.thoughtcrime.org/> >  

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

Abstract 

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

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

Description 

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's 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's 
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, I can
generate 
a valid certificate and request a signature from VeriSign: 

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

Then I generate a certificate for any domain I want, and sign it using
my 
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 doesn't 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 

I would consider this to be incredibly 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's 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. 

========================================================================
= 
Affected Browsers 

Netscape 4.x and Mozilla are NOT vulnerable. 

IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable. 

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's 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. 

========================================================================
= 
Working Exploit 

I've set up a URL to demonstrate this problem.  If you want to test 
browsers not listed above or need proof of this vulnerability, contact
me 
and I'll give you the information. 

========================================================================
= 
Vendor Notification Status 

Last week I saw Microsoft downplay and obfuscate the severity of the 
IE vulnerability that Adam Megacz reported.  After seeing that, I don't 
feel like wasting time with the Microsoft PR department. 

- Mike 

-- 
http://www.thoughtcrime.org <http://www.thoughtcrime.org/>
<http://www.thoughtcrime.org <http://www.thoughtcrime.org/> >  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20020809/b07e9276/attachment.html

Powered by blists - more mailing lists