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

> What we end up with from WhiteHat Security is a way to circumvent the

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

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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

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.

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related securityfocus.com Links bugtraq certification focus-bsd focus-ids focus-ih focus-linux focus-ms focus-sun focus-unix-other focus-virus forensics incidents libnet linux-secnews ms-secnews pen-test secpapers secprog sectools secureshell security-basics securityjobs sf-news vuln-dev webappsec Request more information about Pantek

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(at)tux.org - 
peterw(at)usa.net - 
http://www.tux.org/~peterw/ 
Private personal mail: use PGP key F4F397A8; more sensitive data? Use 2D123692