聊一聊chkrookit的誤信和誤用

wyzsk發表於2020-08-19
作者: 百度安全攻防實驗室 · 2015/06/19 17:06

很久不寫文章了。BSRC在約稿以及個人最近吐槽模式的開啟,索性就藉著勁頭寫點東西緩解緩解。

chkrookit以及rkhunter基本上已經成為類unix系統的應急響應中的標配了。大多數處理安全事件基本上上機器的第一步都是來個兩連發。但很多是以失望結束,或者出了結論又不知道如何是好。這篇文章或許能夠解決你們的部分困惑。這篇文章主要是講chkrootkit,rkhunter回頭有空再吐槽。

首先對工具我們應該有一個明確的認識。工具是死的,人是活的,攻防本身就是人與人的對抗。挑戰的物件是活生生的人而不是預定義好的程式時,機械的依靠某個工具,真正上戰場了註定要悲劇。對於用於實際對抗中使用的工具,什麼時間用,能夠解決什麼問題,對它的期望如何。我們心裡應該很清楚,甚至我們有多大程度可以相信它的結論,欺騙或者bypass它的成本是什麼樣子也都需要了解。

言歸正傳,這篇文章我們先聊聊chkrootkit: http://www.chkrootkit.org。從README中我們瞭解到最近一次更新是:04/30/2014,而前一次更新是09年…看看CHANGELOG,大概也能夠明白它都有哪些功能,程式碼目錄的命名很好的反應出了這一點:

enter image description here

chkrootkit本身是一個shell指令碼。執行 chkrootkit –l 可以看到所有的檢測集。注意chkrootkit指令碼這幾個字的重點飄紅。一般來說,這種開源的指令碼呼叫外部命令方式工作的安全檢查程式,按照經驗註定是悲劇的節奏(注意定語)。而且上機器後看都不看執行環境就執行這類檢測程式極易被反補一刀1

開啟chkrootkit我們一開始就看到這樣兩句SHELL

#!bash
pth=`echo $PATH | sed -e “s/:/ /g”`

pth=”$pth /sbin /usr/sbin /lib /usr/lib /usr/libexec .”

嘖嘖,檢查範圍讓64位作業系統情何以堪啊

大體來說檢測流程是什麼樣子吧:

  1. 歷史遺留rootkit/backdoor/蠕蟲的預設檢測;方式為根據位置、特殊的檔名、字元之類的來找檔案,根據繫結的埠號來看是否有某個特定的後門(拜託…)。但這些查詢特徵赤裸裸的寫在chkrootkit這個指令碼里面的,繞過這類的檢查的成本有多大,指望在實際對抗中,能查出什麼樣的東西,大家預期不要太高。
  2. 後面進入checking階段,有幾個check點還比較有意思,但基本上都是靠外部的bin來實現的。但我們不要忘記了,這些bin執行的環境很有可能是惡意的哦。

這裡不討論從ring0上怎麼躲避檢查了,簡單的一些open檔案的redirect就能夠bypass一堆,有興趣的可以去phrack 97年的文章中看看思路3。靠ring3的開源程式去查ring0級別的未知後門本身出發點就有問題,這裡注意是開源啊,再用ring0去bypass純粹是欺負人啊:)。(當然對於實現不好的,只能被稱作beta版的rootkit還是有可能,檔案引用計數差異啊、沒有相互配合好的cd和readdir呼叫啊之類的。但誰讓你開源啊~嘖嘖。)

吐槽我還是限制後門在ring3下的實現吧。

Ldd看一下

enter image description here

這裡以Linux為例,不傳引數的情況下的make,產出的是一堆使用動態連線的bin,一個ld.so.preload就可以直接KO了。判定開啟檔案的讀寫物件,塞一個正常的給他即可。再看看有沒其他更有意思的繞過方式。一個一個的來分析檢測原理:

1 chkproc程式

a) chkproc函式完成了ps命令隱藏以及readdir函式隱藏的檢測。

b) 檢測邏輯:比對ps和readdir的輸出以及透過遍歷到MAX_PROCESSES(99999)的程式嘗試chdir到每個目錄/proc的結果來找出差異並報告(只有99999啊,嘖嘖),完全可以把pid拉起來啊 , 不過這樣檢查會導致報告一個OooPS錯誤

enter image description here

c) 實際使用經驗來看,高併發的機器上,ps輸出完畢後,再去讀取/proc目錄中的內容,時間視窗也會帶來很大的誤差

d) 對於利用ptrace等方法注入shellcode或者SO到其他程式的後門檢查無效

e) 不隱藏的程式無效

2 chkdirs程式:

a) 接受要檢查的目錄,遞迴檢查,透過比對父資料夾的link計數和子資料夾計數的差異來發現異常。正常情況下父目錄的link計數應該是所有子項的數目+2

b) 在呼叫chkdirs這個命令的時主程式傳遞的引數為“/tmp /usr/share /usr/bin /usr/sbin /lib”大家記得別把隱藏檔案放這些目錄即可,這是在逗我麼…

c) 不隱藏的檔案無效

3 chklastlog、chkutmp chkwtmp

a) 本質上這幾個程式都是在對utmp wtmp之類的檔案做交叉比對,有些工具會檢查某些特殊的欄位,比如time是否為0。此類的檢查工具的檢查思路更多的是來自對外界廣泛流傳的日誌擦除工具的瞭解。

b) 程式實現時有硬編碼的略過賬戶在裡面,可以直接將產生的log主體改成它可以繞過檢查

c) 不要輕易的將日誌的欄位完全清0,甚至在某些程度上,你可以從其他的entry copy一個過來

4 ifpromisc程式

a) 列舉系統上處於混雜模式的介面以及PF_PACKET鏈路層套接字的程式來查詢嗅探器

b) 建議採用so hijack的方式進行隱藏

看到現在,應該大概對chkrootkit 的定位和功能有效性有所感覺了:

  • 首先,基本的、初級的入侵行為,比如uid=0,許可權異常,檔案系統的檔案替換和新增、刪除,這還得你自己查。甚至當前可列的程式埠,你還是要自己去看的。Chkrootkit充其量是輔助,或者輔助的輔助。
  • 沒有自作(第一聲)的程式是查不出來的,你堂而皇之的拿crontab起一個回連後門,它根本吱都不會吱一聲。稍微複雜一些的它也查不出來,比如so注入等後門。Chkrootkit只能幫你做很有限的一些入侵特徵檢查,而且這種檢查是經驗性的,是建立在對攻擊者尿性的揣摩基礎上。
  • 由於是開源,檢測邏輯很好繞,而且存在很多方式方法。攻擊者換個姿勢,就瞎了,幾乎可以肯定定製化的 rootkit根本查不出來。
  • chkrootkit的後門/rootkit檢測對抗工作思路還很樸素。別指望能有啥重大發現了。

清楚了一個安全檢測工具的工作原理和侷限性、公開了check 點,在一個“通用”的作業系統上對抗,攻擊者以有心算無意總能有收穫。通用系統的坑或者特性太多了,拿啟動位置來說,隨隨便便能列一堆之前聽都沒聽過的地方,惡意程式利用這些點,都能帶起來。

假使應急響應中需要使用這類透過研究攻擊者尿性開發的有針對性的工具,還是老老實實的private吧,這類東西屬於出奇制勝、見光死。

多關注關注CVE,呵呵,你的檢查執行程式,別成了人家本地提權的途徑了。說不定人家造成大的動靜就等著你來chkrootkit呢!

最後,以一個吐槽結束,應急響應最重要的目標在實際操作中太容易被忽視。弄清怎麼進來的,進來後做了啥,造成了哪些損害。我們不是要和攻擊者玩躲貓貓,你來藏我來找。事情結了後,能重灌就重灌吧,別折騰清理什麼後門了。保不齊就被就被你沒留意的一個小細節或者不知道的一個特性給坑了。Focus目標, 勿忘初心。

References:


(1]https://www.exploit-db.com/exploits/33899/

(2]https://github.com/ossec/ossec-hids/releases/tag/2.8.2

(3]http://www.phrack.org/issues/51/9.html#article

本文章來源於烏雲知識庫,此映象為了方便大家學習研究,文章版權歸烏雲知識庫!

相關文章