Re: Vulnerability in IE

From: Rich Benack [MS] (richbe@online.microsoft.com)
Date: 08/16/02 

From: "Rich Benack [MS]" <richbe@online.microsoft.com>
Date: Fri, 16 Aug 2002 08:55:58 -0700

Here is some more information on this issue:
http://www.microsoft.com/technet/security/news/IARWSV.asp

Rich

This information is provided "as is" without warranty of any kind.

"Jo Jeynes" <jo_jeynes@hotmail.com> wrote in message
news:42ac01c24535$01d7ac50$9ae62ecf@tkmsftngxa02...
> Hi, presume you are aware of this recently publicised
> vulnerability? What is
> Microsoft's response? I've not seen anything officical
> yet....
>
>
> ===========================================================
> =============
> Internet Explorer SSL Vulnerability 08/05/02
> Mike Benham <moxie@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.
>
>
>
>
>
>
>

Relevant Pages

  • Vulnerability in IE
    ... Internet Explorer SSL Vulnerability 08/05/02 ... certificate and has it signed by a Certificate Authority. ... intermediate certificates have valid CA Basic Constraints. ...
    (microsoft.public.security)
  • [NT] Internet Explorer SSL Vulnerability
    ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... certificate and has it signed by a Certificate Authority. ... You guessed it Internet Explorer does not check the Basic Constraints. ...
    (Securiteam)
  • [NT] Certificate Validation Flaw Could Enable Identity Spoofing
    ... The IETF Profile of the X.509 certificate standard defines several ... optional fields that can be included in a digital certificate. ... The vulnerability could enable an attacker who had a valid end-entity ...
    (Securiteam)
  • RE: IE SSL Vulnerability
    ... One quick note is that there's no basic constraints field in Verisign V1 ... Subject: IE SSL Vulnerability ... the administrator of a web site might wish to provide ... certificate and has it signed by a Certificate Authority. ...
    (Bugtraq)
  • IE SSL Vulnerability
    ... Internet Explorer SSL Vulnerability 08/05/02 ... allows for an active, undetected, man in the middle attack. ... certificate and has it signed by a Certificate Authority. ...
    (Bugtraq)