理解攻擊向量
內核rookit通常以系統調用為攻擊目標，主要出于兩個原因：
a.在內核態劫持系統調用能以較小的代價控制整個系統，不必修太多東西；
b.應用層大多數函數是一個或多個系統調用不同形式的封裝，更改系統調用意味著其上層所有的函數都會被欺騙；
在kernel-2.4.27中大約有230多個系統調用，而kernel-2.6.9中大約有290多個系統調用，系統調用的個數取決于內核版本。完整的系統調用列表可以在 /usr/include/asm/unistd.h頭文件中獲得。
另外需要注意的是入侵者并不更改所有的系統調用，而只是替換其中一些比較有用的。這些系統調用如表一所示，他們可以被系統管理員及入侵檢測系統（OS kernel級IDS）監視，可以用man命令得到每個系統調用的完整描述。
System call name Short description ID
---------------------------------------------------------------------------------------
sys_read used for reading from files 3
sys_write used for writing to files 4
sys_open used to create or open files 5
sys_getdents/sys_getdents64 used to list a content of directories(also /proc) 141/220
sys_socketcall used for managing sockets 102
sys_query_module used for querying loaded modules 167
sys_setuid/sys_getuid used for managing UIDs 23/24
sys_execve used for executing binary files 11
sys_chdir used to change the directory 12
sys_fork/sys_clone used to create a child process 2/120
sys_ioctl used to control devices 54
sys_kill used to send signal to processes 37 |
我們注意上表的系統調用號，這些ID都是針對kernel-2.4.18-3的。
本文所有的例子都在Redhat7.3 kernel-2.4.18-3上通過測試，我們也可以在其他版本包括最新的2.6.x上用相似的步驟研究，不同之處可能在于2.6的一些內部結構，比如系統調用表的地址原來內含在系統調用處理例程system_call中，現在改成在syscall_call函數中。
更改系統調用表
當前的系統調用地址保存在系統調用表中，位于操作系統為內核保留的內存空間(虛擬地址最高1GB)，系統調用入口地址的存放順序同/usr/include/asm/unistd.h中的排列順序，按系統調用號遞增。
在0x80軟中斷發生之前，對應的系統調用號被壓入eax寄存器，例如sys_write被調用時，其對應的系統調用ID:4會被壓入eax。
入侵者使用的第一種方法是：更改系統調用表中的系統調用地址，這樣系統調用發生時會跳轉到攻擊者自己編寫的函數去執行。通過觀察系統調用表中的系統調用入口地址，使用gdb我們可以比較容易檢測到這種攻擊行為。
原始的系統調用地址在內核編譯階段被指定，不會更改，通過比較原始的系統調用地址和當前內核態中的系統調用地址我們就可以發現系統調用有沒有被更改。原始的系統調用地址在編譯階段被寫入兩個文件：
a.System.map該文件包含所有的符號地址，系統調用也包含在內；
b.系統初始化時首先被讀入內存的內核映像文件vmlinux-2.4.x；
vmlinux-2.4.x文件通常以壓縮的格式存放在/boot目錄下，所以在比較之前必須解壓這個文件，另一個問題是：我們的比較的前提是假設system.map及vmlinuz image都沒有被入侵者更改，所以更安全的做法是在系統干凈時已經創建這兩個文件的可信任的拷貝，并創建文件的md5 hash。
原文中也列舉了一個內核模塊[gcc -c scprint.c -I/usr/src/`uname -r`/include/ ]使用該模塊打印系統調用地址，并自動寫入syslog，這樣可以進行實時的比較。
在大多數被裝載內核后門情況中，內核在系統初始化之后才被更改，更改發生在加載了rootkit的module或者被植入直接讀寫/dev/kmem的on-the-fly kernel patch之后。而通常情況下rootkit并不更改vmlinuz和system.map 這兩個文件，所以打印這兩個文件中的符號地址就可以知道系統原始的系統調用地址，系統當前運行中的系統調用地址(可能被更改)可以同過/proc下的kcore文件得到，比較兩者就知道結果。
1.首先找出系統調用表地址：
[root@rh8 boot]# cat System.map-2.4.18-13 | grep sys_call_table c0302c30 D sys_call_table |
2.使用nm命令可以打印出未被strip過的image文件中所有的符號地址：
[root@rh8 boot]# nm vmlinux-2.4.18-13 | grep sys_call_table
c0302c30 D sys_call_table |
使用gdb可以打印出所有的系統調用入口地址，這些對應的地址在內核源代碼的entry.S文件中定義，例如：
entry 0 (0xc01261a0)是sys_ni_syscall系統調用
entry 1 (0xc011e1d0)是sys_exit系統調用
entry 2 (0xc01078a0)是sys_fork系統調用
#gdb /boot/vmlinux-2.4.*
(gdb) x/255 0xc0302c30
0xc0302c30 <sys_call_table>: 0xc01261a0 0xc011e1d0 0xc01078a0 0xc013fb70
0xc0302c40 <sys_call_table+16>: 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0
0xc0302c50 <sys_call_table+32>: 0xc013f180 0xc014cb10 0xc014c670 0xc0107940
0xc0302c60 <sys_call_table+48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0
... |
我們也可以通過系統調用名打印出系統調用的地址：
(gdb) x/x sys_ni_syscall
0xc01261a0 <sys_ni_syscall>: 0xffffdab8
((gdb) x/x sys_fork
0xc01078a0 <sys_fork>: 0x8b10ec83 |
要打印出當前運行系統中的系統調用地址我們必須給gdb加兩個參數：
a.第一個參數是內核映像文件vmliux-2.4.x
b.第二個參數是/proc/kcore二進制文件
#gdb /boot/vmlinux-2.4.* /proc/kcore
(gdb) x/255x 0xc0302c30
0xc0302c30 <sys_call_table>: 0xc01261a0 0xc011e1d0 0xc01078a0 0xc88ab11a <<--
0xc0302c40 <sys_call_table+16>: 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0
0xc0302c50 <sys_call_table+32>: 0xc013f180 0xc014cb10 0xc014c670 0xc0107940
0xc0302c60 <sys_call_table+48>: 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0
... |
我們注意到第一行最后的0xc88ab11a這個地址明顯不正常，這是系統調用號為3的系統調用，即sys_read (系統調用從0開始) 。
我們說它不正常的顯著標志是它的地址高于0xc8xxxxxx，Linux默認4GB線性地址，其中最高1GB0x00000000-0xffffffff為內核保留，當一個模塊被插入內核時，vmalloc函數為其分配一段地址空間，這個地址通常從0xc8800000開始...到這里已經很明顯了吧？
系統調用劫持
劫持系統調用與上一種方法不同之處在于：它并不直接修改系統調用表中的入口地址，即指向每個系統調用的跳轉指針，而是在想要hook的系統調用之前加一段跳轉代碼，使執行流重定向到入侵者自己的內核態函數，這些被hook的系統調用前部通常有call,jmp之類的匯編指令。
要檢測這種攻擊，同樣使用gdb加vmlinux-2.4.*及/proc/kcore兩個參數，然后反匯編系統調用：
#gdb /boot/vmlinux-2.4.* /proc/kcore
(gdb) disass sys_read
Dump of assembler code for function sys_read:
0xc013fb70 <sys_read>: mov $0xc88ab0a6,%ecx
0xc013fb73 <sys_read+3>: jmp *%ecx <<--
0xc013fb77 <sys_read+7>: mov %esi,0x1c(%esp,1)
0xc013fb7b <sys_read+11>: mov %edi,0x20(%esp,1)
0xc013fb7f <sys_read+15>: mov $0xfffffff7,%edi
... |
我們注意"mov $0xc88ab0a6,%ecx -- jmp *%ecx"這兩條指令，他跳轉到了其他的地方去執行了。
然后再來看一下被hook之前的系統調用指令：
#gdb /boot/vmlinx-2.4.*
(gdb) disass sys_read
Dump of assembler code for function sys_read:
0xc013fb70 <sys_read>: sub $0x28,%esp
0xc013fb73 <sys_read+3>: mov 0x2c(%esp,1),%eax
0xc013fb77 <sys_read+7>: mov %esi,0x1c(%esp,1)
0xc013fb7b <sys_read+11>: mov %edi,0x20(%esp,1)
0xc013fb7f <sys_read+15>: mov $0xfffffff7,%edi
... |
看到了吧，不一樣的。
更改系統調用處理例程
入侵者可能修改一些重要的內核函數，比如系統調用處理例程system_call函數，顧名思義，這個函數對用戶請求的系統調用作出響應，在系統調用表中尋找對應的入口地址，然后跳轉到那里執行，這個函數中保存了系統調用表的地址。攻擊者能做什么呢？另辟一塊內存空間，在那里攻擊者偽造自己的系統調用表，然后修改system_call函數中的系統調用表地址指向那里就可以了。
通過反匯編system_call函數可以找出系統調用表的地址：
(gdb) disass system_call
Dump of assembler code for function system_call:
0xc01090dc <system_call>: push %eax
0xc01090dd <system_call+1>: cld
0xc01090de <system_call+2>: push %es
0xc01090df <system_call+3>: push %ds
0xc01090e0 <system_call+4>: push %eax
0xc01090e1 <system_call+5>: push %ebp
0xc01090e2 <system_call+6>: push %edi
0xc01090e3 <system_call+7>: push %esi
0xc01090e4 <system_call+8>: push %edx
0xc01090e5 <system_call+9>: push %ecx
0xc01090e6 <system_call+10>: push %ebx
0xc01090e7 <system_call+11>: mov $0x18,%edx
0xc01090ec <system_call+16>: mov %edx,%ds
0xc01090ee <system_call+18>: mov %edx,%es
0xc01090f0 <system_call+20>: mov $0xffffe000,%ebx
0xc01090f5 <system_call+25>: and %esp,%ebx
0xc01090f7 <system_call+27>: testb $0x2,0x18(%ebx)
0xc01090fb <system_call+31>: jne 0xc010915c <tracesys>
0xc01090fd <system_call+33>: cmp $0x100,%eax
0xc0109102 <system_call+38>: jae 0xc0109189 <badsys>
0xc0109108 <system_call+44>: call *0xc0302c30 (,%eax,4) <<--系統調用表地址
0xc010910f <system_call+51>: mov %eax,0x18(%esp,1)
0xc0109113 <system_call+55>: nop
End of assembler dump. |
注意：上面的輸出中顯示的是一個正常的系統調用表地址。
實用工具
一種方法是使用基于主機的入侵檢測系統HIDS實時監控重要的內核結構，比如使用Samhain工具，可以監視系統調用表、IDT等，在“Host Integrity Monitoring: Best Practices for Deployment”一文中有相關描述。
譯者注
本文提及的方法在kstat2.4版中都有代碼的實現，可以參閱kstat/2.4/src/syscall.c，使用gdb是一種手工檢測方法，它能解決的問題是檢測系統是否被更改，至于如何找出內核rootkit還需要一些工具，比如madsys在phrack60上的module_hunter.c，有2.4和2.6的版本，grip2、coolq對其做了一些修改，并且該代碼不斷完善中。
責任編輯 趙毅 zhaoyi#51cto.com TEL:（010）68476636-8001
