Web Cache Poisoning to Denial of Services

Ekin Bayer
4 min readMar 26, 2021

Hello everyone, I’m Ekin Şiar Bayer. I am 15 years old and going to the 10th grade at Samsun Science High School. Today I will share with you my first bug bounty write-up.

Recon

I will tell you the whole story so I’m starting with recon. That’s my bash codes for finding alive sub-domains.

$ assetfinder --subs-only target.com | sort -u > all-assetfinder.txt$ subfinder -silent -d target.com > all-subfinder.txt > /dev/null$ amass enum -passive -norecursive -noalts -d target.com > all-amass.txt &> /dev/null$ cat all-sublister.txt all-assetfinder.txt all-subfinder.txt all-amass.txt | grep -v "*" | sort -u | sed '/@/d' | sed '/<BR>/d' | sed '/\_/d'| sed '/*/d' > all-finalsubdomains.txt$ cat all-finalsubdomains.txt | sort -u | uniq -u | httpx -silent > all-alive.txt

What is Web Cache

Before explaining how I found the vulnerability, it is necessary to understand what the vulnerability stems from.

If the server has to respond separately for each HTTP request, this may cause the server to be overloaded. Caching is used to reduce such problems.
The cache saves responses to specific requests, usually for a certain period, which stands between the server and the user. If another user then sends an equivalent request, the cache provides a copy of the cached response directly to the user, without any back-end interaction. This relieves the server by drastically reducing the requests that the server has to answer.

Want to read this story later? Save it in Journal.

You can understand better if you look at the picture below.

Cache Keys

When the cache receives an HTTP request, it first has to determine whether there is a cached response that it can serve directly, or whether it has to forward the request for handling by the backend server. Caches identify equivalent requests by comparing a predefined subset of the request’s components, known collectively as the “cache key”. Typically, this would contain the request line and Host header. Components of the request that are not included in the cache key are said to be “unkeyed”.

If the cache key of an incoming request matches the key of a previous request, then the cache considers them to be equivalent. As a result, it will serve a copy of the cached response that was generated for the original request. This applies to all subsequent requests with the matching cache key until the cached response expires.

Crucially, the other components of the request are ignored altogether by the cache.

What is Web Cache Poisoning

Any web cache poisoning attack relies on the manipulation of unkeyed inputs, such as headers. Web caches ignore unkeyed inputs when deciding whether to serve a cached response to the user. This behavior means that you can use them to inject your payload and elicit a “poisoned” response which, if cached, will be served to all users whose requests have the matching cache key. Therefore, the first step when constructing a web cache poisoning attack is identifying unkeyed inputs that are supported by the server.

The compromise status of web cache poisoning may vary depending on the application affected. In the vulnerability I found, web cache poisoning was causing An attacker can block access to resources of the web application.

You can understand better if you look at the picture below.

Exploitation of Denial of Services

Now let’s move on to the exciting part, where I explain how I found the vulnerability, exploited it and what its effect was.

The first thing I did was check whether the website caches error-related pages to test the articles I read a while ago.

Article 1: https://portswigger.net/research/responsible-denial-of-service-with-web-cache-poisoning

Article 2: https://www.geeks.fyi/showthread.php?tid=8856

This technique is based on the fact that the web cache caches error-related pages. Normally, in this case, the bad request, which is not recognized by the cache, is not taken into the web cache. To test this situation, I sent the request by putting an HTTP Header and \x07 HTTP meta character as my headers value which the website cannot recognize.

And normally I ran into an error page. However, because the website cached this page, the website resource (page, script) that I made an error has become inaccessible to anyone until the cache refreshes itself.

To prevent this vulnerability, you need to make sure that the web cache does not cache error-related pages.

This vulnerability is evaluated as a medium severity by the CVSS 3.1 scale.

  • Initial report sent: March 22nd 2021
  • Reproduce: March 24th 2021
  • Triage : March 24th 2021
  • Bounty awarded with 500$: March 26th 2021

📝 Save this story in Journal.

--

--