Facebook Notes 中允許用戶包含img標(biāo)簽，一旦檢測到img標(biāo)簽，F(xiàn)acebook就會用爬蟲從外部服務(wù)器抓取標(biāo)簽中指定的圖片并緩存。正常情況下Facebook對圖片只會緩存一次，但利用隨機(jī)get參數(shù)可以繞過這個限制，那么該特性就可以被利用發(fā)動一場大流量的HTTP GET洪水攻擊。

這個bug的利用步驟已經(jīng)于2014年3月3號向Facebook Bug獎勵計劃報告了。

下面為大家解密我是如何做到的：

第一步，創(chuàng)建一組img標(biāo)簽組成的列表，列表中每一項只會被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創(chuàng)建notes，其默認(rèn)會將notes設(shè)置為固定長度。

第三步，為同一用戶或不同用戶創(chuàng)建一些notes，這樣每個notes中就包含1000多個http請求。

第四步，同時瀏覽所有的notes，目標(biāo)服務(wù)器就會受到因大量http get請求而產(chǎn)生的洪水流量攻擊了。幾秒之內(nèi)，成千上萬的get請求被發(fā)往目標(biāo)服務(wù)器。而Facebook的并發(fā)服務(wù)器總數(shù)怎么也得有100+。

Facebook最初不承認(rèn)這個Bug，因為他們誤認(rèn)為該bug只會導(dǎo)致404請求，不會對網(wǎng)站造成這么大的沖擊。

交流過幾封電子郵件之后，他們要求我證明該漏洞是否會產(chǎn)生什么大的影響。我將云中的一臺虛擬機(jī)作為目標(biāo)，只使用三個筆記本上的瀏覽器就在2－3個小時內(nèi)產(chǎn)生了400+Mbps的出站流量。

Facebook服務(wù)器數(shù)：127

當(dāng)然，在實戰(zhàn)中其造成的沖擊應(yīng)該比400Mbps大得多，因為我只是為了測試，限制了每個瀏覽器獲取圖像的數(shù)量。我利用該流量圖給Facebook寫了一個可以產(chǎn)生更大流量的PoC腳本。

4月11日，我收到Facebook的回復(fù)說：

感謝你的耐心，很抱歉我的回復(fù)有些晚了。我們已經(jīng)討論了該問題，與另一個團(tuán)隊也進(jìn)行了更加深入的討論。

最后的結(jié)論是，在不會明顯影響網(wǎng)站整體功能的情況下，我們暫時沒有辦法真正修復(fù)這個問題使其不被用來“攻擊”小網(wǎng)站。

遺憾的是，由于所謂的“無法修復(fù)”，該bug就不符合bug獎勵計劃，所以對該問題的報告也就不會有獎勵。不過我得承認(rèn)，你提出攻擊思路很有趣，很有創(chuàng)造力，很明顯上個月你投入大量精力研究并報告這一問題。我們對此很感激，希望你可以繼續(xù)向Facebook bug獎勵計劃提交任何安全問題。

我不知道他們?yōu)槭裁床恍迯?fù)這個問題，在image標(biāo)簽中支持動態(tài)鏈接可能引出其它問題，我不喜歡這種方式。我想，如果用戶要在notes中動態(tài)生成圖片，手動上傳可能會更安全一點。

同時我也想到一些因img標(biāo)簽亂用導(dǎo)致的其它問題：

流量放大攻擊：如果圖片被大尺寸的pdf文件或視頻文件代替，F(xiàn)acebook可能會去抓取這些大尺寸文件，但用戶獲取不到任何東西。

每個Note支持多于1000個連接，每個用戶大約能創(chuàng)建100個左右Notes，之后就無法再創(chuàng)建了。而由于創(chuàng)建note時沒有驗證碼，所有這些都可以自動化完成，攻擊者可以輕松用多個帳戶創(chuàng)建上百個notes，之后一次性同時瀏覽所有這些notes。

雖然持續(xù)400Mbps的流量可能比較危險，但我仍想最后再測試一次，看其是否能對網(wǎng)站造成更大的影響。

這次不再使用瀏覽器，而是使用PoC腳本，可以達(dá)到大約900Mbps的出站流量。

我使用的是一個普通的13M大小的PDF文件，由Facebook去fetch 180000+次，涉及到112臺Facebook服務(wù)器。

通過流量表可以看到流量幾乎維持在895Mbps，可能是因為我使用的這臺云虛擬機(jī)的能達(dá)到的最大流量就是這么多，該虛擬機(jī)使用的是一個共享的Gbps以太網(wǎng)口。看起來Facebook服務(wù)器根本沒有對爬蟲做嚴(yán)格的限制，可以想像那些服務(wù)器能產(chǎn)生大多的流量。

發(fā)現(xiàn)并報告了這一問題之后，我在Google上發(fā)現(xiàn)了類似的問題。結(jié)合Google與Facebook，我們可以輕松創(chuàng)造Gbps級別的GET洪水流量。

Facebook爬蟲將自自己顯示為facebookexternalhit。目前看起來現(xiàn)在也沒什么其它方法來避免這種麻煩。

[更新]

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/