Linux下基于内存分析的Rootkit检测方法- 路人甲.PDFVIP

原原文文地地址址:/tips/4731 0x00 引引言言 某Linux服务器发现异常现象如下图，确定被植入Rootkit，但运维人员使用常 Rootkit检测方法无效，对此情况我们还可以做什么？ 图1 被植入Rootkit的Linux服务器 所有暗链的html文件ls均看不到。 使用ls -al 绝对路径，能看到，但无法删除。 这些暗链的uid和gid都很奇特 分别为 2511744398:4043361279 。 对任意文件执行chown 2511744398:4043361279 其表现会和暗链文件相同。 将硬盘n s挂载到正常系统上，现象无任何变化。 0x01 Rootkit实实现现方方式式和和检检测测方方法法 一般来说，Rootkit检测方式有以下几种： 1. 可信任Shell——使用静态编译的二进制文件：lsof、stat、strace、last、…… 2. 检测工具和脚本：rkhunter, chkrootkit, OSSEC 3. LiveCD——DEFT、Secon Look、 Helix 4. 动态分析和调试：使用g b根据System.map和vmlinuz image分析/proc/kcore 5. 直接调试裸设备： ebugFS 在分析这几种检测方法的优劣之前，我们先通过图2了解一下Linux Rootkit的一般实现原理 图2 Linux中系统命令执行的一般流程 在Ring3层 （用户空间）工作的系统命令/应用程序实现某些基础功能时会调用系统.so文件注1。而这些.so文件实现的基本功能，如文件读写则是通过读取Ring0层 （内核空间）的Syscall Table注 2(系统调用表)中相应Syscall(系统调用)作用到硬件，最终完成文件读写的。 那么如果中了Rootkit，这个流程会发生什么变化呢？下面通过图3来了解一下。 图3 Rootkit的一般执行流程 Rootkit篡改了Syscall Table中Syscall的内存地址，导致程序读取修改过的Syscall地址而执行了恶意的函数从而实现其特殊功能和目的。 上图仅仅是列举了一种典型的Rootkit工作流程，通过修改程序读取Syscall的不同环节可以产生不同类型的Rootkit，我们简单罗列一下。 Rootkit部分实现方式： 1. 拦截中断-重定向sys_call_table，修改IDT 2. 劫持系统调用-修改sys_call_table 3. inline hook-修改sys_call，插入jmp指令 这部分不是本文的重点，不再赘述。了解了Rootkit实现原理，我们再回过来对比一下常 Rootkit检测方式的优劣。 对于使用静态编译的二进制文件的检测方式，如果Rootkit修改了Syscall，那么这种方法产生的输出也是不可靠的，我们无法看到任何被Rootkit隐藏的东西。 那么如果使用Rootkit检测工具呢，我们简单分析一下rkhunter的检测原理。 在rkhunter脚本文件中，scanrootkit函数部分代码如下： 图4 rkhunter中的scanrootkit函数 注：其安装脚本中定义了以下两个变量 #!bash RKHTMPVAR=${RKHINST_SIG_DIR} RKHINST_SIG_DIR=${RKHINST_DB_DIR}/signatures 图5 Signatures 目录中的文件列表——Rootkit签名列表 从上面这段代码我们可以看出rkhunter扫描Rootkit调用了3个重要的变量：SCAN_FILES, SCAN_DIRS，SCAN_KSYMS，用于每种Rootkit的检查。 下面的四幅图分别是Adore和KBeast两个Rootkit检测的具体代码。 图6 rkhunter中经典Rootkit Adore的检测流程 图7 rkhunter中检测Adore的文件和目录的清单 图8 rkhunter中Rootkit KBeast的检测流程 图9 rkhunter中检测KBeast的文件和目录的清单 根据以上分析，我们可以看出rkhunter仅仅是检查已知Rootkit组件默认安装路径上是否存在相应文件，并比对文件签名 （signature）。这种检测方式显然过于粗糙，对修改过的/新的Rootkit基本 无能为力。 而另一款流行的Rootkit检测工具chkrootkit，其LKM Rootkit检测模块源文件为chkproc.c，最后更新日期为2006.1.11日。检测原理与rkhunter大致相似，也主要基于签名检测并将ps命令的输出 同/proc 目录作比对。在它的FA