> <snip> > 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. Hi Mike, I visited your demo at https://www.thoughtcrime.org. It appears that Thawte is the TTP instead of Verisign. Does this make any difference for example the certificate extensions? Is that what you are saying here that you got a subordinate CA signing certificate from Thawte (or Verisign according to your posting) for thoughtcrime.org and used this to generate a end entity server certificate for any domain you like? Or did you got an end entity server certificate from Thawte for www.thoughtcrime.org and used this certificate to sign end entity certificates? I ask this because in the basic constraints of www.thoughtcrime.org in your example the "subject type" is "end entity" instead of "CA" which should be the case for an intermediate CA according to RFC 2459. I think that you used a end entity certificate as intermediate CA, but I am not sure. > As the unscrupulous administrator of www.thoughtcrime.org, I can generate > a valid certificate and request a signature from VeriSign: Is this a CA-signature or a end entity signature? > > > [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: The "name constraints extension" in the CA certificate should not allow this. However in the case of a end entity certificate the name constraints extension is not present so you used a end entity certificate for your 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. Not if the "name constraints extension" is properly defined by the TTP. See section "4.2.1.11 Name Constraints" of RFC 2459. And the "pathLenConstraint field" in the basic constraints is set to zero. So is IE really vulnerable or is it the TTP that messed up by not defining a "name constraints extension"? > Affected Browsers > > Netscape 4.x and Mozilla are NOT vulnerable. I got a not very clear error code from Mozilla and Netscape. > > 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. > -Alex -- Ing. Alexander Willem Loots <mailto:a.loots@itsec.nl> ITsec Security Services <http://www.itsec.nl> Exploit & Vulnerability Alerting Service <http://www.evas.nl> P.O. box 5120 NL 2000 GC Haarlem Tel +31(0)23 542 05 78 Fax +31(0)23 534 54 77 --
