[新聞日本旅遊業巨頭JTB793萬條用戶數據洩露

【IT168 評論】一封看似合理的電子郵件引發了2016年6月份最大的安全事件-日本旅遊業巨頭JTB793萬條用戶數據洩露，此次事件，自JTB2016年6月15日宣布被未知黑客入侵以來持續發酵，相關報不絕於耳。綜合各方面的信息材料，基本可以還原出整個JTB被入侵的全過程。

　　根據日經新聞報導，此次入侵事件存在以下幾個關鍵時間節點：
　　3月15日JTB員工打開釣魚電子郵件，辦公電腦被黑客植入木馬
　　3月20日第三方安全企業發現異常流量，但未引起JTB特別關注
　　3月21日黑客開始抽取數據庫中的核心信息
　　3月25日黑客把數據庫信息向外傳輸完畢
　　4月01日發現黑客盜取數據留下的痕跡
　　6月10日JTB確認此次黑客入侵損失
日本旅遊業巨頭JTB793萬條用戶數據洩露
　　根據對該病毒程序的樣本分析，可以重演黑客如何利用感染的商品信息控制服務器對“實用數據庫”進行攻擊，獲取數據。下圖描述了plugx在入侵pc機，感染內網多台服務器後,如何從數據庫中盜取核心數據。
日本旅遊業巨頭JTB793萬條用戶數據洩露
　　1：商品信息控制服務器被黑客的木馬通過內網感染，#FormatImgID_3#木馬將自己設置成名為QUEST software TOAD的進程。該木馬會調用fmtoptions程序和相應的組件(通過替換dll文件植入惡意程序)，被攻擊的#FormatImgID_4#fmtoptions程序建立了80端口的http服務。
　　2：海外的C&C(通訊與命令)服務器，通過該服務器上開放的http協議與被感染的fmtoptions程序進行通訊，發送經過壓縮加密的命令到商品信息控制器。由於商品信息控制器被數據庫服務器所信任。從而登錄“實用數據庫”，對數據庫進行批量導出或混淆式導出。
　　3：導出的數據集被fmtoptions程序保存為CSV文件，通過web集群向未知的服務器發送數據。CSV使用後，會立即刪除，隱藏黑客入侵的痕跡。
　　RAT(遠程訪問木馬)的新特徵：
　　RAT(remote access Trojan)是一種常見的攻擊手段，入侵者可通過此類攻擊達到竊取核心數據的目的，此次事件正是一次典型的RAT攻擊。
　　對比以往的RAT攻擊，此次安全事件暴露出新版本和以往不同的特點，而這些新特點也給我們帶來了新的安全挑戰。
　　特點一：目標明確，洞悉內網環境
　　此次JTB遭遇黑客從入侵到結束，總共用時11天。這說明黑客對JTB及其子公司內網部署結構和安全措施有相當深入的了解。並不像常見RAT那樣採取被動的隱藏的方式通過長期的潛伏緩慢獲取數據。而是採用了一種主動的方式(可能是fire hosed方式)，快速獲取目標數據，並通過多台JTB機器向黑客控制服務器傳送被盜數據信息。
　　特點二：黑客工具針對性強
　　根據JTB的公開說明，此次被植入的惡意後門是plugx。這是一款從2012年就被廣泛使用的惡意後門。根據Sophos實驗室首席研究員Szappi報告指出有一個變種的plugx從2013年開始就專門針對日本地區。這個變種的一個顯著特點就是使用了大量僅在日本本地流行的軟件漏洞。例如：Plugx原本用於本地系統提權的漏洞是利用了Microsoft Word存在的漏洞，但這個變種則是使用了日本人廣泛使用的太一朗文字存儲器存在的漏洞。
　　我們有理由相信，Sophos實驗室提到的這個plugx變種很可能正是JTB遭到的惡意後門。這也揭示出了現在RAT攻擊採取的技術會更加專業化，不再面向通用軟件。而是根據當地的特色，甚至目標企業的特色制定專門適合當地的入侵軟件。
　　特點三：數據獲取手段隱蔽
　　此次黑客獲取數據庫中數據採用了可信工具直接訪問數據庫提取出關鍵數據的間接方式。並沒有在數據庫服務器上安裝後門程序。這種通過可信機制獲取數據庫信任得到數據的方式。既隱蔽了自己的行踪​​，又分散了數據的流量給數據洩露的追查工作也帶來了更大的挑戰。
　　暴露的安全問題以及解決方案：
　　回顧整個事件發現黑客的攻擊手法和強度都有不小的提升。整個事件僅11天黑客就完成了盜取數據庫數據的過程，而JTB則花費了90多天才確定此次黑客盜取的信息。我們在惋惜JTB的不幸遭遇和驚嘆於黑客技術升級迅速的同時。更為重要的是通過此次JTB暴露的安全問題，我們可以從中吸取什麼教訓，來避免類似事件在我們自己身上發生。
　　通過此次事件暴露出數據安全面臨的3類典型安全隱患。
　　一、缺乏對核心數據的專業保護能力
　　二、內網安全管控能力不強
　　三、企業安全意識薄弱
　　一、缺乏對核心數據的專業保護能力
　　核心數據對於企業的價值越來越重要。核心數據往往被存放在數據庫服務器中。因此數據庫服務器的防護能力必須加強。數據庫的防護的關鍵可以分為四個核心部分
　　1.數據的風險感知，及時發現異常行為
　　數據庫面臨的風險來自方方面面，感知風險是面對風險的關鍵的一步;如果在黑客開始攻擊數據庫的第一時間就感知到異常，完全可以立即發出警告並找到準確的攻擊來源，採取措施。JTB在數據庫服務器和應用之間缺乏一種對sql語句行為判斷的有效過濾工具(數據庫防火牆 )，對訪問數據庫信息的語句沒有管控能力，導致黑客在取得可信Ip和數據庫用戶信息後，能夠利用數據導出工具對數據進行肆意獲取。
　　數據庫防火牆可以提供一種有效的感知風險的方式。通過對應用系統和數據庫之間的數據訪問行為進行學習，而形成應用和數據庫之間的語法結構模型(應用的行為模型)。最終只允許嚴格符合模型中語法的sql語句從數據庫中獲取信息。一旦發現有不符合原語法模型的新型SQL產生，很可能標誌著應用系統遭到了跨站劫持、惡意代碼或註入攻擊等。對於新型的sql語句進行警告並控制，並記錄下該行為的來源(IP地址和程序名稱fmtoptions)，作為審查的線索，從而在第一時間發現異常行為，感知風險，進行響應。
　　2.細粒度訪問控制，對非常規請求進行限制
　　數據庫防火牆不但可以對異常語句在入侵到數據庫前及時作出分辨。還可以通過細粒度的訪問控制有效的約束對數據庫的訪問行為，並且對符合規範的請求語句，在結果集上作出限制。JTB這個事件中雖然無法直接證明，但黑客獲取數據庫數據很可能是通過數據庫信任的數據分析採集系統進行的。雖然請求語句是可信的，但如果黑客一次導出大量的結果集。數據庫防火牆則會根據結果集行數限制的規則對操作進行阻斷或攔截並提醒相關人員數據庫中有異常流量。及時的阻斷和攔截將有助於減小數據庫外洩信息的條數，減小企業損失。
　　3.數據操作審計，實現安全追責和損失收集
　　JTB的數據庫同時缺乏數據庫審計工具。數據庫審計工具多采用旁路的部署方式，對數據庫性能毫無影響。可以審計到數據庫上所有的流量。不怕黑客進入數據庫後刪除日誌文件。數據庫審計工具會清楚的顯示出所有對數據庫的請求和數據庫的回复。一旦出現類似JTB的數據庫數據洩露事件。可以在第一時間調取數據庫審計產品，確認黑客到底拿走了什麼數據。不需要花費將近3個月的時間去恢復CSV文件才能確定黑客給企業造成的損失。更重要的是不會造成消費者的恐慌心理。減小整個數據庫洩露事件對企業的負面影響。並給安全機關提供有效的追查方向。
　　4.核心敏感數據實施必要的加密
　　JTB在存儲數據的時候也犯了一個錯誤。不應該把核心信息存儲成明文，而應該存儲成密文，且採用基於上下文語境的強制訪問控制來保護核心數據。在最壞的時候也能保障用戶的核心信息不外洩。黑客即便拿到核心數據。但都是密文，同樣也無法利用。
日本旅遊業巨頭JTB793萬條用戶數據洩露
　　二、內網安全管控能力不強
　　企業對於外網的防護往往是不遺餘力的，而對內網的檢測和管控則或多或少都存在一些漏洞。Plugx在入侵了內網的一台PC機後會，利用這台PC機作為跳板在整個內網中傳輸含有plugx的木馬程序。感染整個內網環境。如果採取更完善的內網環境的隔離和動態檢測。相信不會這麼大面積的感染內網環境中的機器，致使企業的賬號密碼都被plugx通過鍵盤記錄器收集。以至於最後核心數據庫被盜取。
　　三、企業安全意識薄弱
　　企業安全意識不強主要表現在兩個方面上：1.從體制上，企業缺乏專業的安全團隊保障整個企業的網絡、業務、應用及系統安全。由於體制上的缺乏，導致了黑客入侵難以被發現。被發現也不會及時重視。一再貽誤戰機，最終導致793W數據外洩。2.企業缺乏相關安全意識培訓，致使員工安全意識薄弱。員工缺乏分辨釣魚郵件的能力。回复郵件出現異常也未引起察覺。管理層也對安全威脅重視程度不足。早在19號第三方安全企業已經發出安全警告。管理團隊僅採用對web服務器進行隔離、添加黑名單等治標不治本的手法。而沒有在第一時間發現攻擊的根源，導致本來可以減小的損失，並沒有減小。
　　反思與總結：
　　對比JTB的三大失誤和此次黑客入侵工具的三大特點不難看出。企業和黑客之間的戰爭正在悄然無息的全面升級。黑客越來越專業化，甚至根據不同的目標進行工具的優化。在整個企業安全的長城上尋找一絲一毫的切入口。任何一個缺陷最後都可能成為整個數據洩露的罪魁禍首。同樣對於企業來說，隨著互聯網產業的發展，隨著大量業務的互聯網化。來自網絡的威脅將逐漸成為未來企業將面對的最大威脅。如何解決好來自網絡的威脅將成為困擾廣大企業用戶的長期問題。
企業要想最終贏得這場與黑客之間的戰爭必須克服JTB犯的2大問題：一個是人的安全意識的問題、另外一個是核心數據的風險感知和安全防護的問題。不提高工作者、管理者、消費者的安全意識，安全永遠是句空話。安全符合木桶原理，決定安全度的永遠不是最長的板，而是最短的板。太多企業很注重自己的外網安全。但對內網安全特別是數據安全則重視程度並不足夠。其實這是一種本末倒置的想法，黑客入侵企業網絡，最希望的訴求就是獲取數據庫中的核心數據。當黑客進到內網遇到幾乎“裸奔”的數據庫服務器，興奮程度可想而知。試想如果JTB在數據庫前有數據庫防火牆，數據庫中的數據庫恐怕沒有這麼容易被盜取;同樣如果有針對數據庫的審計產品相信JTB也不會為了弄清楚黑客從數據庫中拿了什麼，而花費近3個月的時間。
給客戶帶來恐慌，給企業帶來信任危機。哪怕JTB用數據庫加密產品對數據庫中關鍵字段加密，不是明文存放，至少保證客戶信息在一段事件內的安全。期間通知客戶進行修補，也能最大限度的避免損失。但可惜的是JTB對數據庫什麼都沒做，於是黑客毫不費力的拿到了793W條核心數據。
　　你的企業想成為下一個JTB嗎?不想就請給你的數據庫加上安全防護吧，它遠沒你想的安全。