Re: IE SSL Vulnerability
In the wise words of Charles Miller: Actually, the SSL vulnerability is a very predictable answer to an old question. For a while now, one of the big what ifs of Internet security has been What if one day, the SSL infrastructure is completely compromised? The most common hypothetical example of this was the compromise of a Verisign root signing key. Right. And along the way we've already experienced the baby version of this (certs that appear to be from Microsoft, but aren't, etc.) and the sky didn't fall in then, either. Predictions have ranged from the death of e-commerce, to the end of the world as we know it. Sure, if you take the hard line Cypherpunk position that absolute security is mandatory for e-commerce, that key escrow wouldn't do, that 40 bits wasn't enough, etc. Of course what happened is that people realized that, with a modicum of protection offered by SSL, the network transport was no longer the weak link --- the problem becomes the fact that the endpoints aren't totally secure. Given moderately insecure endpoints, the average user just wants to stop the average cracker from skimming the credit-card info. It's assumed that the outstanding cracker will still be able to get the info. SSL, even with some attacks against the certificate chain, is the best example of good enough crypto out there. (I tackle this argument from a slightly different angle in my most recent SecurityFocus column, actually. I'm becoming a big fan of good enough, especially coupled with insurance or an understanding of risk.) Now, it's not hypothetical any more. Until this is patched and the majority of users upgrade (in other words, give it two years), anyone can forge site certificates that seem valid to 90% of Internet users. The result? The news hasn't reached the real world at all. The story has stayed on news-for-nerds websites and in the technical section of mainstream press. E-commerce hasn't skipped a beat. That's in part because of the reasoning above, probably, and partly because the average consumer neither understands nor wishes to understand how SSL actually works. Without entering into a long discussion of certificate chains (not suitable for the nightly news, or the front page of USA Today) understanding the importance of the vulnerability is mighty tough. Yesterday a customer wanted to know why he couldn't specify a random (not-previously-created) account name and password and have his e-mail work. You see, his account was too full, he was at a remote site, and he didn't want to download all of his old mail... He's a smart fellow, in his domain of expertise, but he's not going to learn about certificate chains. Certainly none of our[1] customers, who were so adamant when we were speccing their web-applications that it _must_ be secured with SSL, have come screaming to us wondering what to do now anyone can man-in-the-middle them. SSL with a weakness in certificates is better than plaintext. You can't passively slurp all of the data; you need to be an active snooper for this to work, and be willing to change data. Among other things, this takes substantially more processing power than just slurping packets. It's still good enough. Heck, the PGP signature didn't catch the OpenSSH trojan; the MD5SUM did. Jon Lasser -- Jon Lasser Home: [EMAIL PROTECTED]|Work:[EMAIL PROTECTED] http://www.tux.org/~lasser/ |http://www.cluestickconsulting.com Buy my book, _Think_Unix_! http://www.tux.org/~lasser/think-unix/
Re: IE SSL Vulnerability
On Fri, 2002-08-16 at 09:11, robert walker wrote: A huge amount of infrastructure is managed remotely via SSL and IE these days. It just boggles the mind the extent to which the security integrity of that infrastructure is now under a cloud unknowing. Actually, the SSL vulnerability is a very predictable answer to an old question. For a while now, one of the big what ifs of Internet security has been What if one day, the SSL infrastructure is completely compromised? The most common hypothetical example of this was the compromise of a Verisign root signing key. Predictions have ranged from the death of e-commerce, to the end of the world as we know it. Now, it's not hypothetical any more. Until this is patched and the majority of users upgrade (in other words, give it two years), anyone can forge site certificates that seem valid to 90% of Internet users. The result? The news hasn't reached the real world at all. The story has stayed on news-for-nerds websites and in the technical section of mainstream press. E-commerce hasn't skipped a beat. Certainly none of our[1] customers, who were so adamant when we were speccing their web-applications that it _must_ be secured with SSL, have come screaming to us wondering what to do now anyone can man-in-the-middle them. I'm not sure whether to be saddened or wryly amused. I think I'll go with the latter. Charles Miller [1] Well, none of mine anyway.
Re: IE SSL Vulnerability
In-Reply-To: [EMAIL PROTECTED] Given my background in cryptographic programming, it is difficult for me to imagine how the cause of this alleged vulnerability could be explained as programmer error or oversight. Yet I cannot fathom why MS would purposely skip such a basic step. I am waiting to hear Microsoft's side of the story. Because it goes to a core issue of whether or not they themselves are trustworthy. My car has airbags which protect me in a collision. Imagine if the manufacturer forgot to install them. What explanation is satisfactory in that circumstance? A huge amount of infrastructure is managed remotely via SSL and IE these days. It just boggles the mind the extent to which the security integrity of that infrastructure is now under a cloud unknowing.
Re: IE SSL Vulnerability (Konqueror affected too)
http://theregister.co.uk/content/4/26620.html [] I've not tested this on IE because several researchers posting to Benham's BugTraq thread (http://online.securityfocus.com/archive/1/286895/2002-08-08/2002-08-14/1) have confirmed the behavior. But I did test it on Mozilla 0.9.4, which Benham says isn't vulnerable, and Konqueror 3.0 (KDE 3.0.2 on SuSE 8.0), which he doesn't mention. Konqueror turned out quite vulnerable. Mozilla was not vulnerable, but I'm not sure if that's because it handled the situation properly, or is, ironically, somehow too buggy to be exploited. I made a simple HTML file with links to the amazon URL. After associating Benham's test-page IP with www.amazon.com in my hosts file I found that in Konqueror, following a link to https://www.amazon.com brought me immediately to the 'you've been hacked' page, indicating total failure. The behavior was the same when I typed the URL into the address bar. With Mozilla the URL, https://www.amazon.com simply went nowhere. No cert warning, no 404, nothing. The browser simply remained on the page from which I started. The behavior was the same when I typed the URL into the address bar. [] --tcg http://theregister.co.uk
Re: IE SSL Vulnerability
On Wed, Aug 07, 2002 at 12:24:19PM -0700, Mike Benham wrote: First of all, https://www.thoughtcrime.org is NOT the demo site. Several people were confused by this email, and subsequently concluded that their browser isn't vulnerable because they got an alert that the name on the certificate is invalid. If you would like to see a demo of this vulnerability, please email me offline. By the way, I've performed full man-in-the-middle with a real bank involved and myselft as victim. It's easy and works perfectly, so I've put a brief description and screenshots at http://arch.ipsec.pl/inteligo.html Details on programs' setup and fake certificate generation are omitted not to provide script-kiddies with a ready recipe. Actually, you can use Mike's https://www.thoughtcrime.org/ as demo site but you first need to DNS spoof your browser into thinking that www.amazon.com has address of 66.93.78.63, which is easy using dnsspoof from dsniff for example. -- Pawe Krawczyk, Krakw, Poland http://echelon.pl/kravietz/ crypto: http://ipsec.pl/ horses: http://kabardians.com/
Re: IE SSL Vulnerability
On Mon, Aug 05, 2002 at 04:03:29PM -0700, Mike Benham wrote:
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.
As OpenSSL's default verify callback does not check basic constraints,
clients that utilize openssl as backend, and verify server certificates can
be affected too.
w3m for example does no basic constraints checking on its own, and neither
does lynx.
As I see the curl library does no basic constraints checking, so anything
that uses curl to fetch https urls are affected too.
As a final example, stunnel does not check basic constraints either. The
latter is usually using self generated certificates, so the impact is not
that severe.
An untested (but compiling) code fragment which checks basicConstraints.ca
field is below (it is to be insterted into the SSL verify_callback):
- ctx is the X509_STORE_CTX as passed to the verify callback
- xs is the X509 certificate to be verified (the callback is called for
every certificate in chain)
if (ok)
{
X509_OBJECT obj;
int bconstraints;
BASIC_CONSTRAINTS *bc;
int rc;
/* check whether issuer is a CA */
rc = X509_STORE_get_by_subject(ctx, X509_LU_X509, X509_get_issuer_name(xs),
obj);
if (rc 0 obj.data.x509)
{
bconstraints = X509_get_ext_by_NID(obj.data.x509, NID_basic_constraints, -1);
if (bconstraints = 0)
{
/* basic constraints found */
bc = X509V3_EXT_d2i(X509_get_ext(xs, bconstraints));
}
else
{
bc = NULL;
}
if (!bc)
{
printf(X509 extension basicConstraints missing from issuer;
subject='%s', issuer='%s', subject_name, issuer_name);
ok = FALSE;
errnum = X509_V_ERR_INVALID_CA;
}
else if (!bc-ca)
{
printf(CA certificate with basicConstraints.ca == FALSE; subject='%s',
issuer='%s', subject_name, issuer_name);
ok = FALSE;
errnum = X509_V_ERR_INVALID_CA;
}
}
}
--
Bazsi
PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
Re: IE SSL Vulnerability
I agree, this is really, really serious. If this is correct, I believe it is one of the most serious vulnerabilities reported in a long time. People trust SSL to protect their money, and this is a vulnerability where you could easily attack thousands of users or go after the banks with a simple man-in-the-middle attack. I have feared a certificate chain vulnerability for some time now. This one certainly has the potential to hurt a lot of the little guys if someone would decide to steal their money. I wonder what the legal implications would be. I suppose, as the bug is in the client software, the banks might be safe from a legal standpoint, even though they have designed the poor security infrastructure they are using. If client certificates were used for authentication, this bug would be far less severe. It is a bit sad that this was reported without letting Microsoft know about it first, although I am not sure what they could have done had they known. To get millions and millions of end users to path their browsers is quite a task, even for Microsoft. Does this bug apply only to IE 5, 5.5 and 6 and not to earlier browsers? Is it a bug in the browser or is it a bug in CryptoAPI? Is client certificate authentication in IIS vulnerable to the same attack? Best regards, Torbjörn Hovmark __ Abtrusion Security AB http://www.abtrusion.com - Original Message - From: Mike Benham [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 06, 2002 1:03 AM 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. [...]
Re: IE SSL Vulnerability
On Thu, Aug 08, 2002 at 01:38:46PM +0200, Balazs Scheidler wrote: On Mon, Aug 05, 2002 at 04:03:29PM -0700, Mike Benham wrote: 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. As OpenSSL's default verify callback does not check basic constraints, clients that utilize openssl as backend, and verify server certificates can be affected too. w3m for example does no basic constraints checking on its own, and neither does lynx. As I see the curl library does no basic constraints checking, so anything that uses curl to fetch https urls are affected too. As a final example, stunnel does not check basic constraints either. The latter is usually using self generated certificates, so the impact is not that severe. An untested (but compiling) code fragment which checks basicConstraints.ca field is below (it is to be insterted into the SSL verify_callback): Update: I was wrong claiming openssl does not check basic constraints by default. I was looking at the wrong code, it is implemented in crypto/x509v3 where purpose checking is implemented. So programs using openssl are safe. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
RE: IE SSL Vulnerability
Hi Mike and the list, That is one side of an issue I have described in http://online.securityfocus.com/archive/1/273101 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 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
Re: IE SSL Vulnerability
On Wed, 7 Aug 2002, Alex Loots wrote: 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? First of all, https://www.thoughtcrime.org is NOT the demo site. Several people were confused by this email, and subsequently concluded that their browser isn't vulnerable because they got an alert that the name on the certificate is invalid. If you would like to see a demo of this vulnerability, please email me offline. 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. Thawte and Verisign aren't doing anything wrong. I received an end-entity certificate with the CA basic constraint set to FALSE from Thawte. According to RFC 2459, intermediate CAs in a certificate chain SHOULD have a CA basic constraint set to TRUE. According to that document, steps h through m should be applied to all certificates but the leaf certificate when verifying a certificate path. Step i is: (i) Verify that the certificate is a CA certificate (as specified in a basicConstraints extension or as verified out-of-band). ...so this is the point. I'm using my joe-schmoe end-entity certificate as an intermediate certificate, and IE is not doing step i. The vulnerability lies with IE. 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? It's a signature from an end-entity certificate, but IE treats it as a CA 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? IE is vulnerable. There's no reason to have a name constraints extension on an end-entity certificate at all. Anyone verifying the certificate path would trip over the absense of a CA basic constraint before even getting to name constraints. - Mike -- http://www.thoughtcrime.org
