Web Cache Poisoning – Through Host Header Injection

Web cache poisoning is an advanced hacking technique through which an attacker can exploit the pattern or behavior of a web cache and server. But before comprehending what is web cache poisoning, we should understand web cache and its vulnerabilities. This will help us in taking measures to prevent web cache poisoning.

The first question here is what is web cache?

A cache is a term that is generally used for the information between server and user. When a web server saves data from certain requests temporarily or for some limited amount of time, those data or information is known as a cache. In case, the server receives a similar request then the user will receive the cached information which was saved earlier without having to interact with the server again.

Figure: HTTP web cache.

Working of Web Cache

Servers receive a lot of requests and can get overloaded if it will have to send a new request every single time for each separate HTTP request. Due to this factor, a server can face delay problems and an unsatisfactory user experience. Therefore, the primary use of cache is to reduce the overloading of the webserver.

When an HTTP request is received by the cache, it will check for a past similar cached response. If there is a response already present then it does not forward the requests to the back-end server for handling. This procedure is carried by Cache Keys. It comprises a pre-defined set of components that consists of the host header and request line from the request. The remaining components of the request that are not present in the key are known as unkeyed components. In case, there are two requests from cached keys, those two requests will be considered equivalent by the server. For such requests, the server provides a saved cached copy of a response to the subsequent requests. There is an expiration time for every saved cache.

Web Cache Poisoning:

Web cache poisoning is an advance attacking technique through which an attacker tries to exploit the target’s web cache and server to distribute malicious HTTP responses.

The exploitation attack is carried out in two phases:

1. In the first step, the attacker needs to conjure a malicious response from the server. This response will carry some kind of harmful payload.
2. After successfully receiving a malicious response from the server, the attacker will try to get the cache response. This response will be finally be delivered to users.

Here are some points that are to be considered when we need to perform a web cache poisoning attack.

Firstly, we need to recognize the unkeyed inputs present in a request. It is because they are often neglected by the server. By using them, we can easily manipulate the server by including payloads in the request inputs when cached data is getting delivered. To identify unkeyed inputs, we need to include different inputs in the request and then observe them. It is done to see whether they cause any effect on response or not. After analyzing those keyed inputs, we can conjure a damaging response from the server with the help of these inputs.

After we are successful in receiving a payload that contains a damaging response, we can start working on getting this response cached by the user. Once harmful response gets cached, we can finally deliver the payloads to targeted users.

Exploiting web cache poisoning vulnerabilities:

With web cache poisoning, we can carry out multiple payload attacks. Here is the list of vulnerabilities that can be exploited by using web cache poisoning:

• XSS attack
• The exploitation of resource import
• Cookie-handling vulnerabilities exploitation
• Multiple headers exploitation
• Exploiting responses to retrieve sensitive information
• The exploitation of DOM-based Vulnerabilities
• Chaining web cache poisoning vulnerabilities

We can also perform exploitation by the implementation of flaws in the cache. It is carried out by exploiting cache key flaws. For example, unkeyed query parameter, internal cache poisoning, unkeyed port, cache key injection, unkeyed query string, etc. We can also achieve this by using cache probing methodology.

Web cache poisoning to go through web stack:

In the beginning, the web was quite simple but its complexity is increasing day by day due to caches global network. It helps improve the network’s responsiveness to a site but also introduces more attack space. With the advancement in technology, we can exploit more than just headers and caches with web cache poisoning.

Different exploitation methodologies like misguided transformation, request line normalization, insecurely stored cache key components, etc, can come in very handy for such a process. Using such methods, an attacker can corrupt the website and perform a persistent DOS attack with just one malicious redirect request.

Impact of web cache poisoning:

The following factors impacts web cache poisoning:

1. What responses can be successfully cached?
2. The traffic on the affected page

The primary focus of web cache poisoning is delivering payloads to the users. Therefore, the impact depends on the amount of malicious content injected into the payload. Another aspect that decides the impact is the number of users the payload was delivered to. If a popular website is poisoned then its impact will be huge.

Preventing web cache poisoning vulnerabilities:

Here are some important points that are to be taken into consideration as a preventive measure.

• Restriction of cache to static responses.
• A better understanding of third-party applications before adding them to your cyber environment.
• To prevent something from getting excluded from the cache key, rewrite the request.
• Avoid excepting large GET requests.
• Try to patch up all the client-associated vulnerabilities.

Example:

Here is an example of exploiting the vulnerability on the online lab using a web cache. In this lab, web cache poisoning will be explained using the unkeyed header. To fix it 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 the burp suite.

We will be following the steps below:

• Access the lab and capture GET requests on the burp suite.

• After capturing the request in burp. In a proxy tab, open “HTTP History” and find the GET request for the home page.

• Now, this request is to be sent to the Repeater.

• This lab is supportive of X-Forwarded-Host. In the parameter of the cache-buster unkeyed header, we need to add, “?cb=1234” in the request. So, we will add X-Forwarded-Host with an arbitrary hostname, for example, “example.com”.  After adding these parameters to the request, Now, we need to keep sending requests until the cache is hit.
  
• The X-Forwarded-Host in the request will dynamically generate a URL for importing a JavaScript file stored at that particular path disclosed in response. Open the exploit server immediately as the cache is hit.
  
• In the exploit, the server will be changing the file name to the path disclosed in the response i.e., “/resources/js/tracking.js”. It will also change the file name of the body to “alert(document.cookie)” and will store these values.
  
• Once we have completed storing the values, the exploit server’s URL is to be copied and then pasted in the request as X-Forwarded-Host.
  
• We need to resend the request, after removing the cache-buster header which is represented as “cb=1234”, and the value of X-Forwarded-Host is to be changed.                             
• This request is to be replayed till the cache response is hit. As soon as the cache is hit the response cache is poisoned to execute the body in the exploit server

Web cache poisoning can even damage a completely secure website and make it vulnerable to attacks by just adding a malicious response in its cache. You can also read about one such vulnerability, i.e., web cache deception in our blog section.

Thank you.

Author,

Pralekya Hirmalwar

Varutra Consulting Pvt. Ltd.