Web Cache Poisoning – Through Host Header Injection
To understand the concept of web cache poisoning first we have to understand what web cache is and why it is being used. Then we will try to understand what web cache poisoning is, how it is done, the impact of it and measures to be taken to prevent poisoning.
The first question here is what is web cache?
A cache is something that stands between server and user. Web server saves some responses to particular requests for a fixed amount of time. These particular responses that are being saved are referred as “Cache”. If the server encounters a similar request then simply the cached response is given to the user directly, without having the need to interact with the back-end.
Figure: HTTP web cache.
The next quest here to understand is why is web cache being used?
There is a lot of requests incoming to the server. The server will likely be overloaded if it has to send a new response for every separate HTTP request. Due to this, the server will face latency issues and user experience will also become poor. Thus cache is primarily used to reduce the overload on the webserver.
How exactly cache works?
A cache is always placed between the server and the user. When an HTTP request is received by the cache, it first checks if there is a similar cached response which can be directly forwarded as a response, if not it will forward the request to the back-end server for handling. This is done by using “Cache keys”. Cache keys are comprised of a pre-defined set of components, like the host header and request line from the request. The rest of the components of the request which are not in the key are called ‘unkeyed’ components. If the cache key of two requests matches, then those requests are considered equivalent by the server. For these kinds of requests, the server serves the saved cached copy of the response to the subsequent requests. This saved cache also has an expiry time.
As we have understood what web cache is and how exactly the cache works, we can now move forward to understand how we can perform web cache poisoning.
Web Cache Poisoning:
Web cache poisoning is an advanced attack where an attacker tries to exploit the web server and cache to serve malicious HTTP responses to users.
This attack is usually performed using two phases
- First, the attacker will have to evoke a harmful response from the server. A harmful response is something that contains some kind of dangerous payload.
- After successfully getting a harmful response from the server the attacker will try to get the response cached so that it can be delivered to users.
While performing a web cache poisoning attack we have to take the following steps into consideration:
Initially, we have to identify what are the unkeyed inputs in a request. This is because unkeyed inputs are ignored by the server and using these we can manipulate the server by adding payloads in the request inputs which when cached will be delivered to users. To identify unkeyed inputs we can add random inputs to the request and observe whether or not they have an effect on the response.
After identifying unkeyed inputs we have to think of ways in which we can evoke a harmful response from the server using these inputs.
As we are able to get a harmful response containing the payload successfully, now we have to focus on getting this response cached. This is the part where we have put in a lot of effort to understand the behavior of the cache. Once we are able to get the harmful response cached, we are all set to deliver the payloads to the users.
Exploiting web cache poisoning vulnerabilities:
Using web cache poisoning we can deliver different attack payloads to the users. Following are the list of vulnerabilities we can exploit using web cache poisoning:
- Web cache poisoning to deliver XSS attack
- Web cache poisoning to exploit handling of resource import
- Exploiting cookie-handling vulnerabilities using web cache poisoning
- Multiple headers to exploit web cache poisoning
- Exploiting responses that expose a lot of information
- Exploiting DOM-based Vulnerabilities
- Chaining web cache poisoning vulnerabilities
Web cache poisoning can also be performed by exploiting implementation flaws of the cache. This can be performed by exploiting cache key flaws like unkeyed port, unkeyed query string, unkeyed query parameters, cache key injection, internal cache poisoning, etc. this can also be achieved by using cache probing methodology.
Web cache poisoning to go through web stack:
In the initial days, the web was simple but now the complexity is rapidly expanding due to the global network of caches. Using this network will improve the responsiveness of the site but it will introduce more attack space.
Initially, it was limited to the exploitation of headers and caches but nowadays as technology has got more advanced we can do more than that to go through. We can exploit by using different methodologies like misguided transformation, request line normalization, insecurely stored cache key components, etc.
Using this an attacker is able to compromise a website, perform a persistent DOS attack with just one malicious redirect request.
Impact of web cache poisoning:
The impact of web cache poisoning depends on the following factors:
- What exactly can successfully be cached
- How much traffic is there on the affected page?
In web cache poisoning the focus is more on delivering the payloads to the users. So the impact will depend on how harmful the injected payload is. Another aspect to decide the impact is the number of users the payload was delivered to. If the website being poisoned is a popular website then the impact of this can be huge.
Preventing web cache poisoning vulnerabilities:
Following points should be taken into consideration as a measure for preventing poisoning of web cache:
- While using caching, restrict cache to static responses
- Understanding the third-party soft wares from the security point of view, while adding it to the environment
- Rewrite the request instead of excluding something from the cache key
- Do not accept a large GET request
- Always patch all the client-side vulnerabilities
Below is an example of web cache poisoning in an online lab. This lab demonstrates web cache poisoning with an unkeyed header. For solving this lab we will poison the response cache that will execute “alert(document.cookie)” in the browser. And to do so we need only 2 things i.e. the lab itself and burp suite. The steps involved are as shown below:
- Access the lab and capture that GET request in the burp suite.
- After capturing the request in burp go to “HTTP History” in the Proxy tab and find the GET request of the home page.
Now send this request to the Repeater.
- Add a parameter “?cb=1234” in the request which will be the cache-buster unkeyed header. This lab supports X-Forwarded-Host. So we will add X-Forwarded-Host with an arbitrary hostname, here it’s “example.com”. After adding these parameters to the request, we need to keep sending the request until the cache is hit.
- In the exploit, the server changes the file name to the path disclosed in the response i.e. “/resources/js/tracking.js” and changes the body to “alert(document.cookie)” and stores these values.
- Once the values are stored, copy the URL of the exploit server and paste in the request as X-Forwarded-Host.
- Now after changing the value of X-Forwarded-Host, remove the cache-buster header i.e. ?cb=1234, and resend the request.
- Replay the request until the cache is hit. As soon as the cache is hit the response cache is poisoned to execute the body in the exploit server.
Varutra Consulting Pvt. Ltd.