Linux下用gdb检测内核rootkit

导读：
　　本文涉及的技术原理都不是新的,对研究人员没什么特别大的价值,
　　不过对工程人员应急相应来说不失为一种新的方法.
　　【理解攻击向量】
　　前面两段废话直接掠过...实在浪费感情-_-!
　　内核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中的排列顺序，按系统调用号递增。
　　-_-！鉴于原文废话很多，我就跳着翻译或者概括起来翻译，有兴趣的可以找本Linux内核的书看看(e.g:ULK2)
　　在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 :　　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 :　　0xc01261a0　　0xc011e1d0　　0xc01078a0　　0xc88ab11a <<--
　　0xc0302c40 　　0xc0302c50 : 0xc013f180　　0xc014cb10　　0xc014c670　　0xc0107940
　　0xc0302c60 : 0xc013e620　　0xc011f020　　0xc014bcd0　　0xc013e9a0
　　...
　　我们注意到第一行最后的0xc88ab11a这个地址明显不正常，这是系统调用号为3的系统调用，即
　　sys_read (系统调用从0开始)
　　我们说它不正常的显著标志是它的地址高于0xc8xxxxxx，Linux默认4GB线性地址，其中最高1GB
　　0x00000000-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 :　　　　　　　　 mov　　 $0xc88ab0a6,%ecx
　　0xc013fb73 :　　　　　　　 jmp　　 *%ecx　　　　　　　<<--
　　0xc013fb77 />:　　　　　　　
　　0xc013fb7b :　　　　　　　mov　　 %edi,0x20(%esp,1)
　　0xc013fb7f :　　　　　　　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 :　　　　　　　　sub　　 $0x28,%esp
　　0xc013fb73 :　　　　　　　mov　　 0x2c(%esp,1),%eax
　　0xc013fb77 :　　　　　　　mov　　 %esi,0x1c(%esp,1)
　　0xc013fb7b :　　　　　　 mov　　 %edi,0x20(%esp,1)
　　0xc013fb7f :　　　　　　 mov　　 $0xfffffff7,%edi
　　...
　　看到了吧，不一样的。
　　【更改系统调用处理例程】
　　入侵者可能修改一些重要的内核函数，比如系统调用处理例程system_call函数，顾名思义，这个函数
　　对用户请求的系统调用作出响应，在系统调用表中寻找对应的入口地址，然后跳转到那里执行，这个函数
　　中保存了系统调用表的地址。攻击者能做什么呢？另辟一块内存空间，在那里攻击者伪造自己的系统调用
　　表，然后修改system_call函数中的系统调用表地址指向那里就可以了。
　　通过反汇编system_call函数可以找出系统调用表的地址：
　　(gdb) disass system_call
　　Dump of assembler code for function system_call:
　　0xc01090dc :　　　　push　　%eax
　　0xc01090dd :　　　cld
　　0xc01090de :　　　push　　%es
　　0xc01090df :　　　push　　%ds
　　0xc01090e0 :　　　push　　%eax
　　0xc01090e1 :　　　push　　%ebp
　　0xc01090e2 :　　　push　　%edi
　　0xc01090e3 :　　　push　　%esi
　　0xc01090e4 :　　　push　　%edx
　　0xc01090e5 :　　　push　　%ecx
　　0xc01090e6 :　　 push　　%ebx
　　0xc01090e7 :　　 mov　　 $0x18,%edx
　　0xc01090ec :　　 mov　　 %edx,%ds
　　0xc01090ee :　　 mov　　 %edx,%es
　　0xc01090f0 :　　 mov　　 $0xffffe000,%ebx
　　0xc01090f5 :　　 and　　 %esp,%ebx
　　0xc01090f7 :　　 testb　 $0x2,0x18(%ebx)
　　0xc01090fb :　　 jne　　 0xc010915c
　　0xc01090fd :　　 cmp　　 $0x100,%eax
　　0xc0109102 :　　 jae　　 0xc0109189
　　0xc0109108 :　　 call　　*0xc0302c30 (,%eax,4)　 <<--系统调用表地址
　　0xc010910f />:　　
　　0xc0109113 :　　 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在phrack 60上的module_hunter.c，有2.4和2.6的版本，grip2、coolq对其做了一
　　些修改，并且该代码不断完善中，另外偶还从jbtzhm那儿挖了点东西，~_~
　　------
　　Ph4nt0m Security Team
　　http://www.ph4nt0m.org
　　一群Open &&Free的年轻人，虽然大多从事网络安全工作，却因为崇尚Black Hat而聚到一起。
:　　>:　　　　　　　>