Web browser certificate Validation flaw: Netscape, Mozilla, MSIE vulnerable - still?

[Pidgorny, Slav]

Group,

I'm referring to the certificate validation issues that recently made huge
press:

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0862

I have seen all sorts of apocalyptic reports and anti-MS propaganda
regarding the issue, but in-depth technical analysis can't be easily found.
When I was doing my research quite a while ago
(http://online.securityfocus.com/archive/1/273101) I have noticed that some
certificates do not have Basic Constraints or any other optional fields in
the X.509 certificate. One example is the certificate used on Steve Gibson's
GRC Web site (https://grc.com). Those are V1 certs.

The problem being, if there's no Basic Constraints or Enhanced Key Usage
field on the certificate in the middle of the certification chain, there's
no mean for the client software to verify if a web server SSL certificate
was used as a CA certificate. Therefore, all platforms are vulnerable to
identity spoofing.

I wouldn't consider that as a huge problem since all Internet PKI is subject
to strict contractual agreements and violating those might well be a
criminal offence. However, I'd like to know your opinion.

Regards,

S. Pidgorny, MS MVP, MCSE/SCSA

DISCLAIMER: Opinions expressed by me is not necessarily my employer's, it is
not intended to be formal and accurate. Neither myself nor my employer
assume any responsibility for any consequences.

RE: IE SSL Vulnerability

[Pidgorny, Slav]

Hi Mike and the list,
 
That is one side of an issue I have described in 
 
http://online.securityfocus.com/archive/1/273101
 
 
I have to admit, your message captures attention much better than mine. All
for good, if that will be fixed.
 
The issue is known to both Microsoft and Verisign: the fix isn't on the todo
list for Microsoft, according to the feedback I have, and Verisign consider
that as a managed/manageable risk (it's more dangerous to their business,
really).
 
One quick note is that there's no basic constraints field in Verisign V1
certificates that are still available (their test CA used to issue V1).
 
I do agree: that's a problem to PKI implementations.
 
Regards
 
S. Pidgorny
 

-Original Message- 
From: Mike Benham [mailto:[EMAIL PROTECTED]] 
Sent: Tue 6/08/2002 9:03 AM 
To: [EMAIL PROTECTED] 
Cc: 
Subject: IE SSL Vulnerability




 
Internet Explorer SSL Vulnerability 08/05/02 
Mike Benham <[EMAIL PROTECTED]> 
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 att

Verisign PKI: anyone to subordinate CA

[Pidgorny, Slav]

G'day Bugtraq,

Microsoft Security Bulletin MS01-017
(http://www.microsoft.com/technet/security/bulletin/MS01-017.asp) inspired
me to do some testing. Here are the results:

1. I configured Microsoft Certificate services to act as a standalone
subordinate CA. A request for a CA certificate was generated.
2. I sent this request as a request for a Web server SSL certificate.
3. The Verisign test CA did not complain upon processing this request. It
generated and signed the certificate.
4. I installed the certificate to MS Certificate Services and start the CA
service.
5. From now on, I effectively have a signed CA certification.  Any generated
signatures from this point will have a certification path leading to the
root CA.

I only used Verisign test root CA in my test. The steps above can probably
be repeated using Verisign production root CA, resulting the situation
whereas I'm becoming a subordinate CA to Verisign trusted root without
letting them know.

Thawte test CA also signs the CA certificate submitted as a Web server
certificate, but MS Certificate Server refuses to install the certificate as
the CA certificate. The difference between Verisign and Thawte certificates
is the Basic Constraints field. If I would be using OpenSSL tools instead of
MS Certificate Server, I can probably disable all the checks against the CA
certificate.

Any thoughts? Do you think it's a security problem?

Regards,

S. Pidgorny, MS MVP, MCSE

DISCLAIMER: Opinions expressed by me is not necessarily my employer's, it is
not intended to be formal and accurate. Neither myself nor my employer
assume any responsibility for any consequences.

P.S. Many thanks to Dave Ahmad for the discussion leading to this post.