我是如何利用Facebook DDoS攻擊任意網站的
責編：admin ｜2014-05-02 16:20:26 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。目前看起來現在也沒什么其它方法來避免這種麻煩。