Shulou(Shulou.com)05/31 Report--

This article is about the abuse of cache key normalization in web security. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

Words written in the front

It is well known that today's websites contain a large number of JavaScript files / code, which are generally taken from complex implementation stacks such as TypeScript, SCSS, and Webpack. In order to reduce the loading time of standard web pages, developers use caching to reduce the load on the server and reduce user latency. Although caching is usually designed to help improve the reliability of the service and make it easier for users to access, some custom cache configurations may introduce a denial of service vulnerability, making the service vulnerable.

Basic knowledge of cache poisoning DoS

When an attacker uses the cache in the target device to send a change response to each other user requesting a resource, it is possible to trigger a cache poisoning vulnerability. Here is a demonstration example of a cache poisoning denial of service attack:

Background content

As you can see, all that is needed to implement a DoS attack is an uncached Header, which forces the source server to send a malformed request. Therefore, I decided to look for potential DoS vulnerabilities in some private applications by applying the following methods:

Detect all subdomains that use the caching service by identifying a specific cache Header (X-Cache, cf-cache-status, etc.)

Use Param Miner to explode potential uncached Header

It didn't take me long to find a cache poisoning DoS vulnerability in assests.redacted.com, and this subdomain is responsible for hosting all the JS and CSS files used by one of the private applications. This vulnerability is caused by Fastify's Accept-Version Header, which will allow the client to return the version description of the resource, which I can take advantage of in the following ways:

GET / assets/login.js?cb=1 GET / assets/login.js?cb=1Host: assets.redacted.com Host: assets.redacted.comAccept-Version: iustin HTTP/1.1 404 Not Found HTTP/1.1 404 Not FoundX-Cache: Miss X-Cache: Hit

Because Accept-version Header is not included in the cache key, any user who requests a JS file resource will receive a cached 404 response. To my surprise, this vulnerability got me a $2000 vulnerability reward because Fastify did not provide the option to disable Accept-version Header, which has been marked as CVE-2020-7764.

However, after testing more hosts, it became more and more obvious that I would not be able to find more vulnerable targets with this technique. Therefore, I decided to do some additional research on other possible cache poisoning DoS gadgets.

In the course of my research, I found that most technologies discuss how non-cached key input leads to DoS, but they ignore cached key input, such as host Header or path, and so on. As a result, I was able to come up with two new attacks and successfully recreate the previous vulnerabilities.

Technology 1: case normalization of host Header

According to RFC-4343 's definition, FQDN (fully qualified domain names) must be case-sensitive, but in some cases, the framework does not strictly follow this. Interestingly, because host values should be case-insensitive, some developers assume that it is safe to write lowercase characters when introducing host header values into cachekey without changing the actual requests sent to the back-end server.

When pairing these two behaviors, I was able to implement the following DoS attacks on the host using custom configured Varnish as a caching solution:

GET / images/posion.png?cb=1 GET / images/posion.png?cb=1 Host: Cdn.redacted.com Host: cdn.redacted.com HTTP/1.1 404 Not Found HTTP/1.1 404 Not FoundX-Cache: Miss X-Cache: Hit

Notice the uppercase host header value above, which will cause a 404 error, and then Varnish will cache the data using the normalized value of the host Header in the cache key. After reporting the loophole, I got another $800 bug reward.

During the analysis, I also found that its load balancer (HAProxy) responded to a 404 error when it received an uppercase header value.

In addition to the host Header, parameters and paths can also be lowercase before being injected into cachekey, so we should examine the mechanism used by the cache to process these data.

Technology 2: path standardization

When using caching to identify subdomains, I found a specific subdomain of a managed image. The request for a picture is similar to the following:

GET / maps/1.0.5/map/4/151/16.pngHost: maps.redacted.com

As before, Param Miner couldn't find any hidden Header, so I decided to take a closer look. As far as I know, the last three digits in the path are used to tell the server which part of the mapping should be returned. I studied for a long time, but got nothing.

At first, I thought 1.0.5 was just a version number, so I didn't pay much attention to it, but to my surprise, when I tried 1.0.4, there was a cache hit. Of course, I thought some other API might be using older versions, so I tested 1.0.0, and it also returned a cache hit response. It wasn't long before I realized that no matter what I replaced 1.0.5 with, it would return 200 OK and a X-Cache hit response Header. So I came up with the following ways:

GET / maps/%2e%2e/map/4/77/16.png GET / maps/1.0.5/map/4/77/16.pngHost: maps.redacted.com Host: maps.redacted.com HTTP/1.1 404 Not Found HTTP/1.1 404 Not FoundX-Cache: Miss X-Cache: Hit

Similarly, when trying to improve the cache hit ratio, the developer did not take into account the potential DoS attack, which allowed me to inject% 2e%2e (URL encoding..) and redirect the request to / map/4/77/16.png that does not exist on the server, resulting in a 404 error.

Thank you for reading! This is the end of this article on "the cache poisoning technology of abusing cache key standardization in web security". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it out for more people to see!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.