Smuggling an (Un)exploitable XSS
This is the story about how I’ve chained a seemingly uninteresting request smuggling vulnerability with an even more uninteresting header-based XSS to redirect network-internal web site users without any user interaction to arbitrary pages. This post also introduces a 0day in ArcGis Enterprise Server.
Smuggling Requests for Different Response Lengths
So what I usually do when having a look at a single application is trying to identify endpoints that are likely to be proxied across the infrastructure - endpoints that are commonly proxied are for example API endpoints since those are usually infrastructurally separated from any front-end stuff. While hunting on a private HackerOne program, I’ve found an asset exposing an API endpoint that was actually vulnerable to a CL.TE-based request smuggling by using a payload like the following:
As you can see here, I’m smuggling a simple GET request against the root path of the webserver on the same vhost. So in theory, if the request is successfully smuggled, we’d see the root page as a response instead of the originally queried API endpoint.
To verify that, I’ve spun up a TurboIntruder instance using a configuration that issues the payload a hundred times:
While TuroboIntruder was running, I’ve manually refreshed the page a couple of times to trigger (simulate) the vulnerability. Interestingly, the attack seemed to work quite well, since there were actually two different response sizes, whereof one was returning the original response of the API:
And the other returned the start page:
This confirms the request smuggling vulnerability against myself. Pretty cool so far, but self-exploitation isn’t that much fun.
Poisoning Links Through ArcGis’ X-Forwarded-Url-Base Header
To extend my attack surface for the smuggling issue, I’ve noticed that the same server was also running an instance of
ArcGis Enterprise Server under another directory. So I’ve reviewed its source code for vulnerabilities that I
could use to improve the request smuggling vulnerability. I’ve stumbled upon an interesting constellation affecting its
generic error handling:
The ArcGIS error handler accepts a customized HTTP header called
X-Forwarded-Url-Base that is used for the base of all links on
the error page, but only if it is combined with another customized HTTP header called
value supplied to
X-Forwarded-Request-Context doesn’t really matter as long as it is set.
So a minified request to exploit this issue against the ArcGis’
/rest/directories route looks like the following:
This simply poisons all links on the error page with a reference to my server at
? which is used to get rid off the automatically appended URL string
While this already looks like a good candidate to be chained with the smuggling, it still requires user interaction by having the user (victim) to click on any link on the error page.
However, I was actually looking for something that does not require any user interaction.
A Seemingly Unexploitable ArcGis XSS
You’ve probably guessed it already. The very same header combination as previously shown is also vulnerable to a reflected
XSS. Using a payload like the following for the
leads to an alert being injected into the error page:
Now, a header-based XSS is usually not exploitable on its own, but it becomes easily exploitable when chained with a request smuggling vulnerability because the attacker is able to fully control the request.
While popping alert boxes on victims that are visiting the vulnerable server is funny, I was looking for a way to maximize my impact to claim a critical bounty. The solution: redirection.
If you’d now use a payload like the following:
…you’d now be able to redirect users.
Connecting the Dots
The full exploit looked like the following:
While executing this attack at around 1000 requests per second, I was able to actually see some interesting hits on my server:
After doing some lookups I was able to confirm that those hits were indeed originating from the program’s internal network.
Mission Completed. Thanks for the nice critical bounty :-)