Lucene search

K
securityvulnsSecurityvulnsSECURITYVULNS:DOC:18452
HistoryNov 19, 2007 - 12:00 a.m.

ertificate spoofing with subjectAltName and domain name wildcards

2007-11-1900:00:00
vulners.com
159

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

###########################################################################

Phishing for Confirmations

Certificate spoofing with subjectAltName and domain name wildcards

###########################################################################

URL:      <http://nils.toedtmann.net/pub/subjectAltName.txt>
Version:  2007-11-16-07
Author:   Nils Toedtmann <[email protected]>
License:  Dual Creative Commons BY-ND & BY-NC-SA (see below)

Disclaimer

This is not an advisory but a reproval. These issues have been discussed for
years now at mozilla.org. But the developers seem to underestimate or ignore
their severeness, particularly when being combined. Additionally i found
(probably not at first) that more browsers are affected.

Abstract

Modern browsers accept more than one (wildcard) domain name within a X.509
certificate, although displaying only one of them (the DN's CN) to the user.
It is essential for preventing TLS-enriched domain name spoofing to bind
user-approved certificates from unknown CAs to the presenting hostname.

Mozilla based browsers, Konqueror and Safari 2 fail that binding, so once a
user accepted a certificate issued by a CA unknown to the browser, he is
vulnerable to certificate spoofing.

To make things worse, some browsers match generic wildcard domain names
like *.com or even *.

There's a demonstration at <http://test.eonis.net/&gt;, check it out.

Introduction

There were and are and will be many ways to trap browser to a false web server
with a spoofed hostname. For example DNS spoofing [1], domain name hijacking
[2] or other man-in-the-middle attacks [3].

Domain name authentication through X.509 certificates is an additional line of
defense against browser-external phishing attempts as the phisher cannot spoof
the TLS-handshake with the original certificate. But this defense only holds
if browser and user handle certificates properly.

B.t.w: Even correctly handled certificates do not protect against similar-
hostname-attacks [4] or in-browser attacks like location bar manipulation [5].

subjectAltName

The X.509 standard [6] defines the certificate extension "subjectAltName". It
can be used to supply additional information about the certificate's subject.
When used for TLS, certificates can carry only one domain name in the
subject's DN ("distinguished name") field CN ("common name"), so additional
domain names are stored as subjectAltName:dNSName. (Some implementations
accept more than one CN in a DN, but that's uncommon.)

Modern browsers respect this. They consider a X.509 certificate valid for
a web server only if the CN part of the certificate's subject DN or one of
the subjectAltName:dNSName extensions matches the web server's hostname
(Some browsers ignore the CN if a subjectAltName:dNSName is present). As long
as the TLS extension "server name indication" (SNI) [7] is not widely adopted
by clients and servers, this is a useful method for virtual HTTPS hosting.

If a HTTPS-server presents a certificate during the TLS handshake but its
issuer is not in the browser's list of accredited trustworthy CAs, the browser
raises a warning. The user may decide to accept the certificate (temporarily
or permanently by installing it into the browser's certificate storage) and
to proceed.

Unfortunately, no major browser displays existing subjectAltName:dNSName fields
in the standard certificate view dialog, although subjectAltName:dNSName has
become equivalent to the displayed subject's CN. The user has do dive deeply
into the "certificate details" to detect bogus subjectAltNames.

When a second (virtual) HTTPS-server (different hostname, same or different IP
address) presents the same certificate, the browser SHOULD raise the "unknown
issuer" warning again, even if the hostname matches one of the certified
domain names. If the browser fails in binding user-approved certificates to the
originating hostname the user won't notice certificate spoofing. Unfortunately,
RFC 2818 (HTTPS) [8] does not cover this case.

Domain name wildcards

Subject's CN and subjectAltName may be wildcard domain names like
*.example.com. Wildcard matching is not specified in RFC 3280 but RFC 2818:

"Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., .a.com matches foo.a.com but
not bar.foo.a.com. f
.com matches foo.com but not bar.com."

So "loose matching" like www.test.example.com=.example.com or
www.example.com=
.com or example.com=* violates RFC 2818.

And though standard compliant, matching "generic wildcards" like top- or
second-level wildcards (museum.=, example.com=.com) or third-level wildcards
within generic SLDs (example.co.uk=*.co.uk) should be considered bad practice.

Accepting certificates permanently

If a user visits a HTTPS server with a unknown-issuer-cert regularly, she may
wish to avoid the "unknown issuer" warning. A browser SHOULD offer the option
to store the web server's certificate permanently. Both alternatives -
accepting the cert on each connect temporarily or storing and trusting the
parent CA certificate permanently - are less secure. The former does not
protect against certificate spoofing on subsequent connects, the latter also
trusts all other certificates issued by that CA.

Of course the web server's certificate should be bound to it's hostname again.

The real world: results by bug

  • [loose-wildcard-match]
    Matching the wildcard "*" with the dot (which is a violation of standards)
    and/or matching SLD and TLD wildcards is a minor security issue, but it
    aggravates the next two.

    Results: Mozilla based browsers, Safari 2 and Opera suffer from it. All
    major browsers match wildcards in generic SLDs like "*.co.uk".

  • [subjectAltName-not-shown]
    Not displaying existing subjectAltNames in the standard certificate view
    is - alone - a slight security issue. But it worsens the next one as the
    user has almost no chance to notice a spoofing attempt.

    Results: All tested browsers suffer from this.

  • [no-cert-name-binding]
    Not binding user-approved certificates to the originating hostname is a
    major bug which enables certificate spoofing. Results:

    Results: Browsers based on Mozilla <=1.9a8, Konqueror, and Safari 2 are
    affected.

  • [servercert-storage]
    Lacking this feature is not a bug but leads to less secure certificate
    handling. Results:

    Opera cannot store web server certificates. MSIE and Safari can, but that
    does not eliminate the "unknown issuer" warnings.

    This time the points go to Mozilla & Konqueror, at least ;)

Results by browser

  • Mozilla based

    loose-wildcard-match: Affected [9, #159483 from 07/2002]
    subjectAltName-not-shown: Affected [9, #238142 from 03/2004]
    no-cert-name-binding: AFFECTED! (>=1.9 not) [9, #240261 from 04/2004]
    servercert-storage: Yes

    Note: Mozilla 1.9 (>= M9) incorporates a new, sophisticated version of its
    certificate manager "Personal Security Manager" (PSM) which binds certs to
    hostnames. Upcoming Firefox 3 will be based on this.

    Vendor status: #402347 filed on 2007/11/03, declared DUPE of #240261
    (filed 2004/04/11), fixed in Mozilla-1.9/Firefox-3 [#327181], declared
    WONTFIX for Mozilla-1.8/Firefox-2 [#402347 comment #4].

    • Firefox 2.0.0.8 (FreeBSD, Linux), 2.0.0.9 (Win32)
    • Firefox 3.0 Alpha (3.0a8/Linux, 3.0a7/Win32)
    • Minefield 3.0a9pre (Windows) (not affected by [no-cert-name-binding])
    • Iceweasel 2.0.0.7
    • IceApe 1.1.5
    • Netscape 9.0 (Win32)
    • SeaMonkey 1.1.5 (Win32)
    • Epiphany 2.18.1
    • K-Meleon 1.12
  • Konqueror

    loose-wildcard-match: - (but matches wildcards in generic SLDs)
    subjectAltName-not-shown: Affected
    no-cert-name-binding: AFFECTED!
    servercert-storage: Yes

    Note: Konqueror does not show any certificate extension (like
    subjectAltName), not even in the details.

    Vendor status: Bug report sent to <[email protected]> on 2007/11/06,
    issue under investigation at kde.org.

    • Konqueror 3.5.5 [ToDo: 3.5.8], 3.95.00 (=4.0 Beta4)
  • Safari

    loose-wildcard-match: - [ToDo: S3/MacOS] [Safari2: Affected]
    subjectAltName-not-shown: Affected
    no-cert-name-binding: - [Safari2: AFFECTED!]
    servercert-storage: See note

    Note: Safari actually can store webserver certs, but without trusting
    the parent CA cert that does not eliminate "unknown issuer" warnings.

    Safari 3 Public Beta for Windows has no own certificate storage but uses
    Windows' certificate list and validation mechs, so see MSIE instead.

    Vendor status: Reply from the Apple Product Security team: "There is no
    plan to address this in Safari 2. Safari 3 is recommended for all Safari 2
    users and is available as a free upgrade as part of 10.4.11."

    • Safari 2.0.4 (MacOS 10.4.10/WebKit 419.3)
    • Safari 3.0.4 (MacOS 10.4.11/WebKit 523.12, MacOS 10.5/WebKit 523.10.3)
    • Safari Public Beta for Windows 3.0.4 (Win32/WebKit 523.12.9)
  • Opera

    loose-wildcard-match: Affected
    subjectAltName-not-shown: Affected
    no-cert-name-binding: -
    servercert-storage: Missing

    Note: Opera has no option to install a web server certificate but makes
    installing the parent CA cert very easy (2 clicks). This misleads users
    annoyed by warnings to do so.

    • Opera 9.0.23 (Linux)
    • Opera 9.0.24 (Win32)
  • MSIE

    loose-wildcard-match: - (but matches wildcards in generic SLDs)
    subjectAltName-not-shown: Affected
    no-cert-name-binding: -
    servercert-storage: Missing (see note #1)

    Note 1: MSIE can actually store web server certificates, but without
    trusting the parent CA cert that does not eliminate "unknown issuer"
    warnings.

    Note 2: If there is a problem with the web server's certificate, MSIE7
    just says that "there is some problem". If you want to view the cert, or
    to know the nature of the problem (maybe the cert just expired?) you have
    to proceed. When you then realize that the CA is wrong, the cookie is
    stolen already.

    Note 3: Microsoft's attitude "There's a problem, but you do not need
    to know what kind of a problem. Abort (recommended) or proceed?" is really
    counterproductive and will not raise security awareness amongst users. In
    fact, users get trained to ignore security alerts. But that's another
    story…

    • MSIE 6.0.2900.2180 (WinXP Pro SP2)
    • MSIE 7.0.5730.11 (WinXP Pro SP2)
    • MSIE 7 (Windows Vista Ultimate) [ToDo: exact version]

Sources

[1] Recent DNS spoofing issues
CVE-2007-2930: <http://www.trusteer.com/docs/bind8dns.html&gt;
CVE-2007-2926: <http://www.trusteer.com/docs/bind9dns.html&gt;
MS07-062 <http://www.microsoft.com/technet/security/bulletin/ms07-062.mspx&gt;

[2] DE-registry press releases about the hijacking of eBay.de and google.de
<http://www.denic.de/en/denic/presse/press_60.html&gt;
<http://www.denic.de/de/denic/presse/press_79.html&gt; (German)

[3] dsniff <http://monkey.org/~dugsong/dsniff/&gt;
ettercap <http://ettercap.sourceforge.net/&gt;

[4] IDN homograph spoofing
<http://www.shmoo.com/idn/homograph.txt&gt;

[5] Recent URL spoofing issues CVE-2007-3656, CVE-2007-3826, CVE-2007-3819
<http://www.heise-security.co.uk/news/92725&gt;

[6] RFC 3280: "Internet X.509 Public Key Infrastructure"
<http://www.ietf.org/rfc/rfc3280.txt&gt;

[7] RFC 3546: "Transport Layer Security (TLS) Extensions" (SNI)
<http://www.ietf.org/rfc/rfc3546.txt&gt;

[8] RFC 2818: "HTTP Over TLS" (HTTPS)
<http://www.ietf.org/rfc/rfc2818.txt&gt;

[9] Mozilla bugtracker
#159483: "cert name matching: RFC 2818 vs. backwards compatibility"
<https://bugzilla.mozilla.org/show_bug.cgi?id=159483&gt;

#238142: &quot;server mismatch dialog doesn&#39;t show subject alt names&quot;
&lt;https://bugzilla.mozilla.org/show_bug.cgi?id=238142&gt; &#40;not public&#41;

#240261: &quot;peer-trusted certs can use alt names to spoof&quot;
&lt;https://bugzilla.mozilla.org/show_bug.cgi?id=240261&gt;

#327181: &quot;Improve error reporting for invalid-certificate errors&quot;
&lt;https://bugzilla.mozilla.org/show_bug.cgi?id=327181&gt; &#40;#28, #51, #72&#41;

#402347: &quot;Not binding X.509 certificate to originating domain name allows
certificate spoofing&quot; &#40;dupe of #240261, but public&#41;
&lt;https://bugzilla.mozilla.org/show_bug.cgi?id=402347&gt;

ToDo

  • Translate into proper English
  • Test more browsers (Camino) and other TLS clients like MUAs
  • Check MSIE for reg-hacks to alter cert handling
  • Actually read the referenced sources ;)
  • Find a braindead major-browser-accredited CA which signs my certificate
    request with hidden TLD-wildcard subjectAltName. Take over the internet.

License

This document is dual licenced under the Creative Commons licenses BY-ND 3.0
and BY-NC-SA 3.0, so you may distribute it unaltered. For noncommercial
purposes you may do anything you want unless you credit me and keep the
BY-NC-SA license. See

&lt;http://creativecommons.org/licenses/by-nd/3.0/&gt;
&lt;http://creativecommons.org/licenses/by-nc-sa/3.0/&gt;

About me

My name is Nils, and i am yet another paranoid network admin. Contact:

&lt;[email protected]&gt; 
$ whois toedtmann.net | grep owner-c

Credits

123456789|123456789|123456789|123456789|123456789|123456789|123456789|123456789
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHQFtVWSNYFlGcTrMRAuinAJ4zinO74OeoEhGnRU9TAOsZXgSmxQCfb3wr
Ob8/FNQThEHekHFjhdne9N8=
=3jmj
-----END PGP SIGNATURE-----