通過 Facebook Notes 可以 DDOS 攻擊任何網站

Facebook Notes 允許使用者使用<img>標籤。每當使用<img>標籤時，Facebook會從外部伺服器抓取影像，並將其快取起來。然而Facebook利用隨機GET引數只快取影像一次，該快取可以被繞過，濫用這個屬性會造成巨大的HTTP GET泛洪。

下面是我在2014年3月3日報告給Facebook漏洞獎賞計劃的過程。

步驟 1.建立一系列img標籤，這些標籤只被抓取了一次。

步驟 2. 使用m.facebook.com建立 notes。它預設整理為固定長度。

步驟 3. 相同使用者或者不同使用者建立多個notes。每一個都會相應1000 多個的http請求。

步驟 4. 同一時間檢視所有的notes，目標伺服器會觀察到有大量的HTTP GET泛洪。成千上萬的GET請求在幾秒鐘傳送到一臺伺服器。並行訪問Facebook的伺服器的總數是100多。

初始回應：問題被拒絕，因為他們誤解了這個bug只會導致一個404的要求，不能夠造成高危害。

通過幾封郵件後，我被要求舉證說明影響。我啟動了一個雲端上的目標虛擬機器，在三臺膝上型電腦上只使用瀏覽器，2-3小時內我實現了400 Mbps的出站流量。

Facebook的伺服器數量：127

當然，影響可能會超過400 Mbps的，因為我只使用了瀏覽器為這個測試，並且我也受由每個獲取的影像的域的瀏覽器執行緒數量限制。我建立概念驗證的指令碼，它可能會導致更大的影響和利用影像向Facebook傳送指令碼。

4月11日，我得到答覆：

“感謝您的耐心和我這裡的長時間拖延表示歉意。我們對這一問題進行了討論，並跟另一個團隊進行了深入探討。

最後，得出的結論是，沒有好的方式來解決這個問題，不可能不顯著降低整體功能而阻止對小型消費級網站的“攻擊”。

不幸的是，所謂的“解決不了”的專案就不在獎賞漏洞的計劃內，所以不會有獎勵這個問題。但我想表示感謝，而且我覺得c提出的攻擊是有趣的，你顯然做了很多工作。我們也希望您繼續提交您找到Facebook的漏洞。”

我不知道為什麼他們不能解決。在影像標籤支援動態連結可能是一個問題，我不是它的忠實粉絲。如果他們想有動態生成的影像，我覺得手動上傳就能滿足使用者的需要。

我也看到了這種型別濫用的一些其他問題：

• 流量放大的情況下：當影像被替換為較大尺寸的PDF或視訊時， Facebook會捕獲到一個巨大的檔案，但使用者什麼也得不到。

每個notes支援1000多條連結，和Facebook會鎖定使用者在產生100個資訊後。由於沒有驗證碼的註釋產生，所有這一切都可以實現自動化，攻擊者可以使用多個使用者輕鬆準備數百個說明雖然持續400 Mbps可能是危險的，但我這測試是最後一次，看它是否確實能有較大的影響。不使用瀏覽器，而使用POC指令碼我能搞定 900 Mbps的出站流量。

我使用了一個普通的13 MB的PDF檔案，被Facebook的處理了180,000多次，涉及Facebook的伺服器數量是112。

我們可以看到流量圖是在895 Mbps上下浮動的。這可能是因為施加於我的虛擬機器在其上使用共享Gbps的乙太網埠雲端計算的最大流量的限制。但這似乎沒有限制在Facebook的伺服器上，所以我們可以想象到底能獲取多少流量。

發現並報告此問題後，我發現谷歌上的類似的問題。結合谷歌和Facebook ，似乎我們可以很容易得到Gbps的流量。
Facebook的處理功能顯示自己可以作為facebook的擴充套件工具。現在它似乎沒有其他的選擇，而必須阻止它，以避免這種滋擾。

[更新1]
https://developers.facebook.com/docs/ApplicationSecurity/ 提到提到一種方式來獲得Facebook獲取的IP地址。

阻塞IP地址可能會比阻止使用者代理更有效。我在部落格上已經得到了很多的回應，並想感謝DOSarrest團隊承認這個發現。

[更新 2]

POC指令碼和訪問日誌現在可以從Github上訪問。這個指令碼非常簡單，僅僅是一個粗略的草稿。請使用它們僅用於研究和分析。

訪問日誌是我用於900 Mbps的測試的確切的日誌。在訪問日誌，你會發現來自Facebook 300,000 多的請求。以前，我只計算了facebookexternalhit/1.1 ，似乎每個IMG標籤，有兩個攻擊，即一個來自1.0版本。另一個則是1.1的。我也嘗試了谷歌，你也會發現來自谷歌的700多條資料。