Web cache entanglement – Novel pathways to poisoning

Each year we anticipate new research from James Kettle at the annual Black Hat USA event and he’s become known for his web cache research. This year he announced Web Cache Entanglement – new techniques to exploit web cache poisoning. We’ve previously covered his work concerning web cache poisoning and HTTP request smuggling which is intriguing for any software engineer to know about. This article will briefly highlight the main points about Web Cache Entanglement:

Introduction to Caches

Before we get into the details of Web Cache Entanglement, let’s recap what is cache. Caches save copies of response data in order to reduce the load on the backend. A cache will use what is called a cache key to determine if it has the appropriate response for the given request or if it must forward the request to the backend for a new response. 

Image source: https://www.keycdn.com/support/cache-definition-explanation 

The cache key will usually consist of:

• request method (GET, POST, etc.)
• query string
• Host header and potentially one or two extra headers from the request. 

The other parts of the request that are not included in the cache keys are called “unkeyed” components. These unkeyed parts of the request can be potentially used to manipulate the cache and serve harmful responses to unsuspecting users.

However, in Kettle’s newest research he examines how it is possible to use “keyed” components, such as the Host header and request line, in a web cache poisoning attack due to the way web servers “parse, transform, and normalize” the request data.

Methodology

The methodology for identifying and successfully exploiting Web Cache Entanglement can be broken down into three steps: 

1. selecting a cache oracle
2. probe key handling
3. exploiting the vulnerability through gadget chaining

Select a Cache Oracle

Every website implements caching differently so it is important to first pick an endpoint on the target site and understand its functionality. This is referred to as the cache oracle. The endpoint must be cacheable and there must be a way to tell if you got a cache hit or miss. 

This can be via some sort of HTTP header or “inferred through dynamic content or response timing”. Additionally, the cache oracle should reflect the URL and at least one query parameter.

Probe Key Handling

Now it is important to determine if the requests are transformed in any way when saved in the cache key.

Common exploitable transformations include removing specific query parameters, removing the entire query string, removing the port from the Host header, and URL-decoding.
– James Kettle

To determine if there is some sort of transformation, a series of two slightly different requests are sent. If the second request causes a cache hit, this indicates that it was issued with the same cache key as the first. 

For example, if the first request is sent with Host:website.com:1337 and causes a cache miss, but the next request is sent with Host:website.com (without the port) and causes a cache hit, this indicates the same cache key is used.

Exploit

The final step in exploiting this new form of web cache poisoning is to chain the recently found transformation with a gadget on the target website. A gadget is a reflected, client-side behavior like an XSS or open redirect. Cache poisoning can be combined with gadgets in three main ways:

1. It can convert a reflected XSS into a stored XSS since cache poisoning affects the same page for everyone.
2. It can enable exploitation of dynamic content in a site’s resource files.
3. It can enable exploitation of previously unexploitable vulnerabilities that rely on malformed requests that browsers won’t send.

Conclusion

Kettle’s research highlights that the security of web caches has been overlooked for years and that there is a high possibility that there are more undiscovered vulnerabilities in web caches. Some steps that you can take avoid some of these vulnerabilities are:

1. Avoid rewriting the cache key. Instead, rewrite the request.
2. Do not support fat GET requests, which is when an application accepts GET requests that have a body.
3. Patch vulnerabilities that are considered zero-risk due to browser constraints, such as self-XSS or input reflection in a resource file.

It is most important to understand that web-caching opens new ways of exploiting vulnerabilities throughout the web. The best way to avoid these issues is to treat all vulnerabilities, exploitable or not, as real security issues.

Further reading on Web Cache Entanglement:

• accompanying white paper from James Kettle, Portswigger