TRACE used to increase the dangerous of XSS.

[Jeremiah Grossman]

WhiteHat Security has released a new white paper discussing a new class
of web-app-sec attack (XST) which potentially affects all web servers
supporting TRACE.

The white paper explains all the detailed technical results we have
found so far. We are fairly certain this particular issue will spark
much debate and encourage those interested to read and comment.


White Paper Mirrors:
http://www.betanews.com/whitehat/WH-..._XST_ebook.pdf
http://www.cgisecurity.com/whitehat-...per_screen.pdf
http://www.boarder.org/WH-WhitePaper_XST_ebook.pdf
http://www.forumgalaxy.com/whmirror/...per_screen.pdf

Press Release
http://www.whitehatsec.com/press_rel...R-20030120.txt

[Thor Larholm]

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

The HttpOnly cookie feature, a proprietary Microsoft extension designed to
mitigate a single aspect of XSS, can be circumvented in myriads of ways. In
fact, reading the HTTP response in any other way than through the
document.cookie property immediately exposed through JS will return the
cookie to you. Calling from JS to a Java applet that in turn parses a HTTP
response, using a Flash movie (or most any other plugin) or even needlessly
complicating matters by parsing the BODY of a TRACE response received
through XMLHTTP - such as this 'whitepaper' suggests.

By design, HttpOnly makes the cookie available only through the HTTP
headers - which, among many others, the XMLHTTP control can read.

What we end up with from WhiteHat Security is a way to circumvent the
HttpOnly cookie feature in IE6SP1, nothing else. In itself, worthy of a note
in a roundup of browser problems or a comment in a reply to the posting
announcing the HttpOnly feature on Bugtraq - but hardly a whitepaper,
pressrelease and blurbs such as comparing this to Code Red and Nimda or
calling this a flaw in all web servers worldwide. This is simply not "a new
class of web-app-sec attack" or a flaw in TRACE, as hyped by WhiteHat
Security.

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.

All the boojah and fuss about not requiring an actual XSS in the
webapplication or being able to impose XSS on arbitrary foreign domains,
factors that would indeed be a cause of concern, is utterly and completely
unrelated to the findings of WhiteHat Security. These are mere
demonstrations of already publicly known unpatched vulnerabilities in
Internet Explorer ( of which there are currently 19 -
http://www.pivx.com/larholm/unpatched/ ).

WhiteHat Security paired a minor low-impact notice of their own with
existing proof-of-concept code from several critical high-impact
vulnerabilities discovered, and long disclosed, by thirdparty researchers,
dubbed it their own and wrote up a fancy press release filled with
inaccuracies announcing a indifferent 'whitepaper' scathered with obscure
irrelevancies.

In short, snakeoil.

Regards
Thor Larholm
PivX Solutions, LLC - Senior Security Researcher

Latest PivX research: Multi-vendor Game Server DDoS Vulnerability
http://www.pivx.com/press_releases/mk_mk001.html


-----Original Message-----
From: Jeremiah Grossman [mailto:jeremiah@whitehatsec.com]
Sent: 22. januar 2003 21:33
To: bugtraq@securityfocus.com; webappsec@securityfocus.com;
vulnwatch@vulnwatch.org
Subject: TRACE used to increase the dangerous of XSS.


WhiteHat Security has released a new white paper discussing a new class
of web-app-sec attack (XST) which potentially affects all web servers
supporting TRACE.

The white paper explains all the detailed technical results we have
found so far. We are fairly certain this particular issue will spark
much debate and encourage those interested to read and comment.


White Paper Mirrors:
http://www.betanews.com/whitehat/WH-..._XST_ebook.pdf
http://www.cgisecurity.com/whitehat-...per_screen.pdf
http://www.boarder.org/WH-WhitePaper_XST_ebook.pdf
http://www.forumgalaxy.com/whmirror/...per_screen.pdf

Press Release
http://www.whitehatsec.com/press_rel...R-20030120.txt

[Doug Monroe]

Jeremiah Grossman wrote:
>
> WhiteHat Security has released a new white paper discussing a new class
> of web-app-sec attack (XST) which potentially affects all web servers
> supporting TRACE.

thanks for the interesting findings.
Respectfully- the apache solution proposed by RFP in the "Server Specific
Recommendation" might alternatively be crafted as:
RewriteEngine on
RewriteCond %{REQUEST_METHOD} !^(GET|POST)$
RewriteRule .* - [F]

[Jeremiah Grossman]

On Wed, 2003-01-22 at 18:28, Doug Monroe wrote:
> Jeremiah Grossman wrote:
> >
> > WhiteHat Security has released a new white paper discussing a new class
> > of web-app-sec attack (XST) which potentially affects all web servers
> > supporting TRACE.
>
> thanks for the interesting findings.
> Respectfully- the apache solution proposed by RFP in the "Server Specific
> Recommendation" might alternatively be crafted as:
> RewriteEngine on
> RewriteCond %{REQUEST_METHOD} !^(GET|POST)$
> RewriteRule .* - [F]
>


Cool, that should lock down strange HTTP request methods nicely. We
tried something similar on ISS/Exchange and it turned off some
functionality.

Careful using this type of method if your using Application Servers
which depend on request method other than GET or POST.

[Peter Watkins]

--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--FN+gV9K+162wdwwF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="PW_strip_trace.c"

#include "nsapi.h" /* NSAPI definitions */

/*
PW-strip-trace.so

NSAPI SAF to prevent the TRACE method from echoing Authorization
or Cookie headers back to the HTTP client to prevent possible
session hijacking or other XST information theft; see
http://www.cgisecurity.com/whitehat-..._XST_ebook.pdf

Usage:
At the beginning of obj.conf:
Init fn=load-modules shlib=PW_strip_trace.so funcs=PW-strip-trace
Inside an object in obj.conf (before other NameTrans calls, preferably
at the top of the Default object stanza)
NameTrans fn=PW-strip-trace
*/

NSAPI_PUBLIC int PW_strip_trace(pblock *pb, Session *sn, Request *rq)
{
/* working variables */
char *requestMethod = pblock_findval("method", rq->reqpb);

/* bail out if we've got nothing to work with */
if (!requestMethod) {
return REQ_NOACTION;
}

if (strcmp(requestMethod,"TRACE") == 0 ) {
/* remove the cookie & authorization headers so we don't echo them */
param_free(pblock_remove("cookie", rq->headers));
param_free(pblock_remove("authorization", rq->headers));
}

/* all done */
return REQ_NOACTION;
}



--FN+gV9K+162wdwwF--