[REVS] Exploiting The XmlHttpRequest Object In IE

From: SecuriTeam (support_at_securiteam.com)
Date: 09/26/05

  • Next message: SecuriTeam: "[NEWS] Gecko based browsers Stack Corruption" 
    To: list@securiteam.com
Date: 26 Sep 2005 12:55:54 +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

    - - - - - - - - -

      Exploiting The XmlHttpRequest Object In IE
    ------------------------------------------------------------------------

    SUMMARY

    XmlHttpRequest is a Javascript object that allows a client side Javascript
    code to send almost raw HTTP requests to the origin host and to access the
    response's body in raw form. As such, XmlHttpRequest is a core component
    of AJAX.

    XmlHttpRequest implementation in IE can be exploited to perform Referer
    spoofing, HTTP Request Smuggling and web-scanning.

    DETAILS

    It seems that the same origin security policy ensures that the power of
    XmlHttpRequest is only used in a secure manner (after all, if the
    Javascript code can only access the server it originated from, then what
    harm can be done, except for XSS conditions), but this is not so. In fact,
    about 2.5 years ago the Amit Klein noticed a problem in XmlHttpRequest's
    implementation in IE - IE doesn't validate some critical fields that are
    provided by the user [1]. Back at that time, the attack vector was through
    an XSS condition, but the basic flaw (and other, related flaws) renders
    itself nicely to other conditions, which we'll see below.

    The techniques discussed below allows the attacker (given the right
    conditions) to perform:
     * Referer spoofing (for leeching and for complete client-side MITM
    attack)
     * HTTP Request Smuggling [5], HTTP Response Splitting [6] and Web cache
    poisoning (see [5] and [6] for details)
     * Accessing content / web-scanning

    Note that Referer is considered (for some reason) to be a good way of
    validating that a browser-using non-malicious client is interacting with
    the site in the "expected" manner, i.e. not via CSRF or embedded frame.
    Referer validation is suggested in [3] to prevent CSRF, and in several
    other sources as a way to prevent leeching (linking to images in other
    sites). In this paper, I prove that given some conditions, the Referer can
    be completely spoofed at the client side, and that pages and images can be
    successfully pulled and displayed using a spoofed Referer (in some
    scenarios). As such, using the Referer can no longer be considered a
    security measure, at least not in HTTP requests (as opposed to HTTPS/SSL).

    Basic technique - retrieving a page with a spoofed Referer:
    The attacker's website is www.attacker.site, the target website is
    www.target.site. The assumption is that the client uses a (cache) forward
    proxy server (not all proxy servers can be used, see discussion below), OR
    that the www.attacker.site and www.target.site are virtually hosted on the
    same IP address.
    The client downloads a page from www.attacker.site. This page contains a
    Javascript code the mounts the attack. The Javascript code exploits the
    XmlHttpRequest object to mount the attack.

    I first demonstrate how a Referer can be spoofed.
    Here's a Javascript code (in the www.attacker.site domain) that can be
    used with IE (henceforth, all examples pertain to IE 6.0 SP2) to send a
    valid Referer and read the page's contents (we assume that the browser
    uses a forward proxy server):

      var x = new ActiveXObject("Microsoft.XMLHTTP");

      
    x.open("GET\thttp://www.target.site/page.cgi?parameters\tHTTP/1.0\r\nHost:\twww.target.site\r\nReferer:\thttp://www.targetsite/somepath?somequery\r\n\r\nGET\thttp://nosuchhost/\tHTTP/1.0\r\nFoobar:","http://www.attacker.site/",false);
      x.send();
      alert(x.responseText);

    Notice the use of HT (Horizontal Tab, ASCII 0x09) instead of SP (Space,
    ASCII 0x20) in the HTTP request line. This is clearly not allowed by the
    HTTP/1.1 RFC (see [2] section 5.1), yet many proxy servers allow this
    syntax, and moreover, will convert HT to SP in the outgoing request (so
    the web server will have no idea that HTs were used).

    Some proxy servers that allow HT as a separator in the request line are:
     - Apache 2.0.54 (mod_proxy)
     - Squid 2.5.STABLE10-NT
     - Sun Java System Web Proxy Server 4.0

    Also notice the HTTP Request Splitting (Ory - this is for you...)
    condition that occurs here. The attacker forces the browser to send 2 HTTP
    requests where it intended to send one. This splitting technique is
    exploited in [3] as part of the HTTP headers (as opposed to the method
    parameter we exploit here).

    If the browser does not use a forward proxy server, and www.target.site
    and www.attacker.site are virtually hosted in the same IP, then the
    following variant may be used:
      var x = new ActiveXObject("Microsoft.XMLHTTP");

      
    x.open("GET\t/page.cgi?parameters\tHTTP/1.0\r\nHost:\twww.target.site\r\nReferer:\thttp://www.target.site/somepath?somequery\r\n\r\nGET\t/\tHTTP/1.0\r\nFoobar:","http://www.attacker.site/",false);
      x.send();
      alert(x.responseText);

    The net result is that two requests are sent to the server, and the
    response from the first one is returned by the browser to the
    XmlHttpRequest object. The code can then embed the returned page in the
    window's html (e.g. document.body.innerHTML=...). Note that the malicious
    Javascript code can first scan the returned page and manipulate it, e.g.
    remove security checks such as "if
    (top.location!='http://www.target.site/...')".

    The problem with images, and how it can be solved:
    The XmlHttpRequest object is suitable for retrieving textual documents,
    such as HTML andd XML pages. However, it is not so useful for retrieving
    binary data, such as images. To begin with, in IE, XmlHttpRequest seems to
    trim the data it returns (via the responseText/responseBody methods) at
    the first null byte. Even if One can work around this (and this may
    perhaps be possible if one sends a Range header to skip the null bytes,
    yet this method is extremely bandwidth and time consuming, to the point
    that it's totally impractical), one doesn't really have anything useful to
    do with the image data - there's no way I know of to tell IE to render
    data as an image (it seems that the "data:" scheme in OBJECT and IMG tags
    is not implemented in IE).

    In this case, one needs to take a different approach. The following will
    only work when the browser uses a *caching* forward proxy server, and the
    image is cacheable by the proxy server.

      var x = new ActiveXObject("Microsoft.XMLHTTP");

      
    x.open("GET\thttp://www.target.site/image.gif\tHTTP/1.0\r\nHost:\twww.target.site\r\nReferer:\thttp://www.target.site/somepath?somequery\r\n\r\nGET\thttp://nosuchhost/\tHTTP/1.0\r\nFoobar:","http://www.attacker.site/",false);
      x.send();
      document.write("<img src='http://www.target.site/image.gif'>");

    The request through the XmlHttpRequest object will be to
    http://www.target.site/image.gif, and as such will be forwarded to
    www.target.site (with the Referer being
    http://www.target.site/somepath?somequery). Later, the browser would parse
    the IMG tag and send a request to http://www.target.site/image.gif, with a
    Referer "http://www.attacker.site/...". However, the cache server already
    has http://www.target.site/image.gif cached, and it will therefore return
    the cached object, and will not forward any request to www.target.site.
    The net result is a single hit on www.target.site with a correct Referer.

    By this I have completed the demonstration of how MITM websites can be
    constructed at the client side, using a correct Referer to fetch the
    original content.

    Notes:
     1. As can be appreciated, the same technique can be used to perform
    "scanning" (CGI scanning and web scanning) on various targets - be they
    public servers or intranet servers. This technique works only if the
    browser uses a proxy server (not necessarily caching). Note that it's
    always possible to force a browser to send a request to any server, a-la
    CSRF ([3]), but in our case, the response is available to the malicious
    script, which is not the case with CSRF.

     2. Likewise, the technique can be used to access materials on non-public
    (intranet) servers. In fact, this vector is mentioned in [4].

     3. In all cases, it is important to note that from the browser's
    perspective, the requests are sent to the www.attacker.site, in the
    attacker.site domain. As such, the browser will not append cookies or
    authentication information belonging to www.target.site to those requests,
    nor will it grant access to the target.site to any scripts found in the
    responses. Therefore, this attack is not XSS.

     4. The victim (human being) may interact with the MITM website,
    disclosing information as the interaction proceeds. One way to limit this
    from happening is (assuming cookies are used to maintain a session) to
    explicitly set the cookie's domain/host, and use the HTTP Set-Cookie
    response header (rather than the META tag or Javascript). Since
    XmlHttpRequest does not grant access to the response headers, this cookie
    cannot be read, and from the browser's perspective, the domain is
    www.attacker.site, those cookies will not be appended to outgoing
    requests.

    Request Smuggling and Response Splitting:
    This discussion is limited to browsers with forward proxy servers. Until
    now, we demonstrated how splitting the request in XmlHttpRequest results
    in a first request that is completely under the attacker's control (up to
    having to use HT instead of SP). The attacker then used in some way the
    first response (either directly, or because it was cached by the proxy
    server).

    However, it is possible to take this technique a step further, and inject
    2-3 requests (on which the attacker has full control). This allows the
    attacker to perform attacks such as HTTP Request Smuggling, and HTTP
    Response Splitting. Note that in order to carry those out, there's a need
    to fully control some caching directives in the requests.

    I also ignored an interesting issue, which is the second request and the
    second response. There are two options:
     1. The attacker may like the second request to (gracefully) terminate the
    TCP connection. In this case, the XmlHttpRequest object will ignore the
    second response, and it will simply "get lost" because the TCP connection
    is terminated. This is desired for the Referer spoofing techniques
    discussed above.

     2. The attacker may like to keep the TCP connection alive, and to take
    the requests and responses out of sync (a-la HTTP Request Smuggling). This
    may enable the attacker to conduct various cross-domain attacks (XSS), and
    this is in fact demonstrated for Firefox in [4] (but I haven't tested it
    on IE). It may also aid in retrieving images with a proper Referer, in
    case the proxy server does not cache the objects that pass through it, or
    in case the images are not cacheable.

    Mozilla/FireFox:
    I focused mainly on IE (tested IE 6.0 and 6.0 SP2), so I don't have a lot
    of results on Mozilla/FireFox. I suspect it is vulnerable to the same
    technique, possibly even more so since I suspect it allows SP in the
    method parameter.

    Conclusions:
     - In some cases, the Referer header can be completely spoofed (at the
    client side).
     - Even when the request looks genuine, the browser may have emitted it
    from the "wrong" domain.

    Recommendations:
    Site owners
     - Use SSL (as always).
     - Do not use virtual hosting with other, non-trustable domains.
     - Don't rely on client side code to prevent cloning/MITM - the attacker
    may scan and remove this code.
     - Don't rely on Referer.
     - Set explicit host/domain in cookie, and verify that the cookie is sent
    back, as early as possible (ideally before sensitive data is requested
    from the user).

    Vendors
     - Microsoft is encouraged to filter HT, CR and LF in the method
    parameter (HT filtering was recommended in [1] 2.5 years ago). Other
    browser vendors are encouraged to check whether their implementation is
    vulnerable.
     - Proxy server vendors are encouraged not to allow raw HT in the request
    line.

    References
    [1] " <http://www.securityfocus.com/archive/107/308433> XS(T) attack
    variants which ca, in some cases, eliminate the need for TRACE", Amit
    Klein, WebAppSec mailing list submission, January 26th, 2003

    [2] " <http://www.tux.org/~peterw/csrf.txt> Cross-Site Request Forgeries",
    Peter W[atkins?], June 13th, 2001 <

    [3] " <http://www.ietf.org/rfc/rfc2616.txt> Hyper Text Transfer Protocol -
    HTTP/1.1"

    [4] "setRequestHeader can be exploited using newline characters", Bugzilla
    bug <https://bugzilla.mozilla.org/show_bug.cgi?id=297078> 297078 302263

    [5] " <http://www.watchfire.com/resources/HTTP-Request-Smuggling.pdf> HTTP
    Request Smuggling", Chaim Linhart, Amit Klein, Ronen Heled, Steve Orrin.

    [6] "
    <http://www.packetstormsecurity.org/papers/general/whitepaper_httpresponse.pdf> Divide and Conquer - HTTP Response Splitting, web Cache poisoning and Related Topics", Amit Klethe author

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:aksecurity@hotpop.com> Amit
    Klein (AKsecurity).

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

    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: "[NEWS] Gecko based browsers Stack Corruption"

    Relevant Pages