Certificate spoofing issue with Mozilla, Konqueror, Safari 2



Moin *

Mozilla based browsers (Firefox, Netscape, ...), Konqueror and Safari 2
do not bind a user-approved webserver certificate to the originating
domain name. This makes the user vulnerable to certificate spoofing by
"subjectAltName:dNSName" extensions.

I set up a demonstration at <http://test.eonis.net/>, check it out. For
details (vulnerable versions, vendor status, bug ids ...) see

<http://nils.toedtmann.net/pub/subjectAltName.txt>

Attack scenario:

(1) Assumed a phisher could redirect a user's browser to his prepared
https webserver spoofing "www.paypal.com" (by DNS spoofing or domain
hijacking or other MITM attack). But the user's browser would raise
an "unknown CA" warning because the phisher does not have a
certificate for "www.paypal.com" issued by a browser-trusted CA
(that's what X.509 and TLS is all about!). Thus, the phisher defers
this step.

(2) The phisher creates another website "www.example.com" (not spoofed)
and a home brewed X.509 cert:

DN="CN=www.example.com"
subjectAltName:dNSName=www.example.com
subjectAltName:dNSName=www.paypal.com

and lures the user to https://www.example.com/. The user gets an
"unknown CA" warning, but the "subjectAltName:dNSName" extensions
are not shown to him, so the cert looks ok. As he does not plan to
enter any private information, he accepts it (temporarily or
permanently) and proceeds.

(3) Any time later (if the cert got accepted temporarily this has to
happen within the same session), the phisher lures the user to his
spoofed https://www.paypal.com/, using the very same self-signed
certificate - NO WARNING!

In the end, the cert warning and the spoofing attempt get separated into
two events which appear to the user as being unrelated. I consider this
a severe cert-spoofing issue, aggravated by the fact that affected
browsers also match any hostname with "subjectAltName:dNSName=*".

For Mozilla, this issue is known for more than three years without being
fixed.

Regards, /nils.



Relevant Pages

  • Re: HTTPS proxy tool that resigns SSL certs
    ... having access to import a certificate into the browser. ... Your approach won't work, since your cert for attacker.com will most likely never match the URL that the victim's browser is expecting, and they will get a warning. ... Everything hinges on your being able to get a cert THAT MATCHES THE SITE THAT THE VICTIM IS GOING TO signed with a key that the browser will accept and valid for the current date. ... Compromise a recognised CA's verification checks to convince them to issue you a certificate for the target site. ...
    (Pen-Test)
  • [Full-disclosure] Certificate spoofing issue with Mozilla, Konqueror, Safari 2
    ... This makes the user vulnerable to certificate spoofing by ... Assumed a phisher could redirect a user's browser to his prepared ... so the cert looks ok. ...
    (Full-Disclosure)
  • Re: [Full-disclosure] [HV-PAPER] Anti-Phishing Tips You ShouldNotFollow
    ... The Cert box is nearly impossible to spoof because you would have to spoof ... second SSL cert for the real bank host name. ... and wrote the bottom of the browser to ... It is possible that the Codefish technique could work if the Pharming was active during the bookmarking when checking the certificate credentials. ...
    (Full-Disclosure)
  • RE: HTTPS proxy tool that resigns SSL certs
    ... Is it possible to get the same cert from two different ... CA's which are trusted by the browser i.e let's say my site is www.foo.com ... having access to import a certificate into the browser. ... THAT THE VICTIM IS GOING TO signed with a key that the browser will ...
    (Pen-Test)
  • RE: Checkpoint smart defance as IPS
    ... the browser trusts all certificate authorities ... *any* SSL/TLS communication without tampering anything on the client ... website a client visits on-the-fly. ...
    (Security-Basics)