Web Cache Poisoning with Multiple Headers
Cybersec Café #19 - 6/11/24
Welcome back to the biweekly Methodology Walkthrough, let’s dig into the devastation that can occur when vuln-chaining with Cache Poisoning.
Objective
Poison that cache with a response that executes alert(document.cookie) in the victim’s browser.
What is Web Cache Poisoning?
Web cache poisoning is where attackers manipulate the web cache to serve malicious content to users. This attack can distribute harmful payloads, misleading information, or phishing site redirection to a wide audience, making detection difficult.
Methodology
The Recon
Starting this lab, we’re provided with a few pieces of information:
The lab contains a cache poisoning vulnerability that is only exploitable when you use multiple headers.
The lab supports both the X-Forwarded-Host and X-Forwarded-Scheme headers.
As we usually approach a target, we can start by clicking “all of the things.”
The lab features a shop with different items, but product pages don’t have any functionality to them.
The lab has a feature to log in, but we have no provided credentials to utilize.
We should also make note we have an Exploit Server available to us. I suspect this is where we will deliver our attack from, but we first need to find the attack vector.
Let’s turn our gaze to the SiteMap.
We can see in the Root Request the X-Cache header is present in the response, which is a key indicator there is caching occurring in the application.
One request that catches my eye is located under resources/js/tracking.js.
It caught my attention because in the HTTP History, it gets called quite frequently.
Let’s send this over to the Repeater for some manual testing.
Testing
We can start by adding the X-Forwarded-Host header with an arbitrary hostname to the request.
This doesn’t yield any noticeable change in the response.
Let’s try again with the X-Forwarded-Scheme header. Wec an send with the same test domain.
We can see we’ve now recieved a 302 response but don’t see any reflection in the response.
Let’s try adding HTTPS as a value to the header.
We can see this now returns a 200 response.
Note: If the X-Cache header returns “hit,” you’ll have to wait for the ache to expire before testing a new payload. The Time-to-Live (TTL) is 30 seconds for this environment.
Next, le’ts add the X-Forwarded-Host header back and cahnge the X-Forwarded-Scheme header to be nothttps.
Send the request until you receive a 302 response again.
Notice this time, the location has changed to reflect our test domain we placed in the X-Forwarded-Host header.
We’ve found the attack vector.
Exploitation
As expected, we’ll need to utilize the Exploit Server to deliver the paylod.
In the Exploit Server, change the File path to reflect the path the application is searching for: /resources/js/tracking.js
Write the payload in the Body of the Exploit Server and click Store: alert(document.cookie)
Copy and paste the URL into the X-Forwarded-Host header and keep the X-Forwarded-Scheme header as nothttps.
Notice when you select Copy URL and load the URL in the browser, you’ll see the script of your payload but the alert won’t execute.
In order to Exploit your victim, remove the cache buster and resend the request until you poison the cache again.
Reload the Browser.
Lab solved!
What We’ve Learned
While Web Cache Poisoning may not be the most effective vulnerability on its own, we’ve seen that cache poisoing can have devastating affects when chained with XSS. On top of that, with the potential blast radius the vulnerability can have on a busy site, this exploit has the ability to affect thousands of users in one swift attack.
It’s important to sanitize user inputs, ensure cache keys are unique and can’t be manipulated, and to use cache-control headers properly to avoid this vulnerability in your applications.
Want to give the lab a try yourself? You can check it out on PortSwigger’s website here.
Securely Yours,
The Cybersec Cafe
Just a heads up, The Cybersec Cafe's got a pretty cool weekly cadence.
Every week, expect to dive into the hacker’s mindset in our Methodology Walkthroughs or explore Deep Dive articles on various cybersecurity topics.
. . .
Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can't wait to keep sharing and learning together!