From: contact at bia-security.com (Anthony LaMantia)
Subject: Anyone buy this?


"The identity of the attacker could easily be determined. To exploit the
vulnerability, the attacker would require a valid SSL digital
certificate,
issued by a trusted Certificate Authority."

that is not true..(taken from  Mike Benham <moxie@...ughtcrime.org>  of
www.thoughtcrime.org bugtraq report)

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


this is also taken advantage of, tools and a exploitation methods can be
found at Mike Benhams' website here:
http://www.thoughtcrime.org/ie.html

the the BugTraq advisory can be found here:
http://online.securityfocus.com/archive/1/286290/2002-07-31/2002-08-06/0


Anthony LaMantia 
http://www.bia-security.com



On Wed, 2002-08-14 at 16:54, Fenris The Wolf wrote:
> http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/
> news/IARWSV.asp
> 
> Information about Reported Web Security Vulnerability
> 
> There has been a good deal of discussion and speculation recently about a
> reported security vulnerability involving how Internet Explorer identifies
> secure web sites. The Microsoft Security Response Center has investigated
> the report and we'd like to provide information about the issue and our
> plans for addressing it.
> 
> The report discusses a problem in the way Internet Explorer establishes
> secure web sessions via the Secure Socket Layer (SSL) protocol. SSL provides
> a number of security features, but of particular interest in this case is
> its ability to verify that a web site is indeed the site it purports to be.
> A flaw in the SSL implementation could enable an attacker to create a web
> site that bypasses this protection, and masquerades as a different web
> site - one that the user might trust and provide with personal information
> such as credit card numbers.
> 
> The flaw could enable an attacker who has been issued a valid SSL digital
> certificate to create a seemingly valid additional certificate that purports
> to belong to a different web site. When a user visited the site, the
> attacker could present the second certificate in an attempt to convince the
> user that he or she was actually at the site it claimed.
> 
> While Microsoft has confirmed that the flaw does exist, it's important to
> note that actually exploiting it would be difficult, for several reasons:
> 
> The attack scenario is narrow. If a user arrived at the attacker's web site
> in the belief that it was actually a different, legitimate site, the flaw
> could allow the attacker to bolster this belief. But it provides no way to
> make the user actually arrive at the attacker's site, let alone in the
> belief that it is a different site. Doing this would likely require that the
> attacker be able to modify the Internet infrastructure that the user
> transited, via a technique such as DNS cache poisoning. However, such
> techniques are difficult, temporary, and generally require favorable network
> topology.
> 
> The identity of the attacker could easily be determined. To exploit the
> vulnerability, the attacker would require a valid SSL digital certificate,
> issued by a trusted Certificate Authority. However, most commercial
> Certificate Authorities require substantial proof of identity before issuing
> such a certificate, thereby making it possible for law enforcement
> authorities to determine who the attacker was. (Information on verifying
> certificates can be found here).
> 
> The user would always have the ability to determine the truth. Anytime an
> SSL session has been established, an icon shaped like a lock is present in
> the lower right corner of the screen. By double-clicking on the icon, the
> user can see information about the site's digital certificate, including the
> identity of the issuer. This would clearly show that, in contrast to the
> norm, this one hadn't been directly issued by a commercial Certificate
> Authority.
> 
> Despite the many challenges associated with exploiting the flaw, there is
> indeed a flaw here and Microsoft is developing a patch that will eliminate
> it. When the patch is available, we will release a security bulletin
> discussing the overall issue and how to apply the patch.
> 
> We regret any anxiety that customers may have experienced regarding this
> issue. Clearly, it would have been best if a balanced assessment of the
> issue and its risk had been available from the start. However, the report,
> which neglected to discuss any of the challenges associated with actually
> exploiting the vulnerability, was made public without any advance warning to
> Microsoft. Responsible security researchers have the safety of users in mind
> and work with vendors to ensure that the information published about
> potential vulnerabilities is balanced and, above all, correct. Had this been
> done in this case, all users' interests would have been better served.
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.netsys.com/full-disclosure-charter.html
> 

Powered by blists - more mailing lists