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
#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-mirror/WH-WhitePaper_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;
}
