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
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
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
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:
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:
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$.