新闻链接：26aK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3k6J5k6h3g2T1N6h3k6Q4x3X3g2U0L8$3#2Q4x3V1k6S2M7Y4c8A6j5$3I4W2M7#2)9J5c8Y4N6W2j5W2)9J5c8U0x3K6x3K6b7#2i4K6u0W2K9s2c8E0L8l9`.`.
新闻时间：2014-04-30
新闻正文： 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的出站流量。
    当然，在实战中其造成的冲击应该比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。目前看起来现在也没什么其它方法来避免这种麻烦。
    [更新]
    2d2K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1k6i4k6W2L8r3!0H3k6i4u0K6i4K6u0W2k6X3q4U0k6h3u0G2L8$3E0Q4x3X3g2U0L8$3#2Q4x3V1k6V1L8$3y4K6i4K6u0r3b7i4m8H3L8r3W2U0j5i4c8A6L8$3&6e0k6h3y4#2M7X3W2@1P5g2)9J5c8W2!0q4y4q4!0n7z5q4!0m8c8q4!0q4y4W2)9^5c8W2)9&6x3q4!0q4y4g2)9^5z5q4!0n7x3q4!0q4y4q4!0n7z5q4)9^5x3q4!0q4y4#2!0m8y4#2)9^5c8q4!0q4z5q4)9^5c8g2!0n7y4#2!0q4y4g2)9^5c8W2)9&6y4W2!0q4y4g2!0n7x3g2)9&6c8g2!0q4y4q4!0n7b7g2)9^5c8f1k6S2j5$3g2T1L8$3!0C8i4@1f1%4i4K6R3^5i4@1q4o6i4@1f1^5i4K6V1&6i4@1q4n7i4@1f1%4i4K6W2m8i4K6R3@1d9g2m8Q4c8e0g2Q4z5f1y4Q4b7U0m8Q4c8e0g2Q4z5f1c8Q4z5o6m8Q4c8e0N6Q4z5f1q4Q4z5o6c8Q4c8e0k6Q4z5e0k6Q4b7U0W2Q4c8e0g2Q4b7V1y4Q4z5p5k6Q4c8f1k6Q4b7V1y4Q4z5f1p5`.
    whois -h whois.radb.net - '-i origin AS32934' | grep ^route
    直接阻断IP地址比阻断useragent可能更有效。
    原文地址

[培训]科锐逆向工程师培训第53期2025年7月8日开班！