Facebook Notes 中允许用户包含img标签,一旦检测到img标签,Facebook就会用爬虫从外部服务器抓取标签中指定的图片并缓存。正常情况下Facebook对图片只会缓存一次,但利用随机get参数可以绕过这个限制,那么该特性就可以被利用发动一场大流量的HTTP GET洪水攻击。
这个bug的利用步骤已经于2014年3月3号向Facebook Bug奖励计划报告了。
下面为大家解密我是如何做到的:
第一步,创建一组img标签组成的列表,列表中每一项只会被Facebook的爬虫抓取一次。
<img src=http://targetname/file?r=1></img> <img src=http://targetname/file?r=2></img> ... <img src=http://targetname/file?r=1000></img>
第二步,通过m.facebook.com创建notes,其默认会将notes设置为固定长度。
第三步,为同一用户或不同用户创建一些notes,这样每个notes中就包含1000多个http请求。
第四步,同时浏览所有的notes,目标服务器就会受到因大量http get请求而产生的洪水流量攻击了。几秒之内,成千上万的get请求被发往目标服务器。而Facebook的并发服务器总数怎么也得有100+。
Facebook最初不承认这个Bug,因为他们误认为该bug只会导致404请求,不会对网站造成这么大的冲击。
交流过几封电子邮件之后,他们要求我证明该漏洞是否会产生什么大的影响。我将云中的一台虚拟机作为目标,只使用三个笔记本上的浏览器就在2-3个小时内产生了400+Mbps的出站流量。
Facebook服务器数:127
当然,在实战中其造成的冲击应该比400Mbps大得多,因为我只是为了测试,限制了每个浏览器获取图像的数量。我利用该流量图给Facebook写了一个可以产生更大流量的PoC脚本。
4月11日,我收到Facebook的回复说:
感谢你的耐心,很抱歉我的回复有些晚了。我们已经讨论了该问题,与另一个团队也进行了更加深入的讨论。
最后的结论是,在不会明显影响网站整体功能的情况下,我们暂时没有办法真正修复这个问题使其不被用来“攻击”小网站。
遗憾的是,由于所谓的“无法修复”,该bug就不符合bug奖励计划,所以对该问题的报告也就不会有奖励。不过我得承认,你提出攻击思路很有趣,很有创造力,很明显上个月你投入大量精力研究并报告这一问题。我们对此很感激,希望你可以继续向Facebook bug奖励计划提交任何安全问题。
我不知道他们为什么不修复这个问题,在image标签中支持动态链接可能引出其它问题,我不喜欢这种方式。我想,如果用户要在notes中动态生成图片,手动上传可能会更安全一点。
同时我也想到一些因img标签乱用导致的其它问题:
流量放大攻击:如果图片被大尺寸的pdf文件或视频文件代替,Facebook可能会去抓取这些大尺寸文件,但用户获取不到任何东西。
每个Note支持多于1000个连接,每个用户大约能创建100个左右Notes,之后就无法再创建了。而由于创建note时没有验证码,所有这些都可以自动化完成,攻击者可以轻松用多个帐户创建上百个notes,之后一次性同时浏览所有这些notes。
虽然持续400Mbps的流量可能比较危险,但我仍想最后再测试一次,看其是否能对网站造成更大的影响。
这次不再使用浏览器,而是使用PoC脚本,可以达到大约900Mbps的出站流量。
我使用的是一个普通的13M大小的PDF文件,由Facebook去fetch 180000+次,涉及到112台Facebook服务器。
通过流量表可以看到流量几乎维持在895Mbps,可能是因为我使用的这台云虚拟机的能达到的最大流量就是这么多,该虚拟机使用的是一个共享的Gbps以太网口。看起来Facebook服务器根本没有对爬虫做严格的限制,可以想像那些服务器能产生大多的流量。
发现并报告了这一问题之后,我在Google上发现了类似的问题。结合Google与Facebook,我们可以轻松创造Gbps级别的GET洪水流量。
Facebook爬虫将自自己显示为facebookexternalhit。目前看起来现在也没什么其它方法来避免这种麻烦。
[更新]
https://developers.facebook.com/docs/ApplicationSecurity/中提到一种获取属于Facebook爬虫的IP地址的方式:
whois -h whois.radb.net - '-i origin AS32934' | grep ^route
直接阻断IP地址比阻断useragent可能更有效。
原文地址: http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/