信息來源：FreeBuf

許多人沒有想到，去年12月一件不起眼的小事，在新年伊始卻演變成了一場屠殺。如今，受害的一方似乎正由于自身的疏忽和遲鈍而顯得愈發(fā)無力反抗，一個(gè)接一個(gè)倒下。

截止本周三（1月11日），已經(jīng)有20名以上的黑客加入到這場對(duì)MongoDB用戶一邊倒的碾壓中來，遭到入侵、勒索的數(shù)據(jù)庫超過了33，000個(gè)，并且這一數(shù)字還在不斷上升中。（源自凱捷咨詢的Niall Merrigan提供的數(shù)據(jù)）MongoDB是目前包括eBay，紐約時(shí)報(bào)，LinkedIn在內(nèi)的全世界多家公司廣泛采用的數(shù)據(jù)庫。

源于0.2比特幣的勒索

去年12月27日，安全專家兼GDI Foundation聯(lián)合創(chuàng)始人Victor Gevers（@0xDUDE）在Twitter上稱由于存在配置漏洞，可不通過任何認(rèn)證直接訪問某些MongoDB數(shù)據(jù)庫，而黑客早已盯上了這些目標(biāo)。當(dāng)時(shí)，第一波被黑的MongoDB數(shù)據(jù)庫中，Gevers觀察到數(shù)據(jù)內(nèi)容被清空，黑客還留下了一條“WARNING”信息：

“SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !”

意思就是：要求支付0.2比特幣到指定地址用以還原數(shù)據(jù)。署名“Harak1r1”的黑客（或組織）大肆入侵了MongoDB數(shù)據(jù)庫，清空里面的內(nèi)容并向擁有者索要0.2比特幣（約$211）的贖金，否則數(shù)據(jù)將不予歸還。Gevers發(fā)現(xiàn)了這次攻擊并隨即在Twitter上警告了MongoDB數(shù)據(jù)庫用戶。遺憾的是，這份警告并沒有引起MongoDB使用者足夠的重視。而嗅覺敏銳的黑客們卻迅速地圍了上來，盛宴開始。

MongoDB屠戮全面開啟

當(dāng)時(shí)Gevers暫時(shí)只統(tǒng)計(jì)到了有近200個(gè)MongoDB數(shù)據(jù)庫實(shí)例（instance）被黑客入侵當(dāng)做勒索籌碼。FreeBuf安全快訊對(duì)此進(jìn)行了追蹤報(bào)道，在1月3日，這個(gè)數(shù)字達(dá)到了2，000以上。接下來的日子里，攻擊規(guī)模不斷擴(kuò)大，受害者數(shù)量急劇上升。僅在1月9日早間開始的12小時(shí)內(nèi)，受到黑客勒索的數(shù)據(jù)庫就從12，000個(gè)翻倍達(dá)到了27，633之多。

參與其中的黑客數(shù)量也增加到至少15人以上，其中一位名為“kraken0”的黑客已經(jīng)入侵了15，482個(gè)MongoDB數(shù)據(jù)庫并向每位受害者索取了1比特幣（約$921）贖金。盡管安全專家已經(jīng)告誡眾多MongoDB數(shù)據(jù)庫用戶不要向黑客支付贖金（很多黑客并不會(huì)如宣稱的那樣保留了數(shù)據(jù)，多數(shù)情況是直接刪掉了），但已知仍有至少22個(gè)受害機(jī)構(gòu)或個(gè)人繳納了贖金。

之所以會(huì)有如此眾多的數(shù)據(jù)庫實(shí)例被這次沖擊迅速收割，主要是因?yàn)楹芏嗍褂谜邲]有遵照生產(chǎn)環(huán)境部署手冊，缺少安全認(rèn)證，直接將服務(wù)器暴露在公網(wǎng)里以及版本過于老舊。對(duì)于攻擊者而言，使用在線工具就可以較輕松地發(fā)現(xiàn)存在問題的數(shù)據(jù)庫。事實(shí)上，黑客還發(fā)掘到了另一個(gè)商機(jī)：他們有人開始販賣用來攻陷數(shù)據(jù)庫的軟件賺錢。這種工具被稱作“Kraken Mongodb ransomware”，只要價(jià)值$200的比特幣就可以買到該程序的C#源碼。

產(chǎn)生如此后果的另一個(gè)重要原因是部分使用者安全意識(shí)淡薄，反應(yīng)遲鈍。作為最初發(fā)現(xiàn)者的Gevers就曾對(duì)SecurityWeek這樣吐槽：

“永遠(yuǎn)不要低估某些公司的反應(yīng)有多么愚蠢，有些只是移除了勒索信息，還原了數(shù)據(jù)，卻依舊讓服務(wù)器門戶大開。”

Gevers有所怨言是不無道理的。作為安全專家，他長時(shí)間致力于數(shù)據(jù)庫漏洞探測并會(huì)向企業(yè)提供風(fēng)險(xiǎn)報(bào)告。然而，他的預(yù)警卻被許多公司視而不見，僅在去年一年就有138份相關(guān)報(bào)告石沉大海。即使他對(duì)這波攻擊迅速做出了告警，卻依然收效甚微。

安全組織“ShadowServer”通過AISI（Australian Internet Security Initiative）每天約提供400個(gè)MongoDB數(shù)據(jù)泄漏預(yù)警，服務(wù)澳洲90%的網(wǎng)絡(luò)提供商

暗潮涌動(dòng)

輕視安全問題是要付出代價(jià)的。事實(shí)上MongoDB數(shù)據(jù)庫泄漏問題早在2015年就被報(bào)導(dǎo)過。當(dāng)時(shí)Shodan（搜索引擎）的負(fù)責(zé)人John Matherly統(tǒng)計(jì)到有30，000個(gè)以上的MongoDB數(shù)據(jù)庫實(shí)例，近600TB的數(shù)據(jù)暴露于公網(wǎng)之上，無需任何認(rèn)證就可訪問。很多版本滯后的數(shù)據(jù)庫配置文件里沒有做IP捆綁（bind_ip 127.0.0.1），在用戶不甚了解的時(shí)候留下了安全隱患。雖然MongoDB的開發(fā)團(tuán)隊(duì)在下一個(gè)版本里修復(fù)了這個(gè)問題，但截止事發(fā)，仍然有數(shù)量眾多的數(shù)據(jù)庫管理者沒來得及更新。

這次勒索事件的一個(gè)顯著后果就是世界范圍內(nèi)存儲(chǔ)在MongoDB數(shù)據(jù)庫里數(shù)據(jù)量的大幅下滑。據(jù)Merrigan提供的信息顯示，在短短3天內(nèi)就有114.5TB的數(shù)據(jù)因此消失。據(jù)估計(jì)，目前網(wǎng)上約有50，000個(gè)開放訪問的MongoDB數(shù)據(jù)庫，也許用不了多久所有沒做好安全措施的數(shù)據(jù)庫都會(huì)被黑客攻陷。這個(gè)過程需要多久？據(jù)Gevers估算，這個(gè)過程可能用不了幾周。

毫無疑問，黑客們的瘋狂給人們敲響了警鐘。現(xiàn)在應(yīng)該會(huì)有很多人后悔了。

現(xiàn)在補(bǔ)救還來得及

Gevers確認(rèn)，目前已有來自包括IP，醫(yī)療，金融服務(wù)，旅游等行業(yè)在內(nèi)的多家公司就此次攻擊事件求助，但他不愿意透露求助企業(yè)的名稱。他建議：有時(shí)一個(gè)數(shù)據(jù)庫會(huì)被不同的黑客攻擊多次，受害者很有可能把贖金給錯(cuò)了人，這更是一個(gè)無底洞。因此不僅不要支付贖金，更要想辦法讓攻擊者證明丟失的數(shù)據(jù)是否還真實(shí)存在。Gevers表示，如果有適當(dāng)?shù)木W(wǎng)絡(luò)監(jiān)控程序，可以判斷丟失的數(shù)據(jù)是被轉(zhuǎn)移了還是被直接刪掉了。不過這樣做需要把出站的數(shù)據(jù)流量同系統(tǒng)日志里的訪問記錄做多方面比較才行。

MongoDB官方建議如下：

如何知道自己有沒有受到攻擊：

1. 如果已經(jīng)為數(shù)據(jù)庫正確配置了訪問控制，攻擊者應(yīng)該訪問不到數(shù)據(jù)，可參考安全手冊（https://docs.mongodb.com/manual/security/）

2. 驗(yàn)證數(shù)據(jù)庫和集合。在最近的案例中，攻擊者丟棄了數(shù)據(jù)庫和/或集合，并用一個(gè)ransom需求的新的替換它們。

3. 如果啟用訪問控制，請審核系統(tǒng)日志以進(jìn)行未經(jīng)授權(quán)的訪問嘗試或可疑活動(dòng)。

如果已經(jīng)受到攻擊：

1. 如果您是MongoDB企業(yè)支持客戶，請盡快提交P1訂單，我們的技術(shù)服務(wù)工程師可以指導(dǎo)您完成以下過程。

2. 您的首要任務(wù)是保護(hù)您的集群以防止進(jìn)一步的未授權(quán)訪問。您可以參照我們的安全實(shí)踐文檔。

3. 通過運(yùn)行 usersInfo 來檢查是否有添加，刪除或修改的用戶。

4. 檢查日志以查找攻擊的時(shí)間。檢查是否有刪庫或者刪表，修改用戶或創(chuàng)建贖金記錄的命令。

5. 如果你有定期對(duì)受損數(shù)據(jù)庫進(jìn)行備份，則可以還原最近的備份。您需要評(píng)估最近的備份和攻擊時(shí)間之間可能已更改的數(shù)據(jù)量。如果您使用Ops Manager或Cloud Manager進(jìn)行備份，則可以恢復(fù)到攻擊之前的時(shí)間點(diǎn)。

6. 如果您沒有備份或以其他方式無法還原數(shù)據(jù)，那么您的數(shù)據(jù)可能會(huì)永久丟失。

7. 您應(yīng)該假設(shè)攻擊者已經(jīng)復(fù)制了受影響的數(shù)據(jù)庫的所有數(shù)據(jù)。請按照內(nèi)部安全流程對(duì)數(shù)據(jù)泄露事件進(jìn)行恰當(dāng)處理。

8. 最后，請參閱我們的安全最佳做法和資源，以便將來保護(hù)您的數(shù)據(jù)。

如何防范此類攻擊？

1. 做好訪問認(rèn)證。打開你的MongoDB配置文件（.conf），設(shè)置為auth=true

2. 做好防火墻設(shè)置。建議管理者關(guān)閉27017端口的訪問。

3. Bind_ip，綁定內(nèi)網(wǎng)IP訪問。

4. 做好升級(jí)。請管理者務(wù)必將軟件升級(jí)到最新版本。