CDN Cache Poisoning Allows DoS Attacks Against Cloud Apps

A Romanian vulnerability researcher has discovered more than 70 flaws in combinations of cloud applications and content delivery networks (CDNs) that could be used to poison the CDN caches and result in denial-of-service (DoS) attacks on the applications.

In a late December post, security researcher Iustin Ladunca revealed he had found inconsistencies in the way that a variety of content-caching services and technologies handled common headers variations, such as the capitalization of host information, URL fragments, and invalid values. Because the caching service or technology may handle the information differently — such as lowercasing capitalized headers — the application might return an error, which the caching service would store indexed to a legitimate application route. The result would be that valid HTML or API requests would return the cached error, essentially creating a DoS condition.

The research shows that poisoning Web caches is still a significant threat to cloud applications, Ladunca said in the recap of his research.

“Even though Web Cache Poisoning has been around for years, the increasing complexity in technology stacks constantly introduces unexpected behavior which can be abused to achieve novel cache poisoning attacks,” he stated.

Ladunca bet that the greater complexity would result in more vulnerabilities, making cache poisoning a fertile area for research. “Since this subtle inconsistence affected a good subset of bug bounty targets I decided to see what other common patterns I could identify and exploit at scale,” he wrote.

Using Web cache poisoning to block access to cloud services and websites is a very efficient DoS attack. A single request, when cached, can cause a site, service, or specific page to become inaccessible for hours, depending on the length of time between cache refreshes. Any Web or API request that a CDN passes to the application that causes the application to throw an exception could poison the cache and result in a DoS attack.

Three years ago, James Kettle, director of research at security-tool maker PortSwigger, gave a Black Hat presentation about “Practical Web Cache Poisoning,” outlining methods of exploiting the decision process that caching services use to determine whether to return cached content or to forward requests onto an application.

“The specific thing where you can cause a denial-of-service by poisoning the cache, there are so many ways to do it — there are an insane number of ways you can do it,” Kettle says. “If I had to make some money right now by bug hunting, that is what I would do — and it’s great that other people are doing it — but there is no way that one person can find them all.”

Searching for Flaws in Modern Cache Services
Kettle’s research inspired Ladunca to look for Web cache inconsistencies that led to exploitable DoS conditions. Over the past two years, Ladunca has found more than 70 vulnerabilities, garnering more than $26,000 in bug bounties, according to individual bounty amounts in his blog post. (Another report cited Ladunca’s tally of approximately $40,000 as the total amount of bug-bounty awards. Ladunca could not be reached for comment.)

The researcher originally discovered a flaw in a specific configuration of the Varnish Web caching proxy, but soon found that some services — including Cloudflare and Fastly — were vulnerable to a capitalized host header attack: CDNs lowercased the header for the cache index, considering the request valid, while some case-sensitive applications returned an error that was then cached.

“This meant Cloudflare lowercased the host header before introducing it into the cache key, but always forwarded as sent by the client,” Ladunca wrote in his blog. “If any backend behind Cloudflare would respond with a different response when sent a capitalized host header, it would allow the cache to be poisoned.”

Ladunca’s latest blog features cache-poisoning issues with Apache Traffic Server, GitHub, GitLab, Cloudflare, Amazon’s S3 storage buckets, and Fastly. All issues have been fixed, he stated.

Companies Should Reconsider Bug Bounties for DoS
This research underscores that cache-based DoS attacks, which cloud-service providers often do not allow in bug-bounty research, should be considered in scope in the future, says PortWigger’s Kettle. While no company wants to encourage hackers to experiment with methods that might take down its site or service, companies should want to know whether attackers could disrupt their service, he argues.

“There are a lot of programs that say, ‘We do not allow denial-of-service vulnerabilities. We will not pay you for these,'” Kettle says. “I think this is starting to shift. If we are Google and someone can take down our home page, that is a big deal, and we do want to know about it.”

Going forward, we will likely see more companies consider DoS attacks — especially those caused by single requests and exploiting architectures — to be “in scope” for penetration tests and bug bounties, Kettle says.

“Most bug-bounty policies have text discouraging DoS attacks. However, if you look closely you’ll see some of them actually forbid launching DoS attacks, rather than forbidding reporting DoS vulnerabilities,” he stated in a 2019 blog post on responsible research. “Web cache poisoning has a rare property in that it’s often possible to make a proof of concept without actually launching an attack.”

Read More HERE