Vulnerabilities that aren’t. Cross Site Tracing / XST

This is the first of my posts that explain why some common security vulnerabilities are most likely not real threats. They should be treated as security enhancements rather than vulnerabilities. Bearing in mind the number of scanning tools that rate such vulnerabilities as “high” it’s no wonder people make the mistake of reporting them. It’s also a reminder to mistrust the output from something until you’ve verified it.

I’m going to start with the not-a-vulnerability  mother of them all, the HTTP TRACE (and TRACK) method. Something that could lead to an attack called Cross Site-Tracing (XST). In 20 years I have never seen a real-world exploit for  it.

What is it?

HTTP TRACE is a debug method that is the HTTP equivalent of the echo service: it will basically reflect back in the response what is in the request. This is relatively boring. Where it got interesting was that when the vulnerability was released (in 2003) most web servers reflected the value of the request headers back. So back in 2003, it was potentially possible to gain session cookies if the method was available. This attack was found by Jeremiah Grossman and named XST (link opens a PDF).

TRACK is a Microsoft only variant of TRACE which pretty much does the same thing.

Here’s an example of an HTTP request and response against an Apache server:

Why is this not a vulnerability?

The landscape of web browser security has changed significantly since 2003, The exploit shown in the original paper was designed for use with Internet Explorer and explicitly uses the ActiveX Microsoft.XMLHTTP object to call the TRACE method. IE is, of course deprecated and the ActiveX object’s use was deprecated in IE 7.

Let’s look at it from a modern perspective. As it comes under cross-site attacks, we need to execute it in an environment that a user is using so we can discover their cookies, similar to CSRF or CORS based attacks.

From the Server perspective

We also need a web server that supports the TRACE method. The TRACE method is optional, so a HTTP server does not need to support it to be conformant. A quick survey of the most common web servers shows:

• Apache HTTP supports TRACE without a request body. This is enabled by default and can be controlled with the TraceEnable directive
• NGinx will always return a 405 Method not Allowed
• IIS from version 6 and onwards disables it by default (except for 8.5 for some weird reason)

The Apache case is interesting, there’s even a little passive aggressive note in the documentation about this:

That’s quite a confident claim from Apache!

From the Client perspective

The thing to bear in mind with XST is that it is a client attack. It employs the user’s session and user-agent to perform the attack for it. It’s a very early cross-site attack along the same line as CSRF, Flash CrossDomain access and CORS attacks.

This means that we need the user-agent, i.e. the web browser to allow the use of the TRACE request and some mechanism of calling it.

To access a URL from JavaScript the usual methods are XMLHTTPRequest (XHR) or the more modern fetch() API. Similar solutions such as jQuery generally use XHR or fetch().

So can we use these, let’s try XHR in Chrome, using the magic F12 hacking tool:

Oops, Chrome blocks the TRACE method, As Microsoft browsers caused the problem in the past, how about Edge?

So we can make a guess that all Chromium based browsers will be similar, so how about Firefox?

Nope. So that covers the main browsers. I don’t have Safari installed but  I suspect there will be no difference. How about Internet Explorer (on Windows 10)?

So, from a modern Windows 10 device none of the common browsers can even make a call to the TRACE method. Once again, I’ll state that as XST is in the class of cross-site exploits it needs to be exploited from the user-agent against a valid session.

The other thing to bear in mind, that in the current state of play any cross-site requests will need a valid CORS policy in place. All this is making it strangely hard to exploit anything.

What about other programs?

So, I only went through web browsers; but what about other programs. Here we have similar restrictions.

Air, Flash, Silverlight, Unity 3D all have restriction methods, and again, all exploits are user-agent based, By transferring to a program inside the browser you lose access to the session information.

There is a potential that a malicious plugin could have an effect, However, if you have a malicious plugin installed then there are routes which are a lot easier and more flexible to extract information.

Historical vulnerabilities

A quick search through the CVE database doesn’t reveal much for this vulnerability. There are few enough CVEs that they can all be listed here:

• CVE-2003-1567 – highlights the TRACK method in IIS which does the same as TRACE
• CVE-2004-2320 –TRACE is enabled on WebLogic Server
• CVE-2004-2763 –TRACE is enabled on Sun ONE/iPlanet Web Server
• CVE-2005-3398 –TRACE is enabled on Solaris Management Console
• CVE-2007-3008 –TRACE is enabled on AppWeb
• CVE-2008-7253 –TRACE is enabled in Lotus Domino Server
• CVE-2009-2823 –TRACE is enabled in Apache httpd on Mac OS X
• CVE-2010-0360 – this is the only real vulnerability that I’ve found – there’s a heap overflow in the TRACE method in Java System Web Server 7.0 Update 7 which could return undisclosed data
• CVE-2010-0386 –TRACE is enabled on Java System Application Server
• CVE-2018-2502 –TRACE is enabled on SAP Business One Service Layer
• CVE-2018-11039 –TRACE is enabled on Spring Framework

All but one of these are just highlighting the existence of TRACE (or TRACK). The only real exploit (CVE-2010-0360) is over a decade old,  for a product that is no longer supported. It looks like the heap overflow can also be exploited through all methods, so, even with this TRACE adds little extra risk, and only another possible vector.

Conclusion

Let’s put this one to bed. It’s been 20 years since it was identified. It has been neutered on the server and on the client so it would be far more difficult to exploit than any other form of attack on an equivalent system.

Realistically, if it is in a pen test report, then it should only be informational to demonstrate that sufficient hardening hasn’t been done.

It is good practice to disable anything you’re not using, and you certainly don’t lose any capabilities by disabling the TRACE method. I would much rather that efforts were spent fixing real vulnerabilities, rather than wasting time on facilities that have no exploit path.