巧用 iLocker 清理惡意程式

天存資訊發表於2021-06-02

iLocker 作為 iGuard 網頁防篡改系統的檔案驅動過濾模組所衍生出來的獨立應用,是一個檔案防護工具,可以在檔案系統驅動層檢查檔案操作,根據規則對檔案操作進行放行或攔截,可以靈活細緻地對檔案訪問進行控制。

分享一則 iLocker 在實際運用中的案例,幫助大家擴充 iLocker 的運用思路——

起因

和許多突發事件一樣,本次案例也發生在狀況高發期——半夜。

工程師小張反饋伺服器有不明程式在執行,判斷不出程式的執行意圖不說,它甚至還吃掉了100%的 CPU。小張嘗試 kill 掉這個不明程式,卻每次都會有新的程式殺出來,名字不盡相同,都是無規則的一串字母,好不煩人。

根據小張所述,並沒有什麼頭緒,只有在程式裡找線索了。

首先要釐清伺服器(Linux)上的程式狀態。 top 命令一看,確實有個符合上述特徵的奇怪程式在吃 CPU。

嘗試重現小張所說情況: kill-9 可以殺掉,再 top 一看,又出來一個程式,名字變了,但換湯不換藥。

pic

觀察

依照常規,用 ps-ef|grep 檢測發現,如下圖,7769,分明是同一個程式 ID。 top 所顯示的程式名和 ps 得到的結果並不一樣。這一項問題姑且不論,檢查後還發現, ps 命令沒有被替換,程式還沒有感染整個系統。可以用 lsof 進一步檢視此程式,發現程式檔案在 /usr/bin/ 下。

pic

可以嘗試再 kill 一次程式。

雖然如意料之中,得到和最初一樣的結果,但再執行一次 ps 命令,我們有了新發現:不止7769一個程式,還暴露出一長串異常程式。

pic

總結一下這次的問題:在同一時間點上,多個不該執行的命令在執行,比如 route-ngrep"A" ,甚至還有 echo"find" 這樣的命令,十分反常。不僅如此,這些命令變化大量且迅速,每個程式短暫執行數秒即消失,新命令程式也在不斷生成。

至此,這次異常狀況的形態已初露端倪,100%佔用 CPU 的程式可以斷定是核心工作程式,其他變化多端的閃現程式則充當保護肉盾,用來保護真正的工作程式不被殺死刪除。棘手的,便是這些周而復始,陰魂不散的保護程式了。

當然,經驗豐富的我方安全戰鬥人員,一線作戰經驗豐富,如果排查出問題所在,解決方案也當即應運而生。

shell 提示新郵件,檢視一下,或許是個不錯的切入點哦!

pic

不要錯過任何一個線索——

pic

草蛇灰線,掩藏得再好,蛛絲馬跡還是被找到了!

pic

指令碼意圖明顯,功能簡單明瞭:

  1. 使用 ifconfig 命令啟動所有網路卡
  2. 複製 /lib/libudev.so/lib/libudev.so.6
  3. 啟動 /lib/libudev.so.6

可以看出

  • crontab 發出了提醒郵件,是因為系統沒有 ifconfig 命令,指令碼報錯了。
  • 指令碼啟動的是 /lib/libudev.so.6 ,看起來這個檔案比較關鍵。

先嚐試刪除 /lib/libudev.so.6 ,rm 命令執行成功。但是再次 ls 的時候,它又出現了。猜測是那些奇怪的程式在維護這個 /lib/libudev.so.6 不被清理。

思路變得簡單了:

  • 怎麼知道它都把檔案複製到哪裡去了呢?
  • 怎麼找到並殺死那些不停閃現的程式呢?
  • 怎麼阻止它複製自己呢?

手段

iLocker 大顯身手的時候到了。

iLocker 可以保護檔案或目錄不被篡改,不但能阻止檔案建立,還能發現惡意程式操作了哪些檔案。無需多言,iLocker 配置起來。

配置前,有如下幾點考慮:

  • 惡意程式的可執行檔案,在 /usr/bin 下面,需要把 /usr/bin 保護起來;
  • 定時指令碼里的惡意程式路徑在 /lib/libudev.so ,所以也把 /lib 也保護起來;
  • /tmp 目錄也比較特別,也需要特別關注一下;
  • 我自己要刪除 /lib/libudev.so ,所以先要把自己放開;
  • 發現系統的 /lib 目錄實際上是個軟連結 /usr/lib ,故而實際保護
    /usr/lib 目錄。

簡單解釋下 iLocker 的規則:

#uid=0,exe_path=*,cmdline=*,operation=MKDIR,file_path=/tmp/test/pass/*,action=pass
#uid=*,exe_path=*,cmdline=*,operation=*,file_path=/tmp/test/*,action=deny

一條規則包含以下資訊,根據這些資訊 iLocker 可以捕獲任意一個檔案操作,並對其進行攔截或記錄:

  • 使用者 uid ,程式所屬的使用者 ID;
  • 可執行檔案的路徑 exe_path
  • 程式的命令列引數 cmdline ,常用來區分同一個程式的不同程式,比如 java ,python ,shell 等;
  • 具體的檔案操作 operation (如 CREATE ,OPEN , MKDIR 等);
  • 被操作的檔案路徑 file_path
  • iLocker 的響應動作 action (pass ,deny ,log)等。

根據觀察現象過程中搜集到的資訊,在 iLocker 中寫入如下配置——

exe_path=/usr/bin/rm,file_path=/usr/lib/*,action=pass
file_path=/usr/bin/*,action=deny
file_path=/usr/lib/*,action=deny
file_path=/tmp/*,action=deny

啟動 iLocker ,並開啟 iLocker 日誌管理器,發現瞬時增加很多新日誌,瀏覽下來,幾乎都是惡意程式在寫檔案。如下:

2019-03-15 5:42:12,CREATE,0,14840,/usr/bin/irjsypzavm,/usr/bin/szklfovzwg,,deny
2019-03-15 15:42:12,CREATE,0,14840,/usr/bin/irjsypzavm,/tmp/szklfovzwg,,deny
2019-03-15 5:42:17,CREATE,0,14848,/usr/bin/irjsypzavm,/usr/lib/libudev.so,,deny
2019-03-15 5:42:18,CREATE,0,14848,/usr/bin/irjsypzavm,/usr/lib/libudev.so,,deny

例如其中第3條日誌:

使用者 ID=0 ,程式 ID=14848 ,
程式檔案為 /usr/bin/irjsypzavm ,
想 CREATE 檔案 /usr/lib/libudev.so ,被攔截了。

之前的假設得到了證實——程式在不停地複製自己。

同時,我們也找到了惡意程式自我複製的路徑: /usr/bin 或 /tmp/ 下,檔名隨機,複製到 /usr/lib/libudev.so 是固定的檔名。

解決

一波操作之後,終於可以痛下殺手,斬草除根了:

  • 再次 kill 掉100% CPU 的程式
  • rm /lib/libudev.so
  • 清理留下的惡意檔案,清理crontab

如上所述,這些程式每次完成自我複製,就相應拉起一些新的程式,自己退出。

這次,且不用勞神一個一個找出這些程式:iLocker 執行,程式不再複製成功,自己退出。沒複製成功,也就意味著不再拉起新的程式。

iLocker 出馬,惡意程式原地自閉了!本局,安全團隊藉助 iLocker 輕鬆實現全壘打!

案例總結

該案例下,伺服器只開了一個 ssh 服務和一個只提供靜態頁面的 web 服務,系統是最新的,還打了補丁,看起來無懈可擊……

但是!

一個沒有“但是”做ending的案例是不完美的!

……

返回去檢視系統登入日誌,發現了大量失敗的登入記錄,回想起最初工程師小張提供的登入資訊,root 、弱密碼…沒錯,弱密碼被暴力猜解了!

安全是個整體
哪裡都要注意
弱密碼要慎用!

(陳國 | 天存資訊)

相關文章