此事件是去年應急處置時完成的報告,距今有半年時間了。一直存在電腦裏,最近準備完善應急響應中遇到的各種安全事件,這篇文章做爲這一系列的開端。python
對於 Linux 安全檢查,我的上段時間寫了個 shell 用於一鍵進行 Linux 安全檢查,本文對 Linux 的檢查使用相關腳本都可實現,相關連接以下:linux
2018 年 11 月 8 日,我司「捕影」應急響應小組接到駐場團隊反饋,某用戶 OA 被 360 瀏覽器提示「網站存在數字貨幣挖礦行爲」,我司應急響應小組進行分析後確認爲真實事件,隨後進行黑客入侵分析。web
通過分析,判斷這次事件爲黑客惡意攻擊所致,通過安徽三實「捕影」應急響應小組的分析,目前獲得如下結論:算法
1. 此 OA 爲某用戶老的 OA,由於須要使用其數據才臨時啓用。shell
2. 此服務器對應內部 IP 爲 10.134.1.76,目前對互聯網僅開放其 6001 端口,22 端口只能經過內部訪問;目前僅對互聯網開放 6001 端口。數據庫
3. 系統帳號正常瀏覽器
4. 網絡鏈接狀況正常安全
5. 開放端口過多,建議禁用非業務端口
6. 定時任務發現歷史 (2018 年 10 月 29 日至 2018 年 11 月 8 日) 曾定時下載挖礦程序
7. 歷史命令分析歷史曾下載挖礦程序
8. 啓動項正常
9. 系統層面未發現病毒、木馬、後門
10. 由於其 OA 日誌僅保存 2018 年 11 月 13 日至 2018 年 11 月 14 日,黑客植入挖礦程序在 2018 年 11 月 8 號及之前,無相關日誌,沒法分析黑客入侵的途徑。
11. 目前追溯到 2018 年 10 月 29 日已被植入挖礦程序;2018 年 11 月 8 日或更早被植入 JS 代碼進行挖礦
12. 未保存黑客攻擊時 web 應用的相關日誌,沒法經過日誌分析黑客入侵的方式,可是 webgloic 相關版本存在較多高危漏洞,推測利用 weblogic 漏洞入侵的可能性較大。
下面將針對這次應急處置的過程作大體的闡述。
2018 年 11 月 8 日,我司「捕影」應急響應小組接到駐場團隊反饋,某用戶 OA 被 360 瀏覽器提示「網站存在數字貨幣挖礦行爲」,具體狀況以下所示:
圖 1-360 瀏覽器提示 OA 系統「網站存在數字貨幣挖礦行爲」
360 瀏覽器提示「網站存在數字貨幣挖礦行爲」, 說明可能存在相關行爲。我司應急響應人員對其網站源碼分析,發現頁面有多處加載 JS 的行爲,經過對加載的 JS 逐一分析,發現有一處 JS 有可疑。
圖 2-OA 加載 JS 腳本
對這一 JS 腳本進行分析,發現該腳本的確被植入 JS 挖礦腳本,具體以下:
圖 3-OA 加載挖礦腳本
圖 4-挖礦 JS 代碼功能
圖 5-挖礦 JS 源碼
圖 6-挖礦網站
圖 7-LoginID 細節
能夠看到,這裏面的 ID31f7dd372f1545eeb6db379490b0e3c5 爲 LoginID, 而非 XMR 的地址,經過將 XMR 地址經過相應的算法轉換爲 LoginID, 避免了查找真實的 XMR 地址,起到了保護隱私的目的。
經過上面的分析,能夠看到該 JS 的大概功能以下:
礦池地址 | wss://xmr.omine.org:8181 |
---|---|
挖礦方式 | 網頁挖礦 (JS 挖礦) 正經常使用戶訪問被植入 JS 的網站 (OA 系統),正經常使用戶的瀏覽器都會自動爲攻擊者挖礦。挖礦使用 CPU 挖礦,瀏覽器會佔用全部的 CPU 資源。 |
植入的 JS | https://xmr.omine.org/assets/v7.js |
XMR 地址 | 沒法查到,攻擊者將 XMR 地址使用算法轉換爲 LoginID,從而避免查找其 XMR 地址以及相關的挖到數字貨幣的相關數據。 LoginID: 31f7dd372f1545eeb6db379490b0e3c5 |
挖礦 JS 被植入時間 | 2018 年 11 月 8 日或更早 |
挖數字貨幣類型 | XMR 門羅幣, 一種全匿名的數字貨幣。其特色在於交易過程全匿名,沒法追蹤。 |
服務器被植入挖礦腳本說明服務器確定被黑客入侵了,因爲目前 OA 系統服務器僅 6001 端口對互聯網開放,所以經過 web 應用入侵的可能性比較大。另外,黑客入侵之後可能會對系統及應用進行操做,如添加帳號、開放端口、增長定時任務、自啓動程序、植入 webshell、後門等,所以須要對系統對 web 應用進行全面分析,以發現黑客可能進行的惡意操做行爲。
2.3.1 開放端口分析
對 OA 服務器的開放端口, 發現其開放如下端口。
圖-8-開放端口
序號 | 開放端口 | 應用 | 建議 |
---|---|---|---|
1 | 21 | vsftpd | 建議只對內網開放,而且訪問須要通過堡壘機。 |
2 | 22 | SSH | 建議只對內網開放,而且訪問須要通過堡壘機。 |
3 | 111 | portmap | 建議分析,並決定是否須要關閉 |
4 | 631 | cupsd | 建議分析,並決定是否須要關閉 |
5 | 925 | rpc.statd | 建議分析,並決定是否須要關閉 |
6 | 2207 | python | 建議重點分析,並決定是否須要關閉 |
7 | 2208 | hpiod | 建議分析,並決定是否須要關閉 |
8 | 6001 | OA 應用端口 | 建議通過 WAF 防禦 |
結論:經過以上分析,能夠看出該臺服務器開放較多非業務端口,建議根據實際狀況進行決定是否須要開放。
2.3.2 網絡鏈接分析
經過分析 OA 服務器,目前只發現有如下鏈接。
圖 9-網絡鏈接狀況
相關鏈接做用主要以下:
序號 | 鏈接 | 說明 |
---|---|---|
1 | 10.134.1.76:*->10.134.1.74:1521 | 和 Oracle 數據庫交互,其爲用戶訪問 OA 時調用後臺數據庫 |
2 | 10.134.1.76:22<-10.134.8.222 | 內部運維訪問該服務器 |
3 | 10.134.1.76:6001<-220.178.108.2 | 用戶經過互聯網訪問 OA |
結論:經過上面的分析,能夠看出網絡鏈接層面正常。
2.3.3 帳號分析
2.3.3.1 root 權限用戶
目前僅有 root 一個用戶具備 root 權限。
圖 10-root 權限用戶
2.3.3.2 可登陸用戶
OA 服務器有三個用戶可使用 SSH 方式進行登陸:root、ahsx、suncn
圖 11-可登陸用戶
經過/etc/shadow 文件分析,也僅 root、ahsx 和 suncn 三個帳號能夠登陸。
圖 12-可登陸用戶
結論:經過上面的分析,能夠看出帳號層面正常。
2.3.4 定時任務分析
經過分析,系統未見定時任務。
圖 13-定時任務
可是對/var/log/cron*日誌分析,發現存在 5 個相關的日誌。
圖 14-定時任務日誌
對日誌內容進行分析,發現 10 月 29 日 0 點 08 分 01 秒使用 root 帳號下載一個 sh 文件。
圖 15-日誌分析
該定時任務一直到 2018 年 11 月 8 日 17:49:01 秒才結束。
圖 16-定時日誌分析
2.3.4.1 mr.sh 腳本分析
對 mr.sh 腳本進行分析,發現 mr.sh 腳本功能很是強大。大概功能以下:
1. 殺掉部分進程、網絡鏈接
2. 更改主機的 iptables,拒絕部分主機訪問
3. 自動下載其餘惡意腳本、文件, 並執行
4. 將惡意腳本加入到自啓動中
5. 刪除安裝後的惡意腳本與臨時文件
圖 17-mr.sh 腳本內容
2.3.4.2 wc.conf 分析
wc.conf 該文件主要爲挖礦的配置文件,裏面包括礦池地址、礦工名以及挖礦的相關配置。
圖 18-wc.conf 分析
經過以上的分析,能夠看到,黑客在 2018 年 10 月 29 日 0 點 08 分 01 秒前已經入侵該臺服務器,植入挖礦程序,直到 2018 年 11 月 8 日 17 時 49 分該挖礦程序才中止。
2.3.5 歷史命令分析
經過對歷史命令分析,能夠看到曾執行如下惡意腳本。經過對腳本內容分析,發現其是一個挖礦腳本,和 http://www.tionhgjk.com:8220/mr.sh 爲同一腳本。
圖 19-部分歷史命令
圖 20-192.99.142.246:8220/mr.sh 惡意腳本內容
結論:歷史命令發現曾執行惡意腳本,腳本主要功能爲下載挖礦程序。
2.3.6 Hosts 文件分析
Host 文件記錄域名到 IP 的對應關係,在查詢時其優先級別高於 DSN 查詢,黑客常常將正常域名解析到黑客控制服務器的 IP 地址上,以實現監聽、代理等功能。對 OA 服務器的 hosts 文件分析,其解析狀況正常。
圖 21-hosts 配置分析
結論:hosts 文件正常。
2.3.7 登陸日誌分析
Last 記錄 OA 服務器最近用戶的登陸退出等狀況,經過對最近登陸狀況 (登陸用戶、登陸 IP、登陸時間等內容) 的分析,能夠了解系統的安全狀況。對最近登陸狀況分析,發現 OA 服務器最近登陸狀況正常。
圖 22-最近登陸狀況
圖 23-最近登陸失敗狀況
圖 24-最近登陸用戶狀況
結論:最近登陸狀況正常。
2.3.8 啓動項分析
啓動項記錄系統自啓動的狀況,若黑客入侵植入木馬或後門爲了持續控制該服務器,會將相應用服務加入到自啓動服務中。這樣的話,在重啓之後,也能夠持續控制該服務器。對 OA 的自啓動分析,發現其自啓動服務較多,未發現明顯異常自啓動服務。
圖 25-啓動服務
結論:未發現異常自啓動服務
2.3.9 病毒木馬分析
Linux 下病毒木馬相對較少,可是也存在。Linux 下主要的安全隱患是 rootkit,rootkit 是一種惡意程序,通常會和病毒木馬後門程序等捆綁在一塊兒安裝。而且系統被植入 rootkit 之後,經過系統沒法查找其文件、進程、網站流程、帳號等狀況。排除難度較大。查找 rootkit 通常經過工具查找,rkhunter 是一款不錯的 rootkit 查找工具。這裏,咱們使用 rkhunter 來查找 rootkit。
圖 26-rkhunter 查找 rootkit
圖 27-查找 rootkit 日誌
結論:經過以上分析,目前 OA 服務器無 rootkit
2.3.10 系統分析總結
經過以上的分析,能夠得出系統層面如下結論:
一、系統帳號正常
二、網絡鏈接狀況正常
三、開放端口過多,建議禁用非業務端口
四、定時任務發現歷史曾定時下載挖礦程序
五、歷史命令分析歷史曾下載挖礦程序
六、啓動項正常
七、未發現病毒、木馬、後門
由於該服務器只對互聯網開放 web 端口,而且經過系統層面的分析到該服務器曾經定時下載惡意腳本,所以基本斷定黑客是經過 web 方式入侵服務器的。所以,須要對 web 應用進行全面的分析,經過和 OA 開發人員溝通,其網站後臺的維護所有經過操做系統後臺進行維護,前臺沒法維護。所以須要對 web 應用進行全面分析。
2.4.1 Webshell 分析
使用 D 盾對 web 應用進行 webshell 查殺,未發現 webshell。
圖 28-使用 D 盾檢查 webshell 狀況
結論:無 webshell, 而且前文分析到系統中無後門與木馬,所以初步斷定黑客是經過應用的漏洞來入侵系統,而且該漏洞能夠執行系統權限。
2.4.2 日誌分析
目前 web 日誌只保存 2018 年 11 月 13 日到 14 日的日誌,因爲黑客入侵在 10 月 29 號或之前,所以沒法經過日誌分析黑客入侵的方式。
圖 29-訪問日誌
結論:因爲日誌只保存 11 月 13 日與 14 日,沒法經過日誌分析黑客的入侵方式。
2.4.3 Weblogic 分析
既然前面已經斷定黑客是經過 web 方式入侵的,而且這種利益驅動的黑客入侵的方式通常爲利用現有的漏洞批量入侵,所以須要對 web 應用的中間件及版本進行分析,再經過中間件類型與版本關聯相應的漏洞進行分析黑客可能的入侵途徑。
經過分析,OA 系統使用的是 weblogic 中間件,經過查看 registry.xml 配置文件分析,發現其 weblogic 的版本爲 10.3.6.0。經過 google 搜索相應的漏洞,發現該版本存在多個重大漏洞,可利用該漏洞 getshell,拿到服務器權限。相應的漏洞 CVE 編號以下:
1. CVE-2014-4210
2. CVE-2015-4852
3. CVE-2017-3248
4. CVE-2017-10271
5. CVE-2018-2628
……
圖 30-weblogic 10.3.6 漏洞
圖 31-weblogic 版本
圖 32- CVE-2017-10271
圖 33- CVE-2018-2628 漏洞
結論:因爲該服務器對外只開放 web 業務,基本上斷定黑客是經過 web 入口入侵,另外,因爲該版本存在較多高危漏洞,初步懷疑經過該漏洞入侵的可能性比較高。建議升級 weblogic 的版本或使用 WAF 進行防禦。
2.4.4 應用分析總結
因爲應用日誌只保存 11 月 13-14 日日誌,沒法經過日誌分析黑客入侵的方式,而且 weblogic 10.3.6.0 版本存在較多高危漏洞,所以初步斷定黑客是經過 weblogic 漏洞入侵。
1. 此 OA 爲某用戶老 OA,由於須要使用其數據才臨時啓用。
2. 此服務器對應內部 IP 爲 10.134.1.76,目前對互聯網僅開放其 6001 端口,22 端口只能經過內部訪問;目前僅對互聯網開放 6001 端口。
3. 系統帳號正常
4. 網絡鏈接狀況正常
5. 開放端口過多,建議禁用非業務端口
6. 定時任務發現歷史 (2018 年 10 月 29 日至 2018 年 11 月 8 日) 曾定時下載挖礦程序
7. 歷史命令分析歷史曾下載挖礦程序
8. 啓動項正常
9. 系統層面未發現病毒、木馬、後門
10. 由於其 OA 日誌僅保存 2018 年 11 月 13 日至 2018 年 11 月 14 日,黑客植入挖礦程序在 2018 年 11 月 8 號及之前,無相關日誌,沒法分析黑客入侵的途徑。
11. 目前追溯到 2018 年 10 月 29 日已被植入挖礦程序;2018 年 11 月 8 日或更早被植入 JS 代碼進行挖礦
12. 未保存黑客攻擊時 web 應用的相關日誌,沒法經過日誌分析黑客入侵的方式,可是 webgloic 相關版本存在較多高危漏洞,推測利用 weblogic 漏洞入侵的可能性較大。
1. 升級 weblogic 版本或者使用 WAF 進行防禦,同時須要升級 WAF 策略庫,以保障能夠防禦相應的漏洞
2. 按期對服務器進行安全檢查
3. 老的 OA 建議將相關數據遷移到新的 OA, 將老的 OA 暫停使用
4. 按期對網站進行滲透測試與安全監測
5. 按期升級 WAF 策略