一种新型滥用缓存密钥规范化的缓存投毒技术

写在前面的话

众所周知，如今的网站会包含大量的JavaScript文件/代码，而这些代码一般都取自于TypeScript、SCSS和Webpack等复杂的实现栈。为了减少标准网页的加载时间，开发人员会利用缓存来减少服务器上的负载并减少用户的延迟。虽然缓存通常是为了帮助提高服务的可靠性，使其更易于用户访问，但一些自定义缓存配置可能会引入拒绝服务漏洞，导致服务易受攻击。

缓存投毒DoS基础知识

当攻击者利用目标设备中的缓存来向每一个请求资源的其他用户发送更改响应时，便有可能触发缓存投毒漏洞，下面给出的是缓存投毒拒绝服务攻击的演示样例：

背景内容

大家可以看到，实现DoS攻击所需的只是一个未缓存的Header，它将强制源服务器发送格式错误的请求。因此，我决定通过应用以下方法，在一些私人应用程序中寻找潜在的DoS漏洞：

• 通过识别特定的缓存Header（X-Cache和cf-cache-status等）来检测使用了缓存服务的所有子域名；

• 使用Param Miner来爆破潜在的未缓存的Header；

没花多少时间，我就在assests.redacted.com中找到了一个缓存投毒DoS漏洞，而这个子域名负责托管其中一个私人应用程序所使用的全部JS和CSS文件。这个漏洞是由Fastify的Accept-Version Header所导致的，它将允许客户端返回资源的版本描述信息，我可以使用下列方法来利用该功能：

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

由于缓存密钥中没有包含Accept-version Header，因此任意请求JS文件资源的用户都将收到缓存404响应。令我惊讶的是，这个漏洞竟然让我拿到了2000美金的漏洞奖励，因为Fastify并没有提供金禁用Accept-version Header的选项，该漏洞目前已被标记为了CVE-2020-7764。
然而，在测试了更多的主机之后，越来越明显的是，我将无法用这种技术找到更多的易受攻击的目标。因此，我决定对其他可能的缓存投毒DoS小工具做一些额外的研究。
研究过程中，我发现大多数技术都讨论了非缓存键输入如何导致DoS，但它们忽略了缓存键输入，比如说主机Header或路径等等。因此，我能够想出两个新的攻击方式，并成功复现一次之前的漏洞。
技术一：主机Header大小写规范化
根据RFC-4343的定义，FQDN（全限定域名）必须是大小写敏感的，但是在某些情况下，框架并不会严格遵循这一点。有趣的是，由于主机值应该不区分大小写，一些开发人员会假设在将主机头值引入cachekey时写入小写字符会是安全的，而不会更改发送到后端服务器的实际请求。
在将这两种行为配对时，我能够使用自定义配置的Varnish作为缓存解决方案在主机上实现以下DoS攻击：
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 Found
X-Cache: Miss                              X-Cache: Hit

注意上面大写的主机Header值，它将导致404错误，然后Varnish将使用cache键中主机Header的规范化值来缓存该数据。在将该漏洞上报之后，我又拿到了800美金的漏洞奖励。
分析过程中，我还发现它的负载均衡器（HAProxy）在接收到了大写的Header值时，便会响应404错误。
除了主机Header之外，参数和路径在注入到cachekey之前也可以是小写的，因此我们应该检查缓存处理这些数据时所采用的机制。
技术二：路径规范化
在使用缓存识别子域时，我发现了一个托管图像的特定子域。请求一张图片的请求类似如下：
GET /maps/1.0.5/map/4/151/16.pngHost: maps.redacted.com

跟之前一样，Param Miner无法找到任何隐藏Header，因此我决定深入分析一下。就我目前所知，路径中的最后三个数字是用来告诉服务器应该返回映射的哪一部分范围。我研究了半天，但啥也没获取到。
起初，我认为1.0.5只是一个版本号，所以我没有太过关注，但令我惊讶的是，当我尝试1.0.4时，竟然出现了缓存命中的情况。当然，我认为其他一些API可能使用的是旧版本，所以我测试了1.0.0，它也返回了缓存命中的响应。没过多久我就意识到，无论我用什么替换1.0.5，它都会返回200 OK和一个X-Cache命中响应Header。于是乎，我想出了以下方法：
GET /maps/%2e%2e/map/4/77/16.png          GET /maps/1.0.5/map/4/77/16.png
Host: maps.redacted.com                   Host: maps.redacted.com
HTTP/1.1 404 Not Found                    HTTP/1.1 404 Not Found
X-Cache: Miss                             X-Cache: Hit

同样，在试图提高缓存命中率时，开发人员没有考虑到潜在的DoS攻击，这使得我可以注入%2e%2e（URL编码..），并将请求重定向到服务器上不存在的/map/4/77/16.png，从而导致404错误。
















精彩推荐






































本文始发于微信公众号（FreeBuf）：一种新型滥用缓存密钥规范化的缓存投毒技术