Web-Cache Poisoning $$$? Worth it?

In this article, I will try to guide the readers about a bug that is easy to miss and doesn’t get a lot of attention, but surely it’s worth it. I was testing a website that has a private bug bounty program, the website was secure and I failed in getting any of the bugs I knew, and suddenly a response header took my attention.

Identifying the Vulnerability:

I was navigating through the website with burp suite turned on and proxying the URLs. The website was pretty secure and had very limited functionality, it was behind a WAF as well. There weren’t any interesting subdomains either. So I switched to burp suite and started to analyze different sorts of pages. I came across several pages that look almost identical as far as headers are concerned.

GET /redacted-page1 HTTP/1.1
Host: www.redacted.com
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Referer: https://www.redacted.com/
Cookie: _TO_AB_Testing=14

The response returned as:

HTTP/1.1 200 OK
X-Cache: Miss from cloudfront

While a similar request to /redacted-page2 yielded almost the same response:

HTTP/1.1 200 OK
<snip ...
.... snip>
X-Cache: Hit from cloudfront

The cache hit means that the page was cached at CloudFront. So when any other user requests the /redacted-page2, he will be served via CloudFront’s cached data providing that the user hit the same cache server, which he will, if the user is from a similar geographical location, he is most likely to hit the same cache. Also, since it was a production website I couldn’t damage the availability of the website, so I had to be careful while testing, therefore I cached different parameters by sending requests like: /redacted-page2?dontpoisoneverycache=1, etc.

I started sending out different headers, by changing the Host header, to see If I was able to redirect the mass users but it returned a server error. Then I tried adding:

X-Forwarded-Host: evil.com
X-Host: evil.com

To my surprise, it was appended as a link on the web-page as:

<a href=”http://evil.com/redacted-page2" >

Upon clicking, I was redirected to evil.com, I quickly changed the network and navigated to the URL via a different browser and the cached page worked :-) I was redirected to evil.com

I tried escalating it to XSS setting header as:

javascript:alert(1)”> and evil.com”onmouseover=alert(1)>
But it was filtered :-(

I reported it to the appropriate team and it was triaged in 2 days. It was classified as medium and was awarded a bounty of 200$.




Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store