lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1195415025.5999.33.camel@tpol.lan>
Date: Sun, 18 Nov 2007 20:43:45 +0100
From: Nils Toedtmann <securityfocus@...s.toedtmann.net>
To: Bugtraq <bugtraq@...urityfocus.com>
Subject: 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ