Web Cache Poisoning – “Reborn” by James Kettle

Tram Ho

1. Overview

1.1 – About James Kettle

James Kettle is Portswigger ‘s Web Security director . If anyone has ever used BurpSuite, this is the product of this organization. The picture below is the avatar for his nickname: albinowax

Thanks to the fact that he had “money-heavy” bug bounties based on this vulnerability targeting reputable organizations, giving presentations on this vulnerability at major conferences made it noticeable. Just as he wrote about it in full, accompanied by well-built Labs articles. It is no exaggeration to say that he himself “reborn” this flaw.

1.2 – About Web Cache Poisoning

Poisoning the Cache area is not new. But if you try Google search “Web Cache Poisoning”, most will return results from the end of 2018 onwards. That’s when the perception and impact of this vulnerability is no longer just a ‘theoretical’ threat – in the words of James Kettle. It was a real threat, which could affect the entire Web service if caught.

2. The Caching Concept

2.1 Web Caching and Web Cache

Caching is widely applied in all fronts in the IT industry, even the smartphone or PC you are using, Caching also happens continuously. The goal is to speed up the processing of tasks because it is cached, so that whenever the task is requested, it responds directly from here.

Similarly, Web Caching is the Web Server will have a buffer, standing between requests and responses. Based on the optimal algorithms for caching, they will determine the condition for a request to be caching and countless other related issues to be presented in this video, and if the user request to the resource has been cached, they will Immediately sends response without calling Web Server.

Web cache: This is the cache memory used for storage. It is also our poison target.
And note that the cache in this article is a shared cache, not a private cache. It is the beautiful gray area up there.

Caching mechanism: When analyzing the HTTP Header of the packet sent, the Cache will not read them in a byte-to-byte fashion because the data in this is different and contains a lot of unimportant data, such as the blue text area on the side. below:

Therefore, they use something else called cache keys (the orange area above). Accordingly, they will find and match some specific components in the Header of the HTTP Request to return the resources being requested.
However, the Cache keys are case-by-case and non-fixed (or can be determined by the Vary field header).

2.2 Web Cache Poisoning

Web Cache Poisoning Is not:

  • Browser cache poisoning
  • Web Cache Deception
  • Response Splitting / Request Smuggling
  • Theoretical

The goal of this is to send a request that can generate a harmful response, notably, it is stored in the Cache area and used to serve the following (victim) victims:

3. Methodology

All are in the diagram above and an overview analysis of the author:
The input used to make the Cache Keys is mentioned above, but the first step here is to identify the Unkeyed inputs , so what is it? The author has developed an extension on Burpsuite to automate this. This place is easy to confuse, let’s see some examples below:

His extension, Param Miner , quickly discovered an unkeyed input, namely the X-Forwarded-Host field , notably the value of this field (canary), used in the response returned. Instead of the harmless canary text, insert a JS code:

This shows that the response actually contains the Javascript code to trigger the XSS added in the above request, of course, it is possible to use any arbitrary JS code. The final step will determine whether the request has been cached? And the Cache keys, as described in the caching mechanism , will be: www.redhat.com and /en?dontpoisoneveryone=1 .
He also noted that don’t stop seeing Cache-Control: no-cache, just attack like it doesn’t exist. 😆

Sending another request to the right resource of the cache keys and without the X-Forwarded-Host field above, the malicious request cache and the response it actually happened:

At this point, if you’re still not sure about unkeyed input, read the following definition of a “ninja”:

Unkeyed input are parts of the request that are not used when generating the cache key.
For example the value of certain headers / cookies are not used when caching the request. If the value of these headers is recorded in the response, it’s possible to poison the cache.

Done step one 😅 The next steps we need to determine the extent of damage we can do to it, then try to save it in the cache area. If that fails, we need to get a better understanding of how the website caching works, looking for a “cacheable target page”. Whether a page is cached does not depend on many factors such as: file extension, content-type, route, status code, and response headers.

Next James Kettle advertised his extension with a very compelling reason: In the response of the cached resources, it can “hide” the unkeyed input , the handwriting is very miserable, so use the extension. to ensure that it is both fast and efficient and safe for Web Services, according to the dontpoisoneveryone criterion.

4. Case Studies

Here are some case studies that he pointed out in his presentations and articles. Hope it helps you better understand this flaw.

4.1 – Discreet poisoning

In the example above, he successfully poisoned with 1 unkeyed input and 2 cache keys. The cache is very easy because the cache keys are unique. More broadly, if you want poison with cache keys on your home pages, then your request must be the first one after the previous cache area is deleted (due to expired). This is difficult and complicated, but there are a few websites that make life easier, like the example below:

The unkeyed part is X-Host , but it’s not the main star here. Take a look at Age and max-age , we can know the cache expiration time and at that time send the requets continuously to poison the cache area, if it satisfies the first request after the cache expires. Anyone who accesses the site will get “hacked”.

4.2 – Selective Poisoning

Similar to the above, the response in the HTTP Header contains very valuable information, here is the Vary field:

It has been shown that there is a User-Agent field in the request that is also used as a cache keys. In parallel, he found that the X-Forwarded-Host field is an unkeyed input. The other is that he hates which brower, which version … and poison it. If the poison is successful, the users who access the site on those browsers will “get involved”.

4.3 – Local Route Poisoning

After trying to find Unkeyed fields by downloading and scouring the top 20,000 PHP projects on Github, he realized that there were two fields: X-Original-URL and X-Rewrite-URL that could override the requested path on the request. . Thanks to the example below, he was able to easily pass WAF:

Add X-Original-URL to:

Adding this header and caching it will cause the Web Server to respond to pages that are incorrectly requested by the user, as in the following example:

It happened in the real world, those who request to / education , the web will return the view of / gambling . Of course if this is more like an attack than a test, that’s why the parameter x = y is changed. In the example above in my presentation, the entire request will be:
GET /education?dontpoisoneveryone=1
This just ensures sending fewer requests but still being cached => Confirming successful poisoning, not affecting the business of Unity.com

5. Conclusion

The article hopes to provide you with useful information on a type of attack that is not known too much but is extremely dangerous. As well as part of the breadth of the HTTP protocol. If you are curious, you can read the references in section 6

6. References

https://portswigger.net/research/practical-web-cache-poisoning
https://www.youtube.com/watch?v=iSDoUGjfW3Q

Share the news now

Source : Viblo