巧用 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-n ， grep"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 、弱密碼…沒錯，弱密碼被暴力猜解了！

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

（陳國 | 天存資訊）

相關文章