Web缓存投毒实战（五）

　　内部缓存投毒

　　Drupal通常与Varnish等第三方缓存一起使用，但它也包含默认启用的内部缓存。此缓存知道X-Original-URL协议头并将其包含在其缓存键中，但错误的是包含协议头中查询字符串：

　　

　　之前的攻击让我们用另一个路径替换，这能让我们覆盖上面的查询字符串：

　　

　　离目标更进一步，但作用有限 —— 我们需要第三种方法。

　　Drupal开启重定向

　　在阅读Drupal的 URL-override代码时，我注意到一个极其危险的功能—— 在所有重定向响应中，可以用"destination"查询参数覆盖重定向目标。Drupal尝试进行一些URL解析以确保它不会重定向到外部域，但这很容易绕过：

　　

　　在Drupal的路径中看到了双斜杠“//”并试图向“/”发出重定向来规范化它，然后目标参数启动。Drupal认为目标URL告诉人们使用用户名evil.net访问unity。但实际上，网络浏览器会在evil@unity上自动将转换为/，登陆用户。

　　再次强调，开启重定向本身并没啥作用，但现在我们有了构建高危漏洞所需的所有的块。

　　持续重定向劫持

　　我们可以将参数覆盖攻击与重定向结合起来，以持久地劫持任何重定向。Pinterest商业网站上的某些页面恰好通过重定向导入JavaScript。以下请求中缓存项用蓝色显示，参数用橙色显示：

　　

　　这劫持了JavaScript导入的文件的目标地址，让我可以完全控制business.pinterest上几个静态页面：

　　

　　嵌套缓存投毒

　　其他Drupal站点不那么好对付，也不会通过重定向导入任何重要的资源。幸运的是，如果站点使用外部缓存（几乎所有高流量的Drupal站点都使用它），我们可以使用内部缓存来向外部缓存投毒，并在此过程中将任意响应转换为重定向。这是一个两阶段的攻击。首先，我们使用恶意重定向来投毒内部缓存以替换 /redir：

　　

　　接下来，为了替换/download?v=1，我们使用第一步的投毒/redir来投毒外部缓存：

　　

　　最终结果是在unity上点击“下载安装程序”会从evil.net下载一些欺骗性恶意软件。此技术还可用于很多其他类型的攻击，包括将欺骗性项目插入RSS源，使用网络钓鱼页替换登录页，以及通过动态脚本导入存储XSS。

　　这是一个关于Drupal安装的此类攻击的视频：

　　该漏洞已于2018-05-29向Drupal，Symfony和Zend团队披露，并且在希望您阅读本文时，通过协调补丁发布来禁用这些漏洞。

　　跨云投毒

　　如您所料，一些漏洞报告引发了有趣的反应和响应。

　　使用CVSS对我的提交的报告进行评分的一个分析者，标记对CloudFront缓存投毒报告的实现难度为“high”，因为攻击者可能需要租用几个VPS才能毒害所有CloudFront的缓存。我抵制是否给定为“high”难度的争论，我把这作为一个机会，探讨是否可以在不依赖VPS的情况下进行跨区域攻击。

　　事实证明，CloudFront有一个有用的缓存地图，可以使用从一系列地理位置发出免费在线服务 DNS查询以轻松识别IP地址。在舒适的卧室中使特定区域中毒就像使用curl /Burp的主机名覆盖功能将攻击定位到其中一个IP一样简单。

　　由于Cloudflare有更多的区域缓存，我决定也看看它们。Cloudflare在线发布所有IP地址列表，因此我编写了一个快速脚本，通过每个IP请求waf.party/cgn-cgi/trace并记录我点击的缓存：

　　

　　这表明，锁定waf.party（在爱尔兰）时，我可以从曼彻斯特的家中点击以下缓存

　　

　　防御

　　缓存投毒的最强防御方法是禁用缓存。对某类人，这明显不切实际。但我怀疑很多网站开始使用Cloudflare等服务进行DDoS保护或简易SSL，并且因默认情况下启用了缓存导致更易中毒。

　　如果您足够警惕定义为“静态”的内容，那么将缓存限制为纯静态响应也是有效的。

　　同样，避免从头文件和cookie中获取输入是防止缓存投毒的有效方法，但很难知道其他层和框架是否在偷偷支持额外的头文件。因此，我建议使用Param Miner审核应用程序的每个页面以清除非缓存键的输入。

　　一旦在应用程序中识别出非缓存键的输入，理想的解决方案就是彻底禁用它们。若不如此，您可以剥离缓存层的输入，或将它们添加到缓存键。某些缓存允许您使用Vary协议头来键入非缓存键的输入，而其他缓存允许您定义自定义缓存键，但可能会将此功能限制为“企业”客户。

　　最后，无论您的应用程序是否具有缓存，您的某些客户端可能在其末端都有缓存，因此不应忽略HTTP协议头中的XSS等客户端漏洞。

　　结论

　　Web缓存投毒不只是理论上的漏洞，臃肿的应用程序和高耸的服务器堆栈正在将它带向大众。我们已经看到，有名的框架也可能隐藏无所不在的危险，假设其他人只是因为它是开源的并且拥有数百万用户而阅读了源代码，这也不一定是安全的。我们还看到如何在网站放置缓存可以将其从完全安全变到极易受到攻击。我认为这是一种大趋势。网站越依赖于辅助系统，他们的安全状况越来越难以单独进行充分评估。

　　最后，我设置了一个小挑战来测试读者的知识储备，同时好奇其他研究人员将会在哪里利用网络缓存投毒。