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

這個(gè)bug的利用步驟已經(jīng)于2014年3月3號(hào)向Facebook Bug獎(jiǎng)勵(lì)計(jì)劃報(bào)告了。

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

第一步，創(chuàng)建一組img標(biāo)簽組成的列表，列表中每一項(xiàng)只會(huì)被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>

第二步，通過(guò)m.facebook.com創(chuàng)建notes，其默認(rèn)會(huì)將notes設(shè)置為固定長(zhǎng)度。

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

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

Facebook最初不承認(rèn)這個(gè)Bug，因?yàn)樗麄冋`認(rèn)為該bug只會(huì)導(dǎo)致404請(qǐng)求，不會(huì)對(duì)網(wǎng)站造成這么大的沖擊。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

通過(guò)流量表可以看到流量幾乎維持在895Mbps，可能是因?yàn)槲沂褂玫倪@臺(tái)云虛擬機(jī)的能達(dá)到的最大流量就是這么多，該虛擬機(jī)使用的是一個(gè)共享的Gbps以太網(wǎng)口?？雌饋?lái)Facebook服務(wù)器根本沒(méi)有對(duì)爬蟲做嚴(yán)格的限制，可以想像那些服務(wù)器能產(chǎn)生大多的流量。

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

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

[更新]

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/