【導讀】GitLab最近又被DDoS攻擊給盯上了，峰值流量超1 Tbps。此次攻擊的漏洞來源于4月份已經修復的bug，但仍有30000臺未安裝更新的服務器遇難。

GitLab 又被分布式拒絕服務（DDoS）攻擊了！

負責谷歌DDoS防御的云安全可靠性工程師Damian Menscher最近披露，有攻擊者正在利用 GitLab 托管服務器上的安全漏洞來構建僵尸網絡，并發起規模驚人的分布式拒絕服務攻擊（DDoS）。其中一些攻擊的峰值流量，甚至超過了1 Tbps 。

本次攻擊利用的漏洞編號為CVE-2021-22205，GitLab曾在2021年4月修復該漏洞。

此次攻擊由 William Bowling發現，并通過Bug Bount報告給GitLab，漏洞主要影響的組件是Exiftool，可以用于從上載到Web服務器的圖像中刪除元數據的庫。

GitLab 在他們私有版本GitLab Community Edition（CE）和Enterprise Edition（EE）中使用Exiftool，也就是GitLab服務的開源和商業版本，公司可以在自己的服務器上安裝，用于在安全環境中處理私有代碼，而不必使用GitLab的云服務。

在通過Hackerone提交的一份報告中，Bowling說他發現了一種濫用Exiftool處理用于掃描文檔的DJVU文件格式上傳的方法，以獲得對整個GitLab Web服務器的控制權。

據意大利安全公司HN Security稱，利用這一漏洞的攻擊始于今年6月，該公司上周首次報告了漏洞的使用跡象。

當時安全研究員Piergiovanni Cipolloni表示，在發現有隨機命名的用戶被添加到受感染的GitLab服務器后，他們隨即對此展開了調查。這些用戶很可能是由攻擊者一手創建，旨在對受害系統實施遠程控制。

盡管HN Security尚不清楚這些攻擊的目的，但Google工程師Damian Menscher已于昨日表示，被黑服務器屬于某個巨型僵尸網絡的一部分。

該網絡包含成千上萬個受感染的GitLab實例，且正被用于發起大規模的DDoS攻擊。遺憾的是，盡管GitLab已于2021年4月完成了修補，仍有大約30000個GitLab服務器尚未打上補丁。

這說明了什么？不要禁用安全更新！當然了，Windows更新的開啟和關閉是一個玄學問題。

值得注意的是，GitLab問題核心的Exiftool漏洞（CVE-2021-22204）也可能影響部署該工具的其他類型的Web應用程序，，其他類型的Web應用程序也可能需要修補。

防止攻擊的簡單方法是阻止DjVu文件在服務器級別上載，如果公司不需要處理此文件類型的話。

DDoS（分布式拒絕服務）實際上是一種常見的網絡攻擊，亦稱洪水攻擊，其目的在于使目標電腦的網絡或系統資源耗盡，使服務暫時中斷或停止，導致其正常用戶無法訪問。當黑客使用網絡上兩個或以上被攻陷的電腦作為「僵尸」向特定的目標發動「拒絕服務」式攻擊時，稱為分布式拒絕服務攻擊。

就是說服務器的流量都被用于服務僵尸網絡了，當正常用戶訪問時，已經沒有多余的能力來應對了，對于用戶來說網站癱瘓了。

首先，DDoS攻擊會拒絕訪問你的網站或服務。攻擊者濫用受感染或配置錯誤的機器（服務器，路由器甚至PC機）的網絡，以向單個系統生成大量虛假流量，從而使其暫時不可用。

并且大多數托管和云提供商會向其客戶收取額外的帶寬或計算能力。如果啟用了自動擴展，則在遭受DDoS攻擊時，入口流量激增和基礎架構可能會開始快速擴展，本月Internet流量和計算資源費用不斷增加，導致更高的運營成本。

由于數據庫和系統不堪重負，未保存的工作可能不會被存儲或緩存。對于處理關鍵任務工作負載或運行某些數據一致性至關重要的在線事務處理應用程序的企業而言，這可能是一個至關重要的問題。

服務器日志將與數千個攻擊日志混在一起，因此將很難進行過濾和檢查一切是否正常。另外，你可能設置了if-then規則，并使系統自反應。在這種情況下，混雜的日志可能會對系統造成實際損害，從而給你造成很大的影響。

DDoS還可以用作服務錯亂這種攻擊技術。當管理人員忙于過濾流量時，可能會同時執行小的破壞性攻擊。這種相似的攻擊方式曾經對號稱世界上最安全的比特幣錢包Electrum進行過。

當時來自超過15萬個受感染主機的巨大DDoS攻擊被發往Electrum網絡，中斷了所有用戶的交易。同時，網絡釣魚攻擊迫使惡意消息彈出給客戶端，要求他們更新軟件。然后，人們錯誤地安裝了惡意軟件，該惡意軟件立即將所有的賬戶余額都轉向了攻擊者的錢包。

2017年時，GitLab就發生過不小心刪除了數據庫導致網站下線的事故。

Gitlab遭受了惡意郵件發送者的DDoS攻擊，導致數據庫寫入鎖定，網站出現不穩定和宕機，在阻止了惡意郵件發送者之后，運維人員開始修復數據庫不同步的問題，在修復過程中，錯誤的在生產環境上執行了數據庫目錄刪除命令，導致300GB數據被刪除，Gitlab被迫下線。

在試圖進行數據恢復時，發現只有 db1.staging的數據庫可以用于恢復，其它五種備份機制均無效。db1.staging是6小時前的數據，而且傳輸速率有限，導致恢復進程緩慢。

Gitlab第一時間在Twitter上對事件的處置狀態進行實時更新，后來索性在 Youtube上開了頻道直播恢復進程，網站恢復了正常后，gitlab還是丟掉了差不多6個小時的數據。

2018年時，GitHub也曾遭受過DDoS攻擊，峰值流量甚至達到了1.3 Tbps，在當時堪稱史上最嚴重的DDoS攻擊。GitHub受到攻擊后，服務器斷斷續續，無法訪問。攻擊發生10分鐘后，GitHub向CDN服務商Akamai請求協助，訪問GitHub的流量由后者接管。

Akamai用多種方式防御這次攻擊。除了通用DDoS防御基礎架構之外，該公司最近還針對源自memcached服務器的DDoS攻擊實施了特定的緩解措施。

網絡監測和輿情分析公司ThousandEyes表示「這次防御做的很出色，一切都在15-20分鐘內完成。如果看一下統計數據，就會發現，單獨的DDoS攻擊檢測通常都要一個小時，而這次20分鐘內搞定」。

Akamai懷疑攻擊者僅僅是因為GitHub很高端，知名度很高，所以鎖定了GitHub作為目標。而防御措施太快，持續時間相當短，可能還沒來的及要贖金，一切就結束了。

目前防御手段的發展也很快，在2020年時，AWS報告說2月檢測到2.3Tb的DDos攻擊，持續了三天，意圖癱瘓AWS，但沒有成功。

規模來看雖然達到了2018年GitHub的兩倍，但防御起來顯然比之前更輕松。

但IBM就相對比較慘了，2020年6月11日，IBM聲明稱，云業務宕機事件是由第三方網絡提供商非預期地調整IBM對外網絡路由，導致其全球流量一度嚴重受阻。聲明中還提到，整個事件持續時間是從北京時間6月10日早上5:55到早上9:30。兩個小時后該公司再次發推表示，所有的IBM云服務已重啟。

IBM宣布了這次事故歸咎于「外部網絡提供商用錯誤的路由癱瘓了IBM云網絡」。然而，Techzim從一個技術來源處收到了一份信息，該技術來源自始至終都在監視停機情況，并顯示了IBM云網絡本身發生的問題。

所以說，如果一家云公司一年沒有幾次大事故，那它就不能稱之為云巨頭。

參考資料：

https://therecord.media/gitlab-servers-are-being-exploited-in-ddos-attacks-in-excess-of-1-tbps/

本文來自微信公眾號“新智元”（ID:AI_era），編輯：LRS，36氪經授權發布。