Web缓存投毒实战（二）

　　投毒的基本原理

　　尽管听上去很可怕，但缓存投毒实际上很容易被利用。首先，让我们来看看Red Hat的主页。Param Miner程序立即发现了一个非缓存键的输入：

　　

　　在这里，我们可以看到应用程序使用X-Forwarded-Host协议头在元标记(meta tag)内生成打开图片的 URL。下一步是探索它是否可利用 - 我们将从一个简单的 跨站点脚本 Payload开始：

　　

　　我们做出一个响应，对任何查看它的人执行任意JavaScript，最后检查此响应是否已存储在缓存中，以便将其传递给其他用户。不要让"Cache Control: no-cache" 协议头影响你，尝试攻击总是比假设它不起作用好。您可以先通过重新发送没有恶意协议头的请求进行验证，然后直接在另一台计算机上的浏览器中获取URL：

　　

　　这很简单。尽管返回响应中没有任何表明缓存存在的协议头，但我们此番漏洞利用已被明确缓存。DNS快速查询提供了解释 ——www.redhat 是

　　www.redhat.edgekey.net 的CNAME(别名)，表明它正在使用Akamai的CDN。

　　谨慎投毒

　　在这一点上，我们已经证明可以通过使www.redhat/en?dontpoisoneveryone=1投毒来进行攻击，而且避免了影响网站的实际访问者。为了真正使博客的主页投毒并使后续所有的访问者访问我们的漏洞，我们需要确保在缓存的响应过期后将第一个请求发送到主页。

　　也许可以尝试使用像Burp Intruder或自定义脚本之类的工具来发送大量请求，但这种流量大的方法很难不被发现。攻击者可以通过逆向目标的缓存到期系统并通过浏览文档和监控网站来预测准确的到期时间来避免这个问题，但这听起来就很难。

　　幸运的是，许多网站让我们攻击。在unity3d中获取此缓存投毒漏洞：

　　

　　我们用一个非缓存键的输入 —— X-Host协议头 来生成导入脚本的URL。响应协议头“Age”和“max-age”分别是当前响应的时间和它将过期的时间。总之，这些告诉我们应该发送的有效Payload确切的秒数，以确保我们的响应被缓存。

　　选择性投毒

　　HTTP请求头可以为缓存的内部工作节省时间。拿下面这个著名的网站：

　　

　　这看起来几乎与第一个例子相同。但是，Vary协议头告诉我们，User-Agent可能是缓存键的一部分，我通过手动测试确认了这一点。这意味着，因为我们使用的是Firefox 60，所以我们的漏洞只会提供给其他使用Firefox 60用户。我们可以使用普遍的User-Agent列表来确保大多数访问者接收我们的漏洞，但这种行为使我们可以更具选择性地攻击。如果您了解User-Agent，则可以针对特定人员定制攻击，甚至可以隐藏自己的网站监控。

　　DOM投毒

　　利用未加密的输入并不总是像写入XSS Payload一样容易。如以下请求：

　　

　　我们已经控制了"data-site-root"属性，但我们不能突破以使用XSS，甚至不清楚这个属性用于什么。为了找到答案，我在Burp中创建了一个匹配并替换的规则，为所有请求添加了“X-Forwarded-Host：id.burpcollaborator.net”协议头，然后浏览了该站点。当加载某些页面时，Firefox会将JavaScript生成的请求发送到我的服务器：

　　

　　该路径表明，在网站的某个地方，有一些JavaScript代码使用data-site-root属性来决定从哪里加载一些国际数据。我试图通过获取

　　catalog.data.gov/api/i18n/en 来找出这些数据应该是什么样的，但只是收到了一个空的JSON响应。幸运的是，将"en"改为"es"拿到了一个线索：

　　

　　该文件包含用于将短语翻译为用户所选语言的映射。通过创建我们自己的翻译文件并使缓存投毒，我们可以将短语翻译变成漏洞：

　　

　　最终结果表明：任何查看包含“显示更多”文字的网页的人都会被利用。

　　劫持Mozilla SHIELD

　　我配置的“X-Forwarded-Host”匹配/替换规则可帮助解决上一个漏洞，而且产生意想不到的效果。除了与catalog.data.gov的交互之外，我还收到了一些非常神秘的内容：

　　

　　Origin: 相当罕见。我之前从来没有见过一个浏览器发送一个完全小写的Origin 协议头。通过筛选代理的历史记录，发现罪魁祸首是Firefox本身。Firefox曾试图获取一份“recipes”列表，作为SHIELD系统的一部分，用于静默安装扩展以用于营销和研究目的。该系统因曾强行分发“Mr Robot”扩展引起了消费者的强烈反对而闻名。

　　无论如何，看起来X-Forwarded-Host协议头欺骗了这个系统，将Firefox引导到我自己的网站以获取recipes：

　　

　　Recipes看起来像：

　　

　　该系统使用NGINX进行缓存，并很乐意地保存我的投毒响应并将其提供给其他用户。Firefox在浏览器打开后不久就会抓取此URL并定期重新获取它，最终意味着数千万Firefox日常用户都可能从我的网站上检索recipes。

　　这为投毒提供了多种可行方案。Firefox使用的recipes有签名，所以我不能通过只安装恶意插件来使代码执行，但我可以使数千万真正的用户访问我构造的URL。显而易见，这可作为DDoS使用。如果与适当的内存破坏漏洞相结合，结果将非常严重。此外，一些后端Mozilla系统使用无符号recipes，这可用于在其基础设施内部获得立足点并获得recipes签名密钥。此外，我可以重做之前选择的recipes，这可能会大规模强制用户安装一个已知的漏洞扩展，或导致Mr Robot意外返回。

　　我向Mozilla报告了这一点，他们在24小时内修补了他们的基础设施，但是对于严重程度的判断存在一些分歧，因此只获得了1000美元的奖励。