Web cache poisoning is no longer a theoretical vulnerability

PortSwigger researcher James Kettle took to the stage at Black Hat USA today to demonstrate how his work in the elusive field of cache poisoning allowed him to take control of numerous well-known websites and frameworks, along with infrastructure that underpins Firefox.

Web caching – the process of storing web content and other data at various points along the delivery path – is widely employed as a means to increase website performance and scalability.

Although caching can help improve site responsiveness and reduce network costs, these additional levels of storage have resulted in what Kettle calls a “crude patchwork of content delivery networks” – with each additional layer of caching opening the doors to more potential security loopholes.

During his presentation, Kettle shared the tools and techniques he used to find, explore, and exploit web cache poisoning, progressing from simple single-request attacks to intricate exploit chains that hijack JavaScript, pivot across cache layers, subvert social media, and misdirect cloud services.

Assessing the attack surface

According to the researcher, the first step in determining a cache poisoning target is to find some kind of input that’s not included in the cache key, such as custom HTTP headers and cookies. Kettle developed the free, open source Param Miner tool for this purpose.

“Once we’ve found that we can do something useful with our input, the next step is to get it saved in the cache,” he said. “In effect, everything that’s not included in the cache key is part of the cache poisoning attack surface.”

Cache control

Kettle presented numerous case studies that demonstrated the real-world implications of web cache poisoning, first showing how he was able to gain control of Redhat.com by adding a cross-site scripting (XSS) payload to their homepage.

The researcher went on to show how the User-Agent header could be used to target a specific userbase – ideal for selective attacks or sneaking payloads past development teams who are known to use a particular browser.

The Shield is down

After finding a way to take control of browsers visiting Data.gov, Kettle’s research took an even more interesting turn, as a doorway opened into infrastructure that underpins Mozilla’s Firefox.

The vulnerability exists in the infrastructure powering a core Firefox feature, Mozilla Shield, which is used for silently installing extensions in the background for research and marketing purposes (and perhaps most famous for serving up the controversial Mr Robot extension last year).

Kettle explained: “Periodically, Firefox gets a list of URLs, and one of those points to a list of ‘recipes’ that says, ‘You should install this extension’.

“I was able to use cache poisoning to take over this list, making every Firefox installation around the world connect to my server.”

Mozilla was smart enough to sign these recipes, which means an attacker couldn’t simply install a malicious extension, but Kettle found that old recipes could be replayed.

“I could audit all the extensions that have ever been installed by this system, find one that had a known vulnerability, and then I could inflict that vulnerability on every Firefox installation on the planet.”

Route poisoning

Kettle discovered that some applications go beyond using headers to generate URLs and use them for internal routing. This, he says, leaves sites open to further cache poisoning exploits.

By way of example, the researcher noted that employment background checking website Goodhire.com is hosted on HubSpot.

“To exploit this, we need to go to Hubspot.com, register ourselves as a HubSpot client, place a payload on our own HubSpot page, and then finally trick HubSpot into serving this response on Goodhire.com.”

Cloudflare happily cached this response and served it to subsequent visitors, he said.

Hijacking resources

Turning his attention to Cloudflare itself – and specifically the organization’s blog, which is hosted by Ghost – Kettle found that by registering his own ghost.org account and setting up a custom domain, he could redirect requests sent to blog.cloudflare.com to his own site.

“This meant I could hijack resource loads such as images,” he said.

In addition to demonstrating how cache poisoning can be leveraged to override URLs that get shared on social media, Kettle showed how a chain of cache poisoning attacks could be used on Drupal sites to replace downloads with malicious files.

Cache in hand

Kettle’s latest research is enough to leave anyone questioning whether they should ever open an internet browser again. So how do site owners defend against cache poisoning?

“The most robust defense against cache poisoning is to disable caching,” he said. “That advice might sound silly, but I think for example, someone might start using Cloudflare because they are under a DDoS attack. If that’s the case, just turn caching off. It shouldn’t be on by default.

“I recommend auditing every page of your application with Param Miner to flush out unkeyed inputs.”

He added: “Finally, regardless of whether your application has a cache, some of your clients may have a cache at their end, and as such client-side vulnerabilities like XSS in HTTP headers should never be ignored.”


A full technical write-up and accompanying white paper can be found on the PortSwigger blog.