【Rootkit 系列研究】Rootkit 檢測技術發展現狀

摘要

Rootkit這一概念最早出現于上個世紀九十年代初期，CERT Coordination Center(CERT/CC)于1994年在CA-1994-01這篇安全咨詢報告中使用了Rootkit這個詞匯。在這之后Rootkit技術發展迅速，這種快速發展的態勢在2000年達到了頂峰。2000年后，Rootkit技術的發展也進入了低潮期，但是對于Rootkit技術的研究卻并未停滯。在APT攻擊日益流行的趨勢下，Rootkit攻擊和檢測技術也同樣會迎來新的發展高潮。

在往期的Rootkit系列文章里面，我們分別介紹了Rootkit技術的發展歷程和Windows、Linux平臺下的Rootkit攻擊技術。本期Rootkit系列文章將會給大家介紹當前主流的Rootkit防御技術以及一些非常規Rootkit的可實施檢測方案。

被濫用的Rootkit技術

長期以來，Rootkit檢測一直是一個非常大的痛點，這些具有高度定制化的惡意程序集合隱藏在服務器上，以高權限訪問計算機和網絡。雖然Rootkit并沒有成為大新聞中的主角，但是它們一直都過得很安逸，并且持續性的造成損害。對于安全從業者而言，這不應該是一個被忽視的地方。

APT通常和Rootkit齊頭并進。從西方 APT 組織的攻擊歷史及已經泄露的網絡武器看，高隱匿、高持久化(Low&Slow)是其關鍵特征，而 Rootkit 則是達成此目的的重要技術之一，因此Rootkit一直以來和APT配合的很好。

讓人遺憾的是，幾乎任何腳本小子都可以輕易在被攻擊成功的目標主機上植入Rootkit。比起這個，更讓人痛心的是，一些挖礦木馬和廣告木馬都開始使用Rootkit技術了，黑產都卷成這個樣子了嗎？H2Miner挖礦家族開始使用新的Rootkit樣本，該Rootkit使用LD_PRELOAD技術劫持動態鏈接過程。LD_PRELOAD是一個非常古老的C庫技巧，但它今天仍然被成功使用和濫用。

當前主流Rootkit檢測技術分析

當前主要的Rootkit檢測的方法包括但不限于以下幾種類型。

1. 基于Rootkit運行的效果進行檢測
例如: 發現隱藏的端口、進程、內核模塊、網絡連接、被篡改的內核代碼。

缺陷: 該檢測方案對預設的檢測場景的依賴程度較高，一旦惡意軟件出現檢測場景之外的行為，則難以做到有效檢測。

2. 靜態文件特征檢測
例如: 掃描磁盤上的文件，將文件與特征庫進行匹配，通過該方式檢測可能存在的Rootkit。

缺陷: 該檢測方案對特征庫依賴程度較高，能夠有效發現已知特征的Rootkit，難以發現未知特征的Rootkit。

3. 動態行為分析檢測
例如: 對系統運行過程中的行為進行審計，通過行為規則匹配的方式發現系統中的異常行為，通過該方式發現可能存在的Rootkit。

缺陷: 對行為規則的依賴程度較高，只能匹配已知行為特征的Rootkit，難以匹配未知行為特征的Rootkit。

4. 數據完整性檢測
例如: 對系統關鍵的數據結構進行監控，通過監控關鍵數據結構的異常篡改，以發現系統中的惡意行為。

缺陷: 完整性檢測依賴于受信任的源數據，如果源數據被篡改或者不可信的情況下，則完整性檢測也很難奏效。

當前的開源社區的Rootkit檢測技術主要以Rootkit運行效果檢測和靜態文件特征檢測為主，動態行為分析和數據完整性保護的Rootkit檢測項目相對較少。

當前主流Rootkit檢測項目分析

Chkrootkit: 檢測/proc/kallsyms的內容并匹配相對應的文件名和目錄來檢測是否存在Rootkit，通過該方式，chkrootkit能夠在一定程度上發現Rootkit執行的惡意行為，諸如文件隱藏，網絡連接隱藏，進程信息隱藏。但是該檢測方案對Rootkit指紋庫依賴度較高，并且嚴重依賴于/proc/目錄下的文件，一旦該文件不可信任，則很容易被繞過。

Rkhunter: 這個Rootkit檢測工具會掃描相應的文件目錄、文件、符號表，通過該方式檢測是否存在Rootkit惡意家族。同樣的，該檢測方案對特征庫的依賴度較高，且難以發現指紋沒有覆蓋到的Rootkit。

Kjackal: 該Rootkit檢測工具通過遍歷內核中的系統調用表syscall_table，注意檢查例程的入口是否存在內核空間，如果不存在，就意味著發生了syscall劫持。發現了存在syscall_table的劫持之后，該工具會進行反向追蹤，以確定劫持系統調用的是哪一個惡意LKM模塊。Kjackal會枚舉/proc/net/tcp的讀寫句柄是否存在于內核態中，如果不存在，則發生了劫持。該工具還會枚舉modules kset以檢測隱藏的內核模塊。該檢測方案也同樣存在被繞過的可能性，一旦Rootkit通過刪除kobject數據結構的方式隱藏Rootkit，那么這將很難檢測，不過這種刪除kobject數據結構的方式也同樣會影響Rootkit正常使用。

Tyton: 該項目檢測Rootkit的方式和kjackal非常相似，通過枚舉內核空間的module_list，中斷向量表、網絡連接讀寫句柄、系統調用表、netfilter hook等方式發現可能存在的Rootkit，發現Rootkit之后，通過get_module_from_addr函數反向溯源惡意的內核模塊。

Elkeid: 該項目是字節跳動的一個開源的HIDS項目，該hids檢測Rootkit的方式繼承的tyton的檢測方案。除了這個之外，elkeid還在行為檢測方面做出了突破，使用kprobe對關鍵的系統調用進行hook，持續監控系統運行過程中的進程行為，網絡行為、文件行為等相關信息并保存到日志中，再使用字節跳動于近期開源的Elkeid Hub的行為日志檢測引擎和規則集，能夠對系統運行過程中的日志進行自動化分析，以發現可能存在的未知威脅。不得不說這是一個非常勇敢的突破，業界普遍都對kprobe持保留態度，敢于直接上車的并不多見。不過這種日志采集方式也存在一個缺陷，一旦攻擊者控制了/sys/kernel/debug/kprobes/enabled文件，就可以使這種日志采集功能失效。再補充一句，該項目更新頻率較高，并且社區支持非常友好。

stmichael-lkm: 該項目能夠為內核提供一定的完整性保護，能夠在一定程度上發現針對內核的篡改，通過這種方式發現可能存在的Rootkit。一旦檢測到Rootkit篡改內核，StMichael嘗試通過將所做的更改回滾到先前已知的良好狀態來恢復內核的完整性。不得不說這是一個非常大膽的嘗試，比使用kprobe更加激進，這種方案的致命缺陷就是很容易為系統引入未知的問題，導致系統的不穩定。

Qiling: 該項目是一個高級二進制仿真框架，能夠模擬多平臺，多架構的運行環境，通過類似于沙箱的環境運行Rootkit，并且記錄Rootkit運行過程中的行為。這為惡意Rootkit的檢測和分析提供了一種全新的思路。傳統沙箱對惡意軟件的檢測很難達到這種細粒度的監控效果。

非常規Rootkit以及檢測方案

使用了命名空間技術的HorsePILL

在講述該Rootkit之前，有必要簡單介紹一下命名空間的含義。命名空間是Linux的一個非常重要的系統特性，Linux的命名空間機制提供了一種資源隔離的解決方案。PID,IPC,Network等系統資源不再是全局性的，而是屬于特定的Namespace，不同命名空間的資源是互相隔離的，在一個命名空間所做的事情不會影響另一個命名空間。各命名空間在Linux的引入版本如下:

由于命名空間的隔離特性，這給惡意文件的隱藏提供了新的思路。將惡意文件和惡意文件運行過程中的進程、網絡置于一個與系統不同命名空間的環境中，可以非常有效的隱藏自身，在一定程度上來說，難以發現。

HorsePILL這個Rootkit就利用了這種命名空間的特性，該Rootkit會感染系統的initramfs，被感染的系統在啟動過程中加載initramfs就會執行Rootkit的惡意代碼。惡意代碼執行之后，會將整個系統置于一個新創建的子命名空間之中，而惡意代碼本身運行于更上級的命名空間。這種Rootkit隱藏方式可謂是別具一格，對系統的性能影響可以說忽略不計。是一個非常棒的Rootkit，美中不足的是該Rootkit需要重啟系統才能夠執行其惡意代碼。

這種Rootkit也是有非常有效的運行時檢測方案，首先，該Rootkit需要感染initramfs，基于這一點可以修改grub，給grub新增一個啟動過程中校驗initramfs和vmlinuz文件完整性的功能，避免啟動不受信任的系統。當系統不幸感染了這種基于命名空間的Rootkit，整個系統用戶空間的數據已經不在可信的情況下，可以從內核態中測繪各個命名空間的信息，并且從中發現異常的命名空間數據。

感染horsepill，攻擊者拿到了設備的shell，攻擊者視角下真實的1號進程的命名空間數據如下:

感染horsepill之后設備管理員視角下，可以非常直觀的看到命名空間信息已經出現了異常，而這種異常信息通常是被人忽略的。

對于這種Rootkit，受害主機運行時可以通過命名空間測繪的方式發現Rootkit的存在。

使用kprobe技術的Rootkit

在上文中講Elkeid的時候提到了kprobe這個機制，這個機制可以用來采集系統的行為信息，當然也可以用來編寫Rootkit。Kprobe、jprobe以及kretprobe可以在內核符號的函數序言和函數尾聲插樁，一旦內核符號注冊了kprobe，就會修改函數序言，被修改的函數序言會執行一個跳轉指令，跳轉到一個新的內核符號trace_spurious_interrupt，然后由trace機制跳轉到中斷處理函數，中斷處理函數再調用kprobe的回調函數，使用kprobe技術可以篡改部分內核符號的入參和返回值，這能夠非常容易的達到隱藏惡意程序相關信息的目的，并且這種Rootkit隱蔽性也同樣很強。

這類Rootkit的檢測方法也是同樣不同于前面的方案的。最簡單的判斷方法就是查看/sys/kernel/debug/kprobes/list這個文件的內容。

但是該方案有一個非常致命的缺陷，系統感染了kprobe的Rootkit之后，/sys/kernel/debug/kprobes/list文件的內容已經是不可信的了，因此需要從其他途徑獲取Rootkit檢測的線索。

內核中有這么一個數據結構kprobe_table，該數據結構維護了所有注冊的kprobe的表，遍歷這張表，可以發現感染這類Rootkit的kprobe數據結構。

內核符號在vmlinuz、掛載kprobe之前和掛載kprobe之后其數據都是存在非常明顯的差異性的。例如: 內核符號SyS_ptrace經過kprobe掛載前后的內存數據對比如下圖:

左邊是掛載kprobe之后的內存數據，右邊是掛載kprobe之前的內存數據，根據兩者對比，可以發現前4個字節存在差異。同樣也是這個內核符號，在/boot/vmlinuz文件中的二進制數據也和上面兩者不同，相關數據如下圖所示:

其差異同樣體現在符號的前4個字節。這三者之間的差異主要由兩方面因素所導致。首先是vmlinuz加載到內存時，會動態的修改其代碼內容，這種修改主要通過.altinstructions這個段中的數據完成的。加載到內存之后，再對其掛載kprobe，修改的同樣是前4個字節，將這部分差異性較強的代碼進行反匯編，可以得出其匯編代碼。

Vmlinuz：
Before kprobe:
After kprobe:

反匯編這部分數據，可以看到其具體的操作碼也有較強差異。首先，符號SyS_ptrace的內存地址為0xffffffff8108a1b0，掛載kprobe之后，其執行的第一個指令為call 0x5bd300。因此可以計算，其跳轉地址為:'0xffffffff816474b0'。查詢該地址對應的符號如下:

根據上述分析內容，kprobe Rootkit會在執行過程中修改內核符號的函數序言，因此要檢測這種類型的Rootkit，還可以對運行時的內核代碼進行完整性檢測。

基于ebpf的rootkit

基于bpf的Rootkit并不是什么新鮮事物，bpf技術于1993年就被提出，bpf的指令集并非是一種圖靈完全的指令集，因此使用bpf指令開發Rootkit似乎是一種天方夜譚。但是APT組織Equation Group做到了，在shadow brokers于2016年公開方程式的工具包中，有這么一個不太引人矚目的Rootkit DewDrops。這么長時間以來，大多數人眼里看到的可能只有永恒系列漏洞利用和doublepulsar后門，而對于其中的Dewdrops Rootkit，卻是很少有人關注。盡管他的知名度并不高，但并不影響我對這個Rootkit設計者的佩服。

但是DewDrops并非此次的主要內容，這一段的主角rootkit是ebpfkit，這個Rootkit于2021年在多個世界頂級安全會議上亮相。該Rootkit可以hook內核態函數，篡改內核態返回用戶態緩沖區數據，達到用戶態欺騙的目的。用戶態進程拿到被篡改的數據，從而被騙通過認證。在此過程，不改變任何文件、進程、網絡行為，不產生日志。常規HIDS、HIPS產品無法感知。eBPF還支持kprobe/kretprobe、uprobe/uretprobe、XDP、TC、socket、cgroup等程序類型，覆蓋文件、網絡、socket、syscall等事件，都是可以被黑客利用的地方。

面對這么復雜的威脅，從安全防御的視角，該怎樣處理這種類型的威脅呢？這個Rootkit的作者給出了這么一份答卷(業界良心啊)。作者開源了針對這種Rootkit的檢測工具ebpfkit-monitor。該工具可用于靜態分析eBPF字節碼或在運行時監控可疑的eBPF活動，盡管當前該檢測工具僅僅針對ebpfkit，但是這無疑給研究基于ebpf技術的Rootkit檢測工具的人提供了良好的思路。