Linux下用gdb检测内核rootkit的方法(1)

Linux下用gdb检测内核rootkit的方法(1)

本文涉及的技术原理都不是新的,对研究人员没什么特别大的价值,不过对工程人员应急相应来说不失为一种新的方法.

理解攻击向量】

前面两段废话直接掠过...实在浪费感情-_-!

内核rookit通常以系统调用为攻击目标,主要出于两个原因:

a.在内核态劫持系统调用能以较小的代价控制整个系统,不必修太多东西;

b.应用层大多数函数是一个或多个系统调用不同形式的封装,更改系统调用意味着其上层所有的

函数都会被欺骗;

在kernel-2.4.27中大约有230多个系统调用,而kernel-2.6.9中大约有290多个系统调用,系统调用的个数取决于内核版本.完整的系统调用列表可以在 /usr/include/asm/unistd.h头文件中获得.另外需要注意的是入侵者并不更改所有的系统调用,而只是替换其中一些比较有用的.这些系统调用如表一所示，他们可以被系统管理员及入侵检测系统(OS kernel级IDS)监视，可以用man命令得到每个系统调用的完整描述。

System call nameShort descriptionID

-------------------------------------------------------------------------------------------

sys_readused for reading from files 3

sys_writeused for writing to files 4

sys_openused to create or open files 5

sys_getdents/sys_getdents64used to list a content of directories(also /proc) 141/220

sys_socketcallused for managing sockets102

sys_query_moduleused for querying loaded modules 167

sys_setuid/sys_getuidused for managing UIDs 23/24

sys_execveused for executing binary files 11

sys_chdirused to change the directory 12

sys_fork/sys_cloneused to create a child process 2/120

sys_ioctlused to control devices 54

sys_killused 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中的排列顺序，按系统调用号递增。鉴于原文废话很多，我就跳着翻译或者概括起来翻译，有兴趣的可以找本Linux内核的书看看(e.g:ULK2)

在0x80软中断发生之前，对应的系统调用号被压入eax寄存器，例如sys_write被调用时，其对应的系统调用ID:4会被压入eax

入侵者使用的第一种方法是：更改系统调用表中的系统调用地址，这样系统调用发生时会跳转到攻击者自己编写的函数去执行。通过观察系统调用表中的系统调用入口地址，使用gdb我们可以比较容易检测到这种攻击行为。

原始的系统调用地址在内核编译阶段被指定，不会更改，通过比较原始的系统调用地址和当前内核态中的系统调用地址我们就可以发现系统调用有没有被更改。原始的系统调用地址在编译阶段被写入两个文件：a.System.map该文件包含所有的符号地址，系统调用也包含在内b.系统初始化时首先被读入内存的内核映像文件vmlinux-2.4.xvmlinux-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 :0xc01261a0 0xc011e1d0 0xc01078a0 0xc013fb70

0xc0302c40 : 0xc013fcb0 0xc013f0e0 0xc013f230 0xc011e5b0

0xc0302c50 : 0xc013f180 0xc014cb10 0xc014c670 0xc0107940

0xc0302c60 : 0xc013e620 0xc011f020 0xc014bcd0 0xc013e9a0

...

我们也可以通过系统调用名打印出系统调用的地址：

(gdb) x/x sys_ni_syscall

0xc01261a0 : 0xffffdab8

((gdb) x/x sys_fork

0xc01078a0 :　 0x8b10ec83

要打印出当前运行系统中的系统调用地址我们必须给gdb加两个参数：

a.第一个参数是内核映像文件vmliux-2.4.x

b.第二个参数是/proc/kcore二进制文件

#gdb /boot/vmlinux-2.4.* /proc/kcore

(gdb) x/255x 0xc0302c30

0xc0302c30 :0xc01261a00xc011e1d00xc01078a00xc88ab11a <<--

0xc0302c40 : 0xc013fcb00xc013f0e00xc013f2300xc011e5b0

0xc0302c50 : 0xc013f1800xc014cb100xc014c6700xc0107940

0xc0302c60 : 0xc013e6200xc011f0200xc014bcd00xc013e9a0

...

我们注意到第一行最后的0xc88ab11a这个地址明显不正常，这是系统调用号为3的系统调用，即sys_read (系统调用从0开始)

我们说它不正常的显著标志是它的地址高于0xc8xxxxxx，Linux默认4GB线性地址，其中最高1GB0x00000000-0xffffffff为内核保留，当一个模块被插入内核时，vmalloc函数为其分配一段地址空间，这个地址通常从0xc8800000开始...到这里已经很明显了吧?