Linux下的Rootkit驻留技术分析
|
如果我们的目标主机是git或svn服务器，有机会接触到项目源码的话，也可以通过修改目标的源码植入恶意代码，或者把编译环境动手脚，在项目构建时插入恶意代码，比如在configure脚本里或者Makefile里插入代码，既可以在本机运行，又有可能在编译之后在更多主机(取决于项目用途)上运行，进一步扩大感染范围。这个思路也是当年中国xcode事件黑客的思路。 1.5 动态链接库劫持 替换动态链接库 libc会被几乎所有的ELF调用，而特定的lib则会被特定的ELF调用，只要某个ELF的执行概率够高，我们同样可以用我们重新编译的恶意so替换掉它所链接的某个so文件，达到执行恶意代码的效果。 当然，以这种思路来看，替换掉整个libc也是未尝不可的。 下面以sshd的动态链接库为例，sshd使用的so文件如下：
libz.so.1看上去像是zlib的文件，可以验证一下：
那么我们可以去下载zlib源码，在可能会被调用的函数里加上我们的私货。 经过grep搜索openssh portable 7.9的源码，可以看到packet.c使用了zlib的函数：
确定了我们需要注入代码的函数，就可以去修改zlib源码了，在inflate.c的inflate函数里加入简单的system调用，来执行我们的evil程序：
完成修改之后我们make构建项目，然后用我们的恶意libz.so替换原本的文件。 此处修改的zlib，通常只会在ssh客户端指定了使用压缩时，才会被使用。所以我们需要使用ssh -C命令去测试。
提醒一点，作为动态链接库，它们的函数可能被频繁调用，我们在利用的时候要避免造成不必要的负载。另外，，由于大部分程序都是动态链接库文件，我们也需要格外小心，避免加入的代码调用的程序最终往回调用我们修改的库文件本身(尤其是在修改libc的时候)，造成死循环，导致系统停止响应。
最常见的实现是在/etc/ld.so.preload中写入我们需要让libc执行的so文件，或者设置LD_PRELOAD环境变量，这样，任何依赖系统libc的user space程序，都会在运行之前执行我们的so文件，从而实现了有效的rootkit驻留(鉴于几乎所有目标主 机都是动态编译的，几乎所有程序都要使用系统libc)。 下面我们编写一个简单的恶意so(shared object)作为说明： 这里的恶意so将编译为libevil.so。通常的lib都是为主程序提供库函数的，只有被调用的代码才会被执行，于是我们需要 解决的第一个问题是让我们的代码在lib被加载时直接自动运行。类似于Windows下的DllMain，gcc提供了function attributes，我们可以用形如__attribute__((constructor))的attribute来达到目的。对应的，__attribute__((destructor)) 则会在lib被unload的时候执行。 具体解释见官方文档：
我们使用如下代码构建libevil，这里有一个坑，execl函数只有出错时才返回，如果使用它执行了外部程序,那么在外部程 序执行完之后，libevil将会退出当前进程(也就是我们本来要执行的进程)，使任何ELF都无法正常执行。解决方法是使用 fork 函数创建子进程，在子进程里执行execl启动外部程序。
使用如下命令构建我们的 libevil.so：
设置LD_PRELOAD环境变量，使我们的libevil在ld执行任何ELF之前被执行。
需要注意的是，我们的libevil会在每个动态ELF执行之前被执行，如果在其中调用了外部的动态ELF，那个ELF执行时会再次调用libevil，就会造成死循环，使系统处于不可用状态。 我们也可以在libevil里实现rootkit的所有功能。 2. 内核态的驻留 传统的rootkit就是指这类恶意软件，对于Linux rootkit来说，最有效的方法就是把自己作为kernel module加载，因为大多数Linux目标都是允许动态加载kernel module的。 在kernel space里运行恶意代码的好处显而易见，由于大部分审计工具都在user space运行，管理员通常很难发现恶意软件的存在，这就带来了上面的方法所不能达到的隐蔽性。 2.1 LKM – 可加载内核模块 目前有一些开源的LKM (Loadable Kernel Modules) 木马demo，比较有代表性的是Reptile，它使用自己的kernel module实现了隐藏和驻留。 下面我们使用这个思路来实现一个简单的内核恶意代码执行： （编辑：晋中站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
