Three Minutes with the HTTP TRACE Method
Brian King //
All of our scanning tools tell us that we should disable the HTTP TRACE and TRACK methods. And we all think that’s because there’s something an attacker can do with it to steal secrets from legitimate users. But there’s another thing TRACE can do for an attacker, and it’s got nothing to do with other users.
OWASP says you should disable HTTP TRACE because it can be used for Cross Site Tracing.
CERT says it can be “combined with cross-domain browser vulnerabilities to read sensitive header information from third-party domains.”
Deadliest (!) Web Attacks says you can read cookies.
Cross-Site Tracing (XST): The misunderstood vulnerability
All of those are correct, but a little old. In modern browsers, XMLHttpRequest won’t send a “TRACE” request anymore, and the CORS framework prevents XHR requests to foreign sites that don’t explicitly allow them. So these old attacks don’t work so well anymore.
But! It’s still a useful information-getter. Remember that the TRACE verb is handled by the webserver. Your request may pass through something else on the way to the webserver. If that something else adds headers, then your TRACE response will include those headers, and you’ll gain a little information you didn’t already have.
What sits in front of a webserver that might be interesting? A Web Application Firewall (WAF), which may be filtering requests to detect and kill attacks before they get to the webserver.
The X-Forwarded-For header is one of the headers added by some WAFs, and it is sometimes used by the WAF itself to decide if it should filter that request or not. If the header is present and contains the IP address of the WAF, then the request must have come from the WAF, and it must not be malicious, right?
Well, what if we add one of those to the request we send?
This WAF doesn’t just create the X-Forwarded-For header, it adds the requesting system’s IP address (my public IP address, ending in 103) to whatever may already be there. If you know the IP address of the WAF (and you do because you’re talking to it), you can try to tell the WAF that your request is actually the WAF’s request, and should be ignored. If it believes you, then you’ve bypassed the WAF.
This is the most straightforward WAF bypass. This is not a new discovery at all, but the TRACE verb here shows you why it can work.
If you want to play with it at home, here’s the HTML I used for the XHR illustration above:
We think BB is pretty cool …but we might be biased.
Why not find out for yourself and take a class with him?
Available live/virtual and on-demand
July 14, 2016 @ 7:21 am
As you say browser blocks TRACE request, how can I send TRACE request from browser from your give code?
July 14, 2016 @ 8:49 am
That’s the problem – today’s browsers won’t do it for you.
I did it by using BurpSuite, but you could use ZAP or another proxy, even the command-line if you like.
Here’s what I got when I did that just now – you type the first and fifth lines below (hit enter twice after you type “TRACE / HTTP/1.0”):
$> telnet http://www.example.com 80
Connected to http://www.example.com.
Escape character is ‘^]’.
TRACE / HTTP/1.0
HTTP/1.0 405 Method Not Allowed
Date: Thu, 14 Jul 2016 14:46:18 GMT
Server: ECSF (mdw/13EE)
Connection closed by foreign host.