ACROS Security: Poisoning Cached HTTPS Documents in Internet Explorer

From: ACROS Security (lists_at_ACROS.SI)
Date: 10/13/04

  • Next message: Russ: "MS04-028 Enterprise Scanning Tool KB location"
    Date:         Wed, 13 Oct 2004 12:21:25 +0200
    To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM
    
    

    Below please find our public report for the HTTPS cache poisoning issue in
    Internet Explorer. It includes workarounds for server operators, allowing
    them to protect their web services without having to rely on users to patch
    their browsers.

    Regards,

    ACROS Security
    http://www.acrossecurity.com

    =====[BEGIN-ACROS-REPORT]=====

    PUBLIC

    =========================================================================
    ACROS Security Problem Report #2004-10-13-1
    -------------------------------------------------------------------------
    ASPR #2004-10-13-1: Poisoning Cached HTTPS Documents in Internet Explorer
    =========================================================================

    Document ID: ASPR #2004-10-13-1-PUB
    Vendor: Microsoft (http://www.microsoft.com)
    Target: Internet Explorer
    Impact: Arbitrarily modifying the content of HTTPS pages shown
                     in Internet Explorer
    Severity: High
    Status: Official patch available, workarounds available
    Discovered by: Mitja Kolsek of ACROS Security

    Current version
       http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt

    Summary
    =======

    Under specific circumstances, Internet Explorer does not warn the user about

    an invalid server SSL certificate. This allows an attacker to "poison" a
    user's browser cache with a malicious document that will later be used from
    cache when the user visits the legitimate site. Furthermore, once the user
    is
    on the legitimate site and the malicious document is used from browser's
    cache, even manual inspection of the document's certificate will not reveal
    anything suspicious - in contrast to most other SSL content-faking
    vulnerabilities, where manual certificate inspection alerts the user about
    the
    attack.

    The attacker can exploit this vulnerability for "replacing" HTML documents,
    images, script files (.js), cascading style sheet files (.css) and other
    static documents on a legitimate secured web server, thereby possibly
    completely compromising the component of its security provided by the SSL
    protocol.

    Product Coverage
    ================

    - Internet Explorer 6 - affected

    All patches applied, up to and excluding Cumulative Security Update for
    Internet Explorer (834707).
    Note: Windows XP Service Pack 2 resolves the issue on Windows XP.

    Other versions may also be affected.

    Analysis
    ========

    In 1999, our company has informed Microsoft about a vulnerability [1] in
    Internet Explorer that allowed the attacker to force IE to communicate with
    a
    malicious web server over HTTPS without the browser issuing a warning about
    an
    invalid SSL certificate used by that server. To summarize, IE did not check
    the validity of SSL certificates for (1) connections with web servers with
    which a successful SSL connection has previously been established, and for
    (2)
    connections established via images or (i)frames. Microsoft has subsequently
    fixed both aspects of this vulnerability.

    Recently, we've discovered a somewhat similar security problem in Internet
    Explorer, although one which does not pose such an obvious threat. Under
    certain circumstances, Internet Explorer again doesn't perform all three of
    the required SSL certificate validations.

    The threat is not obvious since it is very unlikely that a secure production

    site would provide such circumstances. However, we have found an attack
    vector
    that allows the attacker to "replace" arbitrary static documents on a
    secured
    web server using only DNS spoofing and little or no social engineering.
    Furthermore, the attack can take place any time before the user actually
    visits the "attacked" web server (note: actually, the browser is attacked,
    not
    the server), and the user may even restart his computer in between.

    The key to the attack is browser's cache (temporary internet files). IE by
    default caches all documents except those which web servers instruct it not
    to
    cache. While there is a "Do not save encrypted pages to disk" option in IE,
    it
    is turned off by default, which means that HTTPS documents are cached by
    default.

    When a web server includes a "Last-Modified" header in its response
    containing
    a document, IE remembers its value and when it subsequently needs the same
    document again, includes an "If-Modified-Since" header in its request for
    the document. The web server, receiving an "If-Modified-Since" header,
    checks
    whether the document it hosts is newer than the one browser claims it has
    cached, and sends the document to browser only if it is newer - otherwise,
    it
    returns a "304" (meaning "Not Modified") response, instructing the browser
    to
    use the locally cached copy.

    Using the discovered vulnerability in IE, the attacker can covertly "poison"

    browser's cache with a fake document that seemingly comes from a legitimate
    secured web server while the user opens a page on a malicious web server.
    This
    fake document can be used to effectively replace an image or HTML (e.g., a
    login form) on the legitimate server, or even to introduce a malicious
    script
    that will, for example, steal visitors' credentials and send them to the
    attacker.

    What the attacker needs to do in order to execute the attack is this:

    1. Temporarily poison the user's DNS server or send a fake DNS response to
    the
    user's browser ("man in the middle") to redirect requests for the legitimate

    secured web server to a malicious web server.

    2. Set up a malicious web server hosting a fake document that will poison
    the
    user's browser cache.

    3. Make the user's browser visit the malicious web server, either using
    social
    engineering or by modifying the HTTP traffic from/to the browser ("man in
    the
    middle").

    4. Wait for the user to visit the legitimate secured web site where the fake

    document will be used instead of the real one, possibly introducing
    malicious
    scripts, fake images or fake text.

    Two important facts distinguish this attack from many other attacks on SSL-
    protected sites:

    A. The active component of the attack takes place before the user actually
    visits the targeted web site (e.g., a web-banking site). No attacker's
    activity is required during the user's visit of the legitimate ("spoofed")
    web
    site. Furthermore, there can be a long pause between steps 3 and 4 above,
    during which the user can restart his computer any number of times. The only

    serious limitation is that the user must not manually delete the browser's
    cache (and hence the fake document) during this period.

    B. Once on the legitimate secured site, the user has no way to determine
    that
    a fake document (be it an image or an HTML document) is not legitimate -
    even
    a manual SSL certificate inspection will show that the document has come
    from
    the legitimate server. This is, by the way, not the case in most "URL
    obfuscation" attacks that only modify the apparent URL for web sites or
    documents and try to trick the user into believing that he is actually
    visiting some other site - these attacks can generally be detected at least
    by
    manual certificate inspection.

    Some additional notes regarding this vulnerability:

    - While it may be tempting to think that the described attack requires quite
    a
    resourceful attacker (poisoning DNS response, getting the user to visit a
    malicious web server), we should remember that SSL (and HTTPS) protocol is
    being used for defending against this exact type of attacker - the attacker
    being able to monitor and possibly modify network traffic between browser
    and
    server.

    - The attacker can use any web server certificate issued by any one of the
    IE's trusted issuers (currently 109 of them!), which can be long expired and

    issued for any host name. A useable certificate can also be bought by any
    commercial trusted CA like Verisign or Thawte.

    - It seems that IE will always send en explicit GET for the first request in

    an HTTPS connection - for example, in case of index.html with three inline
    images, index.html will be, as the first request, requested unconditionally
    (i.e., without "If-Modified-Since" header), while the images will be
    requested
    with "If-Modified-Since" header. Consequently, it is easier to successfully
    poison documents that are loaded from another document, e.g., images, script

    files or style sheet files. However, HTML documents can also be successfully

    poisoned as long as they're not the first to be requested over an HTTPS
    connection.

    - Malicious scripts can also be introduced via fake cascading style sheets.

    - The attacker can only poison sites that respect "If-Modified-Since"
    headers.
    Furthermore, the attacker can only poison documents (HTML documents, images,

    .JS files etc.) that the web server considers static and therefore subject
    to
    "If-Modified-Since" logic.

    - It makes no difference if the targeted web server tries to make sure its
    pages aren't written to browser's cache (using cache-related HTTP response
    headers). The attacker's malicious server will always be able to demand its
    fake page to be cached and there's nothing the legitimate web server can do
    to
    prevent it.

    - Caching HTTP proxy servers in general have no effect on this vulnerability
    as HTTPS sessions run through them encrypted. Proxy servers that actually
    decrypt and re-encrypt the traffic can either mitigate, or even escalate
    the issue, depending on their logic.

    Mitigating Factors
    ==================

    1) Browsers with the "Do not save encrypted pages to disk" option enabled
    are
    not affected by this issue as the fake document(s) can't be written to
    browser's cache.

    2) Web servers that ignore browser's "If-Modified-Since" header and always
    send the requested document are not "spoofable" using this vulnerability.

    Solution
    ========

    Cumulative Security Update for Internet Explorer (834707) was released,
    which
    fixes this issue. Affected users can install it via Windows Update or by
    downloading it from
    http://www.microsoft.com/technet/security/bulletin/ms04-038.mspx

    Note that Windows XP Service Pack also fixes this issue on Windows XP.

    Workarounds
    ===========

    Browser
    -------

    Turning the option "Do not save encrypted pages to disk" on will disable the

    cache poisoning attack. Deleting the browser's temporary files is advised
    afterwards to remove any malicious documents.

    Servers
    -------

    If you're running a critical web site and don't want to rely on your
    visitors
    to install the patch, implement a workaround or even know about this issue,
    there are steps you can take to protect them. As the described attack relies

    on the fact that the browser will (re)use a cached page when the web server
    responds with "304 - Not Modified" response, preventing the server from ever

    sending such a response will thwart it. Following, we provide specific
    solutions for IIS and Apache web servers. All solutions are aimed at
    removing
    "If-Modified-Since" headers from browsers' requests, effectively bypassing
    server's "Not Modified" functionality.

    Internet Information Services
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    We wrote a simple, minimum overhead ISAPI filter (24 lines of code) that
    intercepts browsers' requests and removes any "If-Modified-Since" headers
    from
    it. The filter is available on our web site at
    http://www.acrossecurity.com/aspr/misc/if-modified-since-eliminator.zip
    (Visual C++ project)

    [Remember to always review the source code before using it!]

    Apache 1.3
    ~~~~~~~~~~
    Edi Weitz from Germany wrote a simple Apache module called
    mod_header_modify,
    specifically intended for changing incoming HTTP headers. This module can be

    used for eliminating "If-Modified-Since" headers from incoming requests
    using
    the following directives in httpd.conf:

    HeaderModify on
    HeaderModifyRemove If-Modified-Since

    mod_header_modify module can be downloaded from
    http://weitz.de/mod_header_modify.html
    Note: Apache must be built with DSO support.

    [Remember to always review the source code before using it!]

    Apache 2.0
    ~~~~~~~~~~
    Apache 2.0 already comes with mod_headers module. Rebuild Apache with this
    module included and use the following directive in httpd.conf:

    RequestHeader unset If-Modified-Since

    Acknowledgments
    ===============

    We would like to acknowledge Microsoft Security Response Center for prompt
    and professional response to our notification of the identified
    vulnerability.

    References
    ==========

    [1] ACROS Security, "Bypassing Warnings For Invalid SSL Certificates In
        Internet Explorer"
        http://www.acrossecurity.com/aspr/ASPR-1999-12-15-1-PUB.txt

    Company Information
    ===================

    ACROS d.o.o.
    Makedonska ulica 113
    SI - 2000 Maribor

    e-mail: security@acrossecurity.com
    web: http://www.acrossecurity.com
    phone: +386 2 3000 280
    fax: +386 2 3000 282

    ACROS Security PGP Key
       http://www.acrossecurity.com/pgpkey.asc
       [Fingerprint: FE9E 0CFB CE41 36B0 4720 C4F1 38A3 F7DD]

    ACROS Security Advisories
       http://www.acrossecurity.com/advisories.htm

    ACROS Security Papers
       http://www.acrossecurity.com/papers.htm

    ASPR Notification and Publishing Policy
       http://www.acrossecurity.com/asprNotificationAndPublishingPolicy.htm

    Disclaimer
    ==========

    The content of this report is purely informational and meant only for the
    purpose of education and protection. ACROS d.o.o. shall in no event be
    liable for any damage whatsoever, direct or implied, arising from use or
    spread of this information. All identifiers (hostnames, IP addresses,
    company names, individual names etc.) used in examples and demonstrations
    are used only for explanatory purposes and have no connection with any
    real host, company or individual. In no event should it be assumed that
    use of these names means specific hosts, companies or individuals are
    vulnerable to any attacks nor does it mean that they consent to being used
    in any vulnerability tests. The use of information in this report is
    entirely at user's risk.

    Revision History
    ================

    October 13, 2004: Initial release

    Copyright
    =========

    (c) 2004 ACROS d.o.o. Forwarding and publishing of this document is
    permitted providing the content between "[BEGIN-ACROS-REPORT]" and
    "[END-ACROS-REPORT]" marks remains unchanged.

    =====[END-ACROS-REPORT]=====

    --
    NTBugtraq Editor's Note:
    Want to reply to the person who sent this message? This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you'll have to copy their email address out of the message and place it in your TO: field.
    --
    

  • Next message: Russ: "MS04-028 Enterprise Scanning Tool KB location"

    Relevant Pages

    • RE: Is this as bad as it seems?
      ... The network being protected by the router or firewall is still vulnerable to ... > circumvented - the administrator has explicitly allowed HTTP traffic on ... this exploit has the effect of allowing the attacker to send *INBOUND* HTTP ... The HTTP server (located on the internal network or anywhere else that is ...
      (Security-Basics)
    • [NEWS] Firewall Circumvention Possible with All Browsers
      ... The exploit allows an attacker to use any JavaScript-enabled web browser ... any HTTP server behind the firewall. ... outlined in the section "Quick-Swap DNS". ... If the client in use is Microsoft Internet Explorer, ...
      (Securiteam)
    • [NT] Unchecked Buffer in Network Share Provider Can Lead to Denial of Service
      ... SMB (Server Message Block) is the protocol Microsoft uses to share files, ... The attacker could use both a user account and anonymous access to ... What's the scope of the vulnerability? ...
      (Securiteam)
    • ACROS Security: Poisoning Cached HTTPS Documents in Internet Explorer
      ... It includes workarounds for server operators, ... Poisoning Cached HTTPS Documents in Internet Explorer ... user's browser cache with a malicious document that will later be used from ... The attacker can exploit this vulnerability for "replacing" HTML documents, ...
      (Bugtraq)
    • RE: Private addresses on public network
      ... anybody accesses those computers from an external network," -- even when the ... JavaScript delivered to the client that causes the client to retrieve ... the attacker, the request results in another JavaScript response that tells ... Moving beyond a single server ...
      (Security-Basics)