From: Peter Watkins [peterw@usa.net]
Sent: Thursday, January 23, 2003 3:28 PM
To: Thor Larholm
Subject: Re: TRACE used to increase the dangerous of XSS.

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