咨询热线:

栏目列表

您所在的位置 >> 主页 > 技术研究 > 安全漏洞 > >> 正文

我是如何利用Facebook DDoS攻击任意网站的

时间:2014-05-07 09:43 来源:freebuf 作者:Taskiller 点击:

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 - &#039;-i origin AS32934&#039; | grep ^route

直接阻断IP地址比阻断useragent可能更有效。



福建省海峡信息技术有限公司版权所有
1999-2015 Fujian Strait Information Corporation. All Rights Reserved.
闽ICP备06011901号 Email:siss@heidun.net TEL:0591-87303715 地址:福建省福州市北环中路61号海峡信息大楼2F