MongoDB事件之后，再起波瀾

經(jīng)過在MongoDB各服務器間長達數(shù)日的肆虐，一群惡意分子又開始將其劫持矛頭指向ElasticSearch服務器，并要求受害者支付類似的贖金。

第一波針對ElasticSearch服務器所有者的打擊發(fā)生于1月12日，其中部分受害者通過ElasticSearch論壇反映了相關情況。

與此前曾經(jīng)出現(xiàn)的MongDB劫持活動類似，如今新一波指向ElasticSearch集群的惡意入侵再次襲來。目前全球各地的ElasticSearch集群正受到大范圍劫持，其中僅留下一條與贖金要求相關的索引定義，具體如下所示：

根據(jù)已經(jīng)報告的勒索說明，攻擊活動似乎全部源自同一黑客組織，名為P1l4tos。留言中寫明：

如果希望恢復你的數(shù)據(jù)庫，向以下錢包中發(fā)送0.2比特幣：1DAsGY4Kt1a4LCTPMH5vm5PqX32eZmot4r！在比特幣發(fā)送完成后，向p1l4t0s@sigaint.org郵箱發(fā)送你的服務器IP。

截至撰稿之時，以上列出的比特幣地址僅收到一筆贖金款項。

關于此次ElasticSearch劫持更多細節(jié)

已有超過800臺服務器遭受劫持

作為持續(xù)關注此前MongoDB攻擊活動的安全研究人員之一，Niall Merrigan已經(jīng)開始追蹤本輪ElasticSearch攻擊活動。截至本文撰稿時，Merrigan在twitter上的最新報告稱已經(jīng)有超過800臺服務器遭受劫持。

ElasticSearch是一套基于Java的搜索引擎，主要用于在各類大型Web服務及企業(yè)網(wǎng)絡當中進行信息檢索。

據(jù)稱，攻擊者利用低強度、易猜出的密碼對暴露在互聯(lián)網(wǎng)當中的各ElasticSearch服務器發(fā)起入侵。

目前，仍有約35000臺ElasticSearch服務器在線運行

根據(jù)Shodan查詢結果顯示，目前仍有約35000個ElasticSearch實例可通過互聯(lián)網(wǎng)進行接入。2015年8月，來自BinaryEdge公司的安全專家們發(fā)現(xiàn)當時在線運行的ElasticSearch實例僅為8990個，而其時個中包含的信息總量為531199 TB。

安全界早有預警

2015年12月，AlienVault通過實驗發(fā)現(xiàn)，攻擊者能夠利用兩項不同的安全漏洞對ElasticSearch服務器進行劫持，并將其添加至僵尸網(wǎng)絡當中。

MongoDB也有相同的境遇，在MongoDB事件發(fā)生前，其實業(yè)界已經(jīng)告知很多MongoDB數(shù)據(jù)庫處于令人不安的開放狀態(tài)。2015年12與，Shodan經(jīng)過調(diào)查之后發(fā)現(xiàn)當時互聯(lián)網(wǎng)上共有至少35,000個可公開訪問，無須身份驗證的MongoDB實例。（悲傷的是，一年多之后，開放式MongoDB數(shù)據(jù)庫的數(shù)量不降反增，估計共有多達99,000個數(shù)據(jù)庫有被劫持風險。）

技術反思 and“一語成讖”

隨著此前針對MongoDB服務器之攻擊活動的出現(xiàn)，業(yè)內(nèi)人士考慮其需要花費多長時間才會將惡意矛頭指向其它技術方案。

Bleeping Computer的安全觀察員Catalin Cimpanu曾經(jīng)在2017年1月9日公開表示其擔憂：

我在考慮這些MongoDB劫持者需要多長時間來發(fā)現(xiàn)其它互聯(lián)網(wǎng)可訪問目標，包括Redis、CouchDB以及ElasticSearch服務器。

問題的答案是三天。

其它可能的潛在攻擊目標還包括Apache CouchDB、Redis以及Memcached，其皆可通過互聯(lián)網(wǎng)輕松訪問且在安全水平上甚至不及MongoDB。

Elastic公司官方：正確配置，防止數(shù)據(jù)丟失

ES的劫持事件發(fā)生第二天，2017年1月13日，Elastic公司撰寫了一篇博客“保護您的數(shù)據(jù)免受勒索攻擊侵擾”。文中表示此次事件對Elastic Cloud的客戶影響甚微，其中安全產(chǎn)品X-Pack 會隨機分配彼此獨立密碼的配合。而對于其他用戶，Elastic公司不建議將ElasticSearch實例暴露在互聯(lián)網(wǎng)中；對于已有的非安全且面向互聯(lián)網(wǎng)的Elasticsearch，Elastic公司同樣給出了六條建議。

附文章地址為：https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom。

下面為全文譯文：

上周末，一輪惡意攻擊的大規(guī)模來襲導致數(shù)千臺開源數(shù)據(jù)庫中的數(shù)據(jù)遭遇復制、刪除及勒索性加密等嚴重問題。盡管上述攻擊活動中并未使用任何惡意軟件或者“勒索軟件”，且與產(chǎn)品安全漏洞并無關聯(lián)，但最終仍然造成了嚴重的數(shù)據(jù)丟失甚至數(shù)據(jù)泄露安全事故。不過好消息是，我們完全可以通過正確配置輕松防止類似攻擊行為造成的數(shù)據(jù)丟失后果。

因此，讓我們以此為鑒高度關注Elasticsearch實例的安全保護工作，特別是保護那些可通過互聯(lián)網(wǎng)加以接入的實例。

選擇使用Elastic Cloud的客戶可以放心，其使用隨機分配的彼此獨立密碼配合X-Pack安全產(chǎn)品對集群加以保護。客戶為這些集群選擇對應的AWS服務區(qū)，而集群本身亦被部署在冗余防火墻及代理之后。默認配置提供來自互聯(lián)網(wǎng)的加密TLS通信內(nèi)容，且Elastic每七天對集群數(shù)據(jù)進行一次備份。

對于其它部署選項，我們強烈建議大家確保那些可能存在安全問題的Elasticsearch實例不會直接暴露在互聯(lián)網(wǎng)當中。具體請參閱我們2013年發(fā)布的博文。我們還將相關建議以localhost內(nèi)默認安裝綁定的形式加以實施。盡管如此，面對各類互聯(lián)網(wǎng)可訪問實例，我們已經(jīng)意識到其中存在的安全隱患。

如果大家擁有一套非安全且面向互聯(lián)網(wǎng)的Elasticsearch實例，那么我們強烈建議您立即采取以下措施以保護您的數(shù)據(jù)：

更早的呼聲：不在公共網(wǎng)絡中暴露集群

在ElasticSearch服務器集群收到攻擊的當天，搜索及大數(shù)據(jù)專家Itamar Syn-Hershko便撰文

“抵抗被洗劫：妥善保護您的Elasticsearch集群”詳細支招怎樣對抗此次劫持，Itamar是以色列的獨立咨詢師，他的公司code972是Elastics公司的合作伙伴。

http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly

Itamar 強烈呼吁：

無論如何，請千萬不要讓您的集群節(jié)點暴露在網(wǎng)絡當中。雖然這聽起來像是廢話，但事實上用戶們往往并沒有切實遵循這項最佳實踐。您永遠不應將自己的集群暴露在公共網(wǎng)絡當中。

Itamar 對七條推薦實踐進行了分析，探討確保集群安全的“該”與“不該”作法。以下為其文章的翻譯：

1、啟用HTTP的節(jié)點應該僅監(jiān)聽私有IP

Elasticsearch可通過配置限定其所監(jiān)聽的IP，而大家可以控制作為其合法監(jiān)聽對象的本地主機、私有IP、公共IP或者這幾類對象的組合。在現(xiàn)實使用中，我們沒有任何理由yhElasticsearch監(jiān)聽公共IP或者可公開訪問的DNS名稱。

這項設置被稱為network.bind_host或者簡寫為network.host，而大家應始終將其設定為僅適用于私有IP（在某些例外情況下，亦可加入某些本地主機）。

讓我們再次重申：network.bind_host應當始終被設定為私有網(wǎng)絡接口，而永遠不可被設定為公共IP或者DNS。

這將影響到HTTP訪問與本地Java客戶端訪問。在某些用例中，我們可能需要實現(xiàn)某客戶端節(jié)點的公開訪問，具體解決辦法如下。

2、使用代理實現(xiàn)客戶端通信

作為一類常見誤區(qū)，人們通常表示“嘿，Elsticsearch屬于REST over HTTP，我們直接通過智能HTML客戶端進行訪問即可。”事實上，這種作法極不可取。

如果大家的單頁面應用需要查詢Elastic并獲取JSON作為顯示內(nèi)容，那么將通過具備過濾、審計記錄以及最重要的數(shù)據(jù)密碼保護功能的軟件代理加以實現(xiàn)。

如果不這樣做，那么我們很可能面臨以下三種后果：（1）您將其明確綁定至某公共IP，這種作法非常危險; （2）導致數(shù)據(jù)面臨意外修改的風險; （3）最糟糕的是，您無法控制誰在對哪些數(shù)據(jù)進行訪問，而且全部數(shù)據(jù)皆可供外部查看。而本次出現(xiàn)的Elasticsearch集群劫持事件正是引發(fā)了這種情況。

另外，也不要暴露您的文件與索引結構，亦不可對您的瘦客戶端同為其提供數(shù)據(jù)的數(shù)據(jù)存儲系統(tǒng)進行耦合。您的客戶端JavaScript絕對不應與Elastic DSL直接通信。

您的客戶端應該與服務器端軟件進行通信，并由后者將全部客戶端請求轉發(fā)至Elasticsearch DSL、執(zhí)行查詢、而后有選擇地將來自Elasticsearch的響應結果返回至客戶端。另外，在對Elasticsearch進行任何訪問之前，您的服務器端應用顯然應驗證用戶登錄憑證，從而確保其身份及授權符合操作數(shù)據(jù)的相關要求。如若不然，您的集群很可能陷入風險，并直接導致數(shù)據(jù)為貪婪的攻擊者所獲取。

3、如果可能，將Elasticsearch運行在隔離網(wǎng)絡當中

即使是在您的內(nèi)部網(wǎng)絡中，也請盡可能將集群隔離于其它系統(tǒng)部分之外。舉例來說，一部分客戶會將其集群部署在AWS之上，我建議大家將此類集群運行在VPC中，而后再為其設置兩個獨立安全組——其一面向整體集群，其二面向其中單一客戶端節(jié)點，且該節(jié)點僅與要求訪問集群的應用進行共享。

4、不要使用默認端口

再有，請不要使用默認端口——算是我有些多疑吧，但小心一點總是沒錯的。

默認端口的變更方式非常簡單，感興趣的朋友可以點擊此處查看設置過程（英文原文）。

5、在不需要時禁用HTTP

Elasticsearch最好是被部署在服務器組當中，其中每臺服務器充當單一角色——例如主節(jié)點、數(shù)據(jù)節(jié)點以及客戶端節(jié)點。感興趣的朋友可以點擊此處查看官方說明文檔中的相關內(nèi)容（英文原文）。

請確保只在您的客戶端節(jié)點上啟用HTTP，且僅允許您的應用（來自私有網(wǎng)絡之內(nèi)）對其加以訪問。在客戶端節(jié)點上啟用HTTP亦適用于全部集群通信皆立足 TCP端口（默認為9300）完成的JVM類系統(tǒng)，這是因為：（1）大家仍然需要開放HTTP端點以實現(xiàn)調(diào)試與維護; （2）長期運行的Java客戶端也將遷移至HTTP。

感興趣的朋友可以點擊此處了解如何輕松禁用HTTP（英文原文）。

6、保護公共可用的客戶端節(jié)點

在某些情況下，客戶端節(jié)點需要公共可用以支持Kibana及Kopf等UI。雖然我仍然建議大家將這些節(jié)點部署在私有網(wǎng)絡之后并僅允許通過VPN進行連接，但有時候VPN確實不易設置，而最方便快捷的作法無法是將Kibana實例直接部署在公開節(jié)點之上——這會同時導致整套集群暴露在互聯(lián)網(wǎng)當中。

如果大家能夠利用VPN保護自己的客戶端Kibana、Kopf及其它節(jié)點（即借此將其僅綁定至私有IP），那么請務必采取這種方法。

如若不然，大家可以通過引入代理的方式實現(xiàn)保護。作為起點，大家可以點擊此處了解如何利用簡單的示例nginx配置文件建立密碼保護代理以掩護您的客戶端節(jié)點。此示例中包含Kibana、Kopf（靜態(tài)）與實際Elasticsearch訪問。

大家也可以利用Elastic的Shield或者SearchGuard等插件保護自己的集群并控制一切經(jīng)由客戶端節(jié)點的訪問活動。

如果大家不得不選擇通過公共網(wǎng)絡訪問節(jié)點，請確保利用HTTPS對其進行保護，同時禁止一切以明文方式傳輸數(shù)據(jù)及憑證的作法。再次強調(diào)，Shield與SearchGuard等nginx與Elasticsearch插件能夠幫助大家輕松實現(xiàn)這一效果。

7、禁用腳本（2.x之前版本）

在Elasticsearch 2.x之前的版本中，其由于啟用了多種非沙箱語言（mvel、groovy）的動態(tài)腳本功能而存在安全隱患。如果大家使用的集群部署有1.x或者0.x版本，請盡快進行升級?；蛘?，至少應當禁用其動態(tài)腳本功能。

如果大家使用Elasticsearch 2.x版本，則應變更您的默認腳本語言并移除groovy（此語言不支持沙箱功能，且為默認語言）。

我個人發(fā)現(xiàn)，很多集群都是由通過Search API向Elasticsearch發(fā)送惡意腳本的方式遭遇入侵的。

在Itamar看來：Elasticsearch目前已經(jīng)被廣泛應用于從日志記錄到搜索在內(nèi)的各類敏感文件用例當中。無論如何，存儲在Elasticsearch上的數(shù)據(jù)實際上相當安全，即很難被惡意人士所竊取。

正因為如此，大家不應自尋煩惱。請確保您的集群深深隱藏在私有網(wǎng)絡當中，且僅接受來自您自有應用的訪問。

禁用各類您不需要的功能，且盡可能隱藏您的設置（例如默認端口）、您的數(shù)據(jù)結構甚至是您正在使用Elasticsearch這一事實。

最后，我將繼續(xù)密切關注這場安全危機的發(fā)展情況，并根據(jù)事態(tài)隨時為大家?guī)砀嘈孪ⅰ?/p>

如果還有問題，還有大神可以求助嗎？

除了Elastic公司和安全專家Itamar給開出的普適良方，如果你還有問題怎么辦呢？

或許可以求助一位行俠仗義的Hacker， Victor Gevers堪稱一位Hacker道德模范，從1998年起，他負責捉住了5211個安全漏洞。他所在的GDI Foundation公司是一個非盈利組織，公司的使命是讓免費公開的互聯(lián)網(wǎng)更安全，這家不足十人的荷蘭公司致力于發(fā)掘安全漏洞。

在此前對MongoDB的文章報道中，高效開發(fā)運維公眾號的一位技術粉絲bill0 Ng強烈建議對“黑客”和“駭客”兩次進行區(qū)分并稱，

黑客hacker：具有開拓者精神的人，勇于實踐；

駭客cracker：搞破壞的人。

兩類任共性是技術高超，但是出發(fā)點是不同的。上面所說的 Victor和他的同事們當屬正義的Hacker。而發(fā)來勒索信息的P1l4tos自然就是擾得人心惶惶的駭客。

參考資料列表：

Catalin Cimpanu

MongoDB劫持者轉移至ElasticSearch服務器

https://www.bleepingcomputer.com/news/security/mongodb-hijackers-move-on-to-elasticsearch-servers/

Mike Paquette

保護您的數(shù)據(jù)免受勒索攻擊侵擾

https://www.elastic.co/blog/protecting-against-attacks-that-hold-your-data-for-ransom

Itamar Syn-Hershko

抵抗被洗劫：妥善保護您的Elasticsearch集群

http://code972.com/blog/2017/01/107-dont-be-ransacked-securing-your-elasticsearch-cluster-properly