未加星标

Linux下的Rootkit驻留技术分析

字体大小 | |
[系统(linux) 所属分类 系统(linux) | 发布者 店小二03 | 时间 2018 | 作者 红领巾 ] 0人收藏点击收藏
前言

linux作为服务器和IoT设备使用的主要操作系统,针对它的恶意软件也层出不穷。针对Linux设备的恶意软件(以下称为rootkit)通常需要长期驻留于目标操作系统以达到获利目的,所以如何实现驻留也是Linux rootkit作者的重点考虑内容之一,对此,天融信阿尔法实验室进行了可能的思路探索和分析。

在接下来的说明中,我们统一使用一个名为evil的静态链接ELF文件作为我们要实现驻留的rootkit,所有的驻留尝试均围绕这个程序展开。

技术汇总 1. 用户态下的可利用点

1.1 各种init的利用

Linux init

在systemd成为主流之前,sysvinit是大多数发行版的选择,即使是Ubuntu之前使用的upstart,和sysvinit也是完全兼容的,直到今天,Debian系发行版仍保留sysvinit的兼容性。作为Linux的init程序,也就是PID 1,负责启动之后的所有进程,所有的服务都是由它管理,因此它是实现rootkit驻留的最常见手段。

对于传统的sysvinit,常见的驻留点都需要以root身份写入:

/etc/init.d
/etc/rc[runlevel].d
/etc/rc.local

其实sysv的服务文件就是遵循sysv规范的shell脚本,它在嵌入式设备中也很常见。给出一个sysv风格的服务文件如下:

#!/bin/sh
PATH=/bin:/usr/bin:/sbin:/usr/sbin
DESC="cron daemon"
NAME=cron
DAEMON=/usr/sbin/cron
PIDFILE=/var/run/crond.pid
SCRIPTNAME=/etc/init.d/"$NAME"
test -f $DAEMON || exit 0
. /lib/lsb/init-functions
[ -r /etc/default/cron ] && . /etc/default/cron
parse_environment() {
for ENV_FILE in /etc/environment /etc/default/locale; do
[ -r "$ENV_FILE" ] || continue
[ -s "$ENV_FILE" ] || continue
for var in LANG LANGUAGE LC_ALL LC_CTYPE; dovalue=$(egrep "^${var}=" "$ENV_FILE" | tail -n1 | cut -d= -f2)[ -n "$value" ] && eval export $var=$valueif [ -n "$value" ] && [ "$ENV_FILE" = /etc/environment ]; then log_warning_msg "/etc/environment has been deprecated for locale information; use /etc/default/locale for $var=$value instead"fi
done
done
# Get the timezone set.
if [ -z "$TZ" -a -e /etc/timezone ]; then
TZ=$(cat /etc/timezone)
fi
}
# Parse the system's environment
if [ "$READ_ENV" = "yes" ]; then
parse_environment
fi
case "$1" in
start)
log_daemon_msg "Starting periodic command scheduler" "cron" # 这一行是我们修改的目标
start_daemon -p $PIDFILE $DAEMON $EXTRA_OPTS
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping periodic command scheduler" "cron"
killproc -p $PIDFILE $DAEMON
RETVAL=$?
[ $RETVAL -eq 0 ] && [ -e "$PIDFILE" ] && rm -f $PIDFILE
log_end_msg $RETVAL
;;
restart)
log_daemon_msg "Restarting periodic command scheduler" "cron"
$0 stop
$0 start
;;
reload | force-reload)
log_daemon_msg "Reloading configuration files for periodic command scheduler" "cron"
# cron reloads automatically
log_end_msg 0
;;
status)
status_of_proc -p $PIDFILE $DAEMON $NAME && exit 0 || exit $?
;;
*)
log_action_msg "Usage: /etc/init.d/cron {start|stop|status|restart|reload|force-reload}"
exit 2
;;
esac
exit 0

我们在start case中做些修改,使之在启动时执行我们的evil程序:


Linux下的Rootkit驻留技术分析

对于systemd,我们可以用更多手段实现驻留,甚至不需要root权限也可以:

/etc/systemd/system
/etc/systemd/user
/lib/systemd/system
/lib/systemd/user
~/.local/share/systemd/user
~/.config/systemd/user

以下是一个利用systemd服务文件的示例:


Linux下的Rootkit驻留技术分析

systemctl --user enable service 可以使服务随用户登录启动, systemctl enable service 可以让服务随系统启动。

bashrc

bashrc或者zshrc等文件会随着shell的运行而被执行,利用时只需在里面加入恶意的shell script即可。

常见位置:

/etc/profile
~/.bashrc
~/.bash_profile
~/.bash_logout

示例如下:


Linux下的Rootkit驻留技术分析

xinitrc

如果目标主机有安装Xorg,我们也可以以下位置写入shell script实现rootkit驻留,不需要root权限。

~/.xinitrc
~/.xserverrc
/etc/X11/xinit/xinitrc
/etc/X11/xinit/xserverrc

其它initrc

任何应用程序都可能在启动时执行代码,而且它们很可能会执行用户home目录的rc文件。例如,我们甚至可以在vimrc里 写入vimscript来执行代码实现rookit的驻留,这同样不需要root权限。

一个可能的示例如下:


Linux下的Rootkit驻留技术分析

1.2 图形化环境的利用

虽然标准的服务器版Linux发行版是不会预装Xorg的,但还是存在相当一部分用户使用CentOS预装gnome2的版本作为服务器操 作系统。因此,基于gnome等桌面环境和Xorg的驻留有时候也是重要的而且会容易被忽略的手段。

XDG autostart for system

/etc/xdg/autostart下的desktop文件会被主流桌面环境在启动时执行。一个可能的示例如下:


Linux下的Rootkit驻留技术分析
XDG autostart for user

类似的,用户可以在自己的~/.config/autostart目录下加入需要自启动的desktop文件。

1.3 crond的利用

这是一个很常见的驻留点,但需要注意的是,很多恶意软件并不仅仅会把自己写入用户的crontab(如/var/spool/cron/root),它们会把自己写入软件包使用的crontab里面,如/etc/cron.d,这样更不容易引起用户注意。


Linux下的Rootkit驻留技术分析

1.4 替换文件

替换或者patch一些会被服务或用户本身执行的程序文件,以同时执行恶意代码,也是很常见的驻留方式。

我们可以方便的获取到开源项目的源码,进行修改,加上我们的恶意代码并重新编译,替换目标系统的相应文件。这样我们的代码就会随之执行。

下面我们修改openssh portable 7.9的源码,使之在特定条件下执行我们的代码:


Linux下的Rootkit驻留技术分析

这里修改的函数是uncompress_buffer,用于处理压缩传输的ssh连接。我们需要触发它的时候,只需发起一个ssh -C即可。


Linux下的Rootkit驻留技术分析

如果没有源码,我们同样可以给现有的binary注入shellcode,不过这种实现达到的功能相对有限,且可能会导致原文件损坏 。下面使用backdoor-factory进行shellcode注入,这个工具支持自定义shellcode:


Linux下的Rootkit驻留技术分析

如果我们的目标主机是git或svn服务器,有机会接触到项目源码的话,也可以通过修改目标的源码植入恶意代码,或者把编译环境动手脚,在项目构建时插入恶意代码,比如在configure脚本里或者Makefile里插入代码,既可以在本机运行,又有可能在编译之后在更多主机(取决于项目用途)上运行,进一步扩大感染范围。这个思路也是当年中国xcode事件黑客的思路。

1.5 动态链接库劫持

替换动态链接库

libc会被几乎所有的ELF调用,而特定的lib则会被特定的ELF调用,只要某个ELF的执行概率够高,我们同样可以用我们重新编译的恶意so替换掉它所链接的某个so文件,达到执行恶意代码的效果。

当然,以这种思路来看,替换掉整个libc也是未尝不可的。

下面以sshd的动态链接库为例,sshd使用的so文件如下:


Linux下的Rootkit驻留技术分析

libz.so.1看上去像是zlib的文件,可以验证一下:


Linux下的Rootkit驻留技术分析

那么我们可以去下载zlib源码,在可能会被调用的函数里加上我们的私货。

经过grep搜索openssh portable 7.9的源码,可以看到packet.c使用了zlib的函数:


Linux下的Rootkit驻留技术分析

确定了我们需要注入代码的函数,就可以去修改zlib源码了,在inflate.c的inflate函数里加入简单的system调用,来执行我们的evil程序:


Linux下的Rootkit驻留技术分析

完成修改之后我们make构建项目,然后用我们的恶意libz.so替换原本的文件。

此处修改的zlib,通常只会在ssh客户端指定了使用压缩时,才会被使用。所以我们需要使用ssh -C命令去测试。


Linux下的Rootkit驻留技术分析

提醒一点,作为动态链接库,它们的函数可能被频繁调用,我们在利用的时候要避免造成不必要的负载。另外,由于大部分程序都是动态链接库文件,我们也需要格外小心,避免加入的代码调用的程序最终往回调用我们修改的库文件本身(尤其是在修改libc的时候),造成死循环,导致系统停止响应。

ld.so.preload

最常见的实现是在/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的时候执行。

具体解释见官方文档:


Linux下的Rootkit驻留技术分析

我们使用如下代码构建libevil,这里有一个坑,execl函数只有出错时才返回,如果使用它执行了外部程序,那么在外部程 序执行完之后,libevil将会退出当前进程(也就是我们本来要执行的进程),使任何ELF都无法正常执行。解决方法是使用 fork 函数创建子进程,在子进程里执行execl启动外部程序。


Linux下的Rootkit驻留技术分析

使用如下命令构建我们的 libevil.so:

本文系统(linux)相关术语:linux系统 鸟哥的linux私房菜 linux命令大全 linux操作系统

代码区博客精选文章
分页:12
转载请注明
本文标题:Linux下的Rootkit驻留技术分析
本站链接:https://www.codesec.net/view/610822.html


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(linux) | 评论(0) | 阅读(64)