Re: TRACE used to increase the dangerous of XSS.

From: Peter Watkins (peterw@usa.net)
Date: 01/23/03

  • Next message: Jonathan Hunter: "DoS attack on Windows 2000 Terminal Server" 
    Date: Thu, 23 Jan 2003 15:28:24 -0500
From: Peter Watkins <peterw@usa.net>
To: Thor Larholm <thor@pivx.com>

    On Thu, Jan 23, 2003 at 10:10:49AM +0100, Thor Larholm wrote:

    > I just finished reading this so-called whitepaper and the press release, and
    > all I can say is hyped, sensationalised snakeoil.

    > What we end up with from WhiteHat Security is a way to circumvent the
    > HttpOnly cookie feature in IE6SP1, nothing else.

    Really? WhiteHat also claims to have had some similar success with Mozilla,
    so it might not be simply an IE issue. (Exploit code for Mozilla would be
    nice.)

    1) The whitepaper does raise the obvious question --for all admins-- of what
    HTTP protocol methods should be enabled on their sites. TRACE is explicitly
    designed for debugging (RFC 2616 section 9.8), and probably isn't needed by
    any production Web site. Most servers are not expected to service anything
    other than GET, POST, and HEAD requests. It seems only prudent to configure
    http server software to only provide the methods that are required.

    2) It's much easier for a concerned site admin to disable TRACE on servers
    that may see sensitive request headers than for the clients to be fixed
    everywhere. It's fine to lay blame on the client software programmers, but
    better still to protect users when feasible.

    3) Regarding the domain restriction security policies, I wish someone would
    clarify the rules clients follow, especially vis-a-vis http vs https
    requests. A man-in-the-middle or DNS attacker could obviously forge or
    tamper with an http page to include the code needed to make a TRACE request
    of an https server... would that work? Quick tests on IE5 suggest that at
    least the Microsoft.XMLHTTP object will *not* allow making a request to an
    https URL from code in an http-delivered page, which is very good news; at
    least in regard to that object in IE, the problem seems limited to exposing
    HttpOnly cookies and HTTP Authoriztion data, and relies on using XSS bugs in
    the target server.[2]

    Bad news, though, in that my Microsoft.XMLHTTP seems happy to make an HTTP
    request to the same protocol type & host name, but different port. E.G., use
    http://target.example.com:8000/'s XSS bug (or malicious code) to launch an
    XST attack on http://target.example.com/. Not good. (Reminds me of an old IE
    bug, http://cert.uni-stuttgart.de/archive/bugtraq/1999/08/msg00380.html)

    I can't quite get the exploits to work, though, as Microsoft.XMLHTTP seems
    to be trying TRACE requests using HTTP/1.0 -- presumably newer versions are
    smart enough to know TRACE is not a valid method in HTTP version 1.0? -- so
    my target iPlanet httpd sends a 405 method not allowed error. (A quick test
    of an Apache server shows that it allows TRACE in a HTTP/1.0 request, giving
    the client an HTTP/1.1 response with the expected TRACE data. I guess this
    means that iPlanet servers may be marginally less vulnerable...)

    Enough about WhiteHat's specific exploits; it's quite conceivable that other
    objects, plugins, etc., might behave worse than those currently discussed.[2]

    > System administrators should most definitely not waste their precious time
    > on implementing the silly workarounds suggested, such as disabling
    > TRACE/TRACK requests. The one, and only, impact the discovery from WhiteHat
    > Security has is that it re-enables cookie reading from JS despite if you had
    > already cared to specifically alter your webapplication to accomodate this.

    4) There's been debate for some time in the web app development community
    about the merits of cookies vs HTTP authentication (RFC 2617). Much of the
    criticism of cookie-based authentication schemes has been how easy it is to
    access cookie contents in client-side scripting; here we have a way of
    accessing HTTP authentication info (cleartext passwords![0]) using those
    same client-side scripting attack techniques. And admins who thought their
    systems were safe from XSS because they chose not to use cookies are now,
    unfortunately, quite wrong.

    5) Microsoft.XMLHTTP is an intersting bit of code. It can be used to send
    POST requests, too[1], which, combined with the fact that you can tie an
    XMLHTTP.send() to a javascript event handler, means you can tie these
    attacks to something as simple as mousing over an image. That has
    implications both for XST and good old Cross-Site Request Forgery (CSRF)
    attacks. Shoot, with my IE5 I've been able to tie POST requests to onLoad()
    handlers in BODY tags. Ick. Anyhow, these exploit code here should serve as
    a warning to developers that "HTTP Request Enabling Technology" may make
    CSRF attacks easier for the black hats to undertake, XST/TRACE issues
    notwithstanding. :-(

    Bottom line, if http server admins can prevent their systems from responding
    to TRACE requests with three lines in the config file, why not?

    Speaking of which:

    Apache: I'd suggest something more like
       RewriteCond %{REQUEST_METHOD} !^(GET|HEAD|POST)$
    so that only the desired methods are accepted.

    Netscape/iPlanet/SunONE: hacking the vendor's compiled DLL? Ick. I was
    unable to use obj.conf and NSAPI code to disable unwanted methods in iPlanet
    Web Server 4.1, but was able to prevent TRACE from echoing certain headers.
    C source code is included with this message that can be used to prevent iWS
    from echoing the Cookie and Authorization headers. Use at your own risk, no
    warranty, etc., etc.

    -Peter

    [0] Message Digest authentication would not result in disclosing cleartext
    passwords, but in my experience, sites that have used HTTP authentication
    have chosen to use Basic authentication (for a number of reasons), so XST
    attacks are particularly nasty against these sites.

    [1] http://support.microsoft.com/support/kb/articles/Q290/5/91.asp

    [2] As WhiteHat notes, there are several ways that a client might be tricked
    into making additional, arbitrary HTTP/HTTPS requests. We could argue about
    where the domain check should happen: the plugin code, the applet security
    manager, the browser itself, etc. And what the check should be: should code
    in http://isp.example.net/~someuser/mypages/ be able to TRACE a request to
    http://isp.example.net/webmail/otheruser/INBOX & read the Authorization
    data? But the important thing is that WhiteHat has shown the risks of
    allowing TRACE requests -- if you don't need TRACE, then disable it.
    Reducing the number of attack vectors is always a good idea. 

    -- 
Peter Watkins - peterw@tux.org - peterw@usa.net - http://www.tux.org/~peterw/ 
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692

    Relevant Pages

    • Re: difference between session cookie
      ... A cookie is a special piece of data with a bit of associated metadata ... that an HTTP server includes in an HTTP response. ... requests that the client thereafter echo back the cookie in any future ...
      (comp.lang.java.programmer)
    • Re: Routing inbound HTTP Request to One of Many Servers
      ... The key to cookie-affinity is not whether the requests have cookies to start ... If a web publishing rule is configured for cookie ... For Session affinity, this is most certainly per-TCP connection from the ...
      (microsoft.public.isa)
    • WebResponse multithreading
      ... through Http to get a lot of data. ... I've discovered multiple web requests sent by different threads are not ... I'd like to use sockets, but there's a problem with them, too: ... of transmission instead of returning 0 bytesCount. ...
      (microsoft.public.dotnet.distributed_apps)
    • Re: http requests doest work - virus?
      ... > either the http server is not responding, or the request is not sent. ... Just http requests are not working. ... ResQ and Data Recovery Utilities ...
      (microsoft.public.security.virus)
    • Re: Proxy vulnerability in TrendMicro InterScan-VirusWall V3.6 - and 3.7 Build 1190
      ... > has been known to be an issue with plain HTTP proxies like the Squid ... Allows tunneling only for dedicated hosts/nets, others may only use port ... But unfortunately, on not allowed requests, the return code was "400 Bad ... Automatic pattern update sends an e-mail on every run, ...
      (Bugtraq)
    • Quantcast