0%

Web Cache Poisoning——web缓存投毒

前情摘要

闲的蛋疼用awvs捡洞的时候发现某网站报了个Web Cache Poisoning的high risk,前两天也听兄弟们提起过这个漏洞,在下一向对这种新型攻击手段抱有极大的兴趣,所以研究了一下相关的内容。

总览

大概看了一下,主要用于DOS比较多,有点像之前的http偷渡攻击的CL-TE,污染下一个访问者对请求导致他请求失败是主流的口径,这样的话要捡洞骗厂商钱好像没那么容易,毕竟这屌危害也没啥厂商傻到扶贫。

dos的工作原理

基本的攻击流程如下所示:

1、攻击者发送简单的HTTP请求,请求中包含针对目标web资源的恶意头部。该请求由中间缓存端处理,恶意头部字段尽量保持隐蔽;

2、由于缓存端并没有存储目标资源的最新副本,因此会将请求转发至原始服务器。在原始服务器端,由于请求中包含恶意头部,因此会出现错误;

3、因此,原始服务器会返回一个错误页面,该页面(而不是所请求的资源)会被缓存端存储;

4、当攻击者在响应中看到错误页面,就知道攻击已成功完成;

5、合法用户在后续请求中尝试获取目标资源;

6、合法用户无法拿到原始内容,会得到已被缓存的错误页面。

upload successful

(以上内容节选至安全客 https://www.anquanke.com/post/id/189507

深入研究

部分内容参考

https://portswigger.net/blog/practical-web-cache-poisoning

译文:

https://xz.aliyun.com/t/2585

相关概念

概念部分粘贴的部分原文,删掉了废话,提炼了一下总结。

缓存

缓存旨在通过减少延迟来加速页面加载,还可以减少应用程序服务器上的负载。一些公司使用像Varnish这样的软件来托管他们的缓存,而其他公司选择依赖像Cloudflare这样的内容交付网络(CDN),将缓存分散在各个地理位置。此外,一些流行的Web应用程序和框架(如Drupal)具有内置缓存功能。

还有其他类型的缓存,例如客户端浏览器缓存和DNS缓存,但它们不是本研究的重点。

缓存键(Cache keys)

缓存的概念可能听起来简洁明了,但它隐藏了一些风险。每当缓存收到对资源的请求时,它需要确定它是否已经保存了这个确切资源的副本,并且可以使用该副本进行回复,或者是否需要将请求转发给应用程序服务器。

确定两个请求是否正在尝试加载相同的资源可能很棘手,例如浏览器发出的请求:

upload successful

通过请求逐字节匹配的方法是完全无效的,因为HTTP请求充满了无关紧要的数据

缓存使用缓存键的概念解决了这个问题 - 缓存键的一些特定组件用于完全标识所请求的资源。在上面的请求中,橙色突出显示了典型缓存键中包含的值。

这意味着缓存认为以下两个请求是等效的,并使用从第一个请求缓存的响应来响应第二个请求:

upload successful

因此,该页面将提供给第二位访问者错误的语言格式。这暗示了这个问题 —— 任何由未加密的输入触发的响应差异,都可以存储并提供给其他用户。理论上,站点可以使用“Vary”响应头来指定应该键入的请求头。在实际中,Vary协议头仅初步使用,像Cloudflare这样的CDN却完全忽略它,人们甚至没有意识到他们的应用程序支持基于任何协议头的输入。

这会导致许多意想不到的破坏,特别是当有人故意开始利用它时,它的危害才会真正开始体现。

利用分析

从上述的分析来看,初步感觉也就是前面综述中写的dos的应用。下边儿是我把老外的文章读完后的实际案例,仅供参考。

漏洞发现

首先是老外写的burp插件

upload successful

直接burp插件商店装就完事儿了。

然后利用这玩意儿可以用来识别输入点,意思是可以通过这个判断是否存在必不可能成为cache-key的输入点,当然手工也可以挨着挨着去测试,主要测试的是cookie和headers,找到输入点后判断其危害并判断能否将其置于缓存中。

案例分享

分享一个无危害的web cache poisoning,作为缓存投毒攻击的攻击与防护案例。

upload successful

upload successful

这是两个不同的请求,但是缓存服务器将其判断为同样请求,将第一次请求的缓存内容作为响应发送给客户端。

在针对这个网站进行测试的时候我发现,缓存服务器的cache key是存在于cookies中,只要cookies发生了变化,缓存服务器就不认为是同样的请求,而每个用户正常访问网站的cookies由网站随机分配,是完全不同的,所以也就导致了不能将这个“带毒”缓存响应给其他用户,个人认为这种防护手段比较有想法,既不影响高速缓存服务器的工作,又避免了由于提高用户体验影响到用户安全。

总结

结合xss漏洞利用的可能性会高一些,老外的文章中还有一些比较深入的分析,什么路由缓存投毒啊之类的,大概意思是结合实际的业务可能提升某些漏洞的危害,建议直接去老外的文章看案例。