[NT] Poisoning Cached HTTPS Documents in Internet Explorer

From: SecuriTeam (support_at_securiteam.com)
Date: 10/17/04

  • Next message: SecuriTeam: "[REVS] Common Firewall Configuration Errors" 
    To: list@securiteam.com
Date: 17 Oct 2004 15:56:41 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Poisoning Cached HTTPS Documents in Internet Explorer
    ------------------------------------------------------------------------

    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 *** 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.

    DETAILS

    Vulnerable Systems:
     * All patches applied, up to and excluding Cumulative Security Update for
    Internet Explorer (834707).

    Immune Systems:
     * Windows XP Service Pack 2 resolves the issue on Windows XP.

    For more vulnerable systems see Microsoft's advisory at:
    <http://www.securiteam.com/windowsntfocus/6X00G0UBGY.html> Cumulative
    Security Update for Internet Explorer (MS04-038)

    CVE Information:
     <http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0845>
    CAN-2004-0845

    In 1999, ACROS company has informed Microsoft about a
    <http://www.acrossecurity.com/aspr/ASPR-1999-12-15-1-PUB.txt>
    vulnerability 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
    (2) connections established via images or (i)frames. Microsoft has
    subsequently fixed both aspects of this vulnerability.
    Recently, ACROS 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 usable 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 *** 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:
     * 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.
     * Web servers that ignore browser's "If-Modified-Since" header and always
    send the requested document are not "spoofable" using this vulnerability.

    Solution:
    Microsoft released
    <http://www.microsoft.com/technet/security/bulletin/ms04-038.mspx>
    Cumulative Security Update for Internet Explorer (834707) which addresses
    this issue.
    Note that Windows XP Service Pack 2 also fix this issue on Windows XP.

    Workarounds:
    Browsers - 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 - ACROS 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:
    <http://www.acrossecurity.com/aspr/misc/if-modified-since-eliminator.zip>
    here
    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>
    http://weitz.de/mod_header_modify.html
    Note: Apache must be built with DSO support.
    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

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:lists@acros.si> ACROS
    Security.
    The original article can be found at:
    <http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt>
    http://www.acrossecurity.com/aspr/ASPR-2004-10-13-1-PUB.txt

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[REVS] Common Firewall Configuration Errors"

    Relevant Pages