Web cache poisoning attacks demonstrated on major websites, platforms

Web cache poisoning attacks demonstrated on major websites, platforms

Major websites and platforms may be vulnerable to simple yet devastating web cache poisoning attacks, which could put millions of users in jeopardy.Ja

Perfect end to a perfect month: Yet another Win10 1709 cumulative update, KB 4058258
Mozilla Fixes 32 Vulnerabilities in Firefox 54
Keys for Dharma Ransomware Released

Major websites and platforms may be vulnerable to simple yet devastating web cache poisoning attacks, which could put millions of users in jeopardy.

James Kettle, head of research at PortSwigger Web Security, Ltd., a cybersecurity tool publisher headquartered near Manchester, U.K., demonstrated several such attacks during his Black Hat 2018 session titled “Practical Web Cache Poisoning: Redefining ‘Unexploitable.'” Kettle first unveiled his web cache poisoning hacks in May, but in the Black Hat session he detailed his techniques and showed how major weaknesses in HTTPS response headers allowed him to compromise popular websites and manipulate platforms such as Drupal and Mozilla’s Firefox browser.

“Web cache poisoning is about using caches to save malicious payloads so those payloads get served up to other users,” he said. “Practical web cache poisoning is not theoretical. Every example I use in this entire presentation is based on a real system that I’ve proven can be exploited using this technique.”

As an example, Kettle showed how he was able to use a simple technique to compromise the home page of Linux distributor Red Hat. He created an open source extension for PortSwigger’s Burp Suite Scanner called Param Miner, which detected unkeyed inputs in the home page. From there, Kettle was able to change the X-Forwarded-Host header and load a cross-site scripting payload to the site’s cache and then craft responses that would deliver the malicious payload to whoever visited the site. “We just got full control over the home page of RedHat.com, and it wasn’t very difficult,” he said.

In another test case, Kettle used web cache poisoning on the infrastructure for Mozilla’s Firefox Shield, which gives users the ability to push application and plug-in updates. When the Firefox browser initially loads, it contacts Shield for updates and other information such as “recipes” for installing extensions. During a different test case on a Data.gov site, he found an “origin: null” header from Mozilla and discovered he could manipulate the “X-Forwarded-Host” header to trick the system so that instead of going to Firefox Shield to fetch recipes, Firefox would instead be directed to a domain Kettle controlled.

Kettle found that Mozilla signed the recipes, so he couldn’t simply make a malicious extension and install it on 50 million computers. But he discovered he could replay old recipes, specifically one for an extension with a known vulnerability; he could then compromise that extension and forcibly inflict that vulnerable extension on every Firefox browser in the world.

“The end effect was I could make every Firefox browser on the planet connect to my system to fetch this recipe, which specified what extensions to install,” he said. “So that’s pretty cool because that’s 50 million browsers or something like that.”

Kettle noted in his research that when he informed Mozilla of the technique, they patched it within 24 hours; but, he wrote, “there was some disagreement about the severity so it was only rewarded with a $1,000 bounty.”

Kettle also demonstrated techniques that allowed him to compromise GoodHire.com, blog.Cloudflare.com and several sites that use Drupal’s content management platform. While the web cache poisoning attacks he demonstrated were potentially devastating, Kettle said they could be mitigated with a few simple steps. First, he said, organizations should “cache with caution” and if possible, disable it completely.

However, Kettle acknowledged that may not be realistic for larger enterprises, so in those cases he recommended diligently scanning for unkeyed inputs. “Avoid taking input from HTTP headers and cookies as much as possible,” he said, “and also audit your applications with Para Miner to see if you can find any unkeyed inputs that your framework has snuck in support for.”

Go to Source

COMMENTS