巧用 iLocker 清理恶意程序

iLocker 作为 iGuard 网页防篡改系统的文件驱动过滤模块所衍生出来的独立应用,是一个文件防护工具,可以在文件系统驱动层检查文件操作,根据规则对文件操作进行放行或拦截,可以灵活细致地对文件访问进行控制。

分享一则 iLocker 在实际运用中的案例,帮助大家拓展 iLocker 的运用思路——

起因

和许多突发事件一样,本次案例也发生在状况高发期——半夜。

工程师小张反馈服务器有不明程序在运行,判断不出程序的运行意图不说,它甚至还吃掉了100%的 CPU。小张尝试 kill 掉这个不明进程,却每次都会有新的进程杀出来,名字不尽相同,都是无规则的一串字母,好不烦人。

根据小张所述,并没有什么头绪,只有在程序里找线索了。

首先要厘清服务器(Linux)上的进程状态。 top 命令一看,确实有个符合上述特征的奇怪进程在吃 CPU。

尝试重现小张所说情况: kill-9 可以杀掉,再 top 一看,又出来一个进程,名字变了,但换汤不换药。

pic

观察

依照常规,用 ps-ef|grep 检测发现,如下图,7769,分明是同一个进程 ID。 top 所显示的进程名和 ps 得到的结果并不一样。这一项问题姑且不论,检查后还发现, ps 命令没有被替换,程序还没有感染整个系统。可以用 lsof 进一步查看此进程,发现程序文件在 /usr/bin/ 下。

pic

可以尝试再 kill 一次进程。

虽然如意料之中,得到和最初一样的结果,但再运行一次 ps 命令,我们有了新发现:不止7769一个进程,还暴露出一长串异常进程。

pic

总结一下这次的问题:在同一时间点上,多个不该运行的命令在运行,比如 route-ngrep"A" ,甚至还有 echo"find" 这样的命令,十分反常。不仅如此,这些命令变化大量且迅速,每个进程短暂运行数秒即消失,新命令进程也在不断生成。

至此,这次异常状况的形态已初露端倪,100%占用 CPU 的进程可以断定是核心工作进程,其他变化多端的闪现进程则充当保护肉盾,用来保护真正的工作进程不被杀死删除。棘手的,便是这些周而复始,阴魂不散的保护进程了。

当然,经验丰富的我方安全战斗人员,一线作战经验丰富,如果排查出问题所在,解决方案也当即应运而生。

shell 提示新邮件,查看一下,或许是个不错的切入点哦!

pic

不要错过任何一个线索——

pic

草蛇灰线,掩藏得再好,蛛丝马迹还是被找到了!

pic

脚本意图明显,功能简单明了:

  1. 使用 ifconfig 命令启动所有网卡
  2. 复制 /lib/libudev.so/lib/libudev.so.6
  3. 启动 /lib/libudev.so.6

可以看出

  • crontab 发出了提醒邮件,是因为系统没有 ifconfig 命令,脚本报错了。
  • 脚本启动的是 /lib/libudev.so.6 ,看起来这个文件比较关键。

先尝试删除 /lib/libudev.so.6 ,rm 命令执行成功。但是再次 ls 的时候,它又出现了。猜测是那些奇怪的进程在维护这个 /lib/libudev.so.6 不被清理。

思路变得简单了:

  • 怎么知道它都把文件复制到哪里去了呢?
  • 怎么找到并杀死那些不停闪现的进程呢?
  • 怎么阻止它复制自己呢?

手段

iLocker 大显身手的时候到了。

iLocker 可以保护文件或目录不被篡改,不但能阻止文件创建,还能发现恶意程序操作了哪些文件。无需多言,iLocker 配置起来。

配置前,有如下几点考虑:

  • 恶意程序的可执行文件,在 /usr/bin 下面,需要把 /usr/bin 保护起来;
  • 定时脚本里的恶意程序路径在 /lib/libudev.so ,所以也把 /lib 也保护起来;
  • /tmp 目录也比较特别,也需要特别关注一下;
  • 我自己要删除 /lib/libudev.so ,所以先要把自己放开;
  • 发现系统的 /lib 目录实际上是个软链接 /usr/lib ,故而实际保护
    /usr/lib 目录。

简单解释下 iLocker 的规则:

#uid=0,exe_path=*,cmdline=*,operation=MKDIR,file_path=/tmp/test/pass/*,action=pass
#uid=*,exe_path=*,cmdline=*,operation=*,file_path=/tmp/test/*,action=deny

一条规则包含以下信息,根据这些信息 iLocker 可以捕获任意一个文件操作,并对其进行拦截或记录:

  • 用户 uid ,进程所属的用户 ID;
  • 可执行文件的路径 exe_path
  • 进程的命令行参数 cmdline ,常用来区分同一个程序的不同进程,比如 java ,python ,shell 等;
  • 具体的文件操作 operation (如 CREATE ,OPEN , MKDIR 等);
  • 被操作的文件路径 file_path
  • iLocker 的响应动作 action (pass ,deny ,log)等。

根据观察现象过程中搜集到的信息,在 iLocker 中写入如下配置——

exe_path=/usr/bin/rm,file_path=/usr/lib/*,action=pass
file_path=/usr/bin/*,action=deny
file_path=/usr/lib/*,action=deny
file_path=/tmp/*,action=deny

启动 iLocker ,并打开 iLocker 日志管理器,发现瞬时增加很多新日志,浏览下来,几乎都是恶意程序在写文件。如下:

2019-03-15 5:42:12,CREATE,0,14840,/usr/bin/irjsypzavm,/usr/bin/szklfovzwg,,deny
2019-03-15 15:42:12,CREATE,0,14840,/usr/bin/irjsypzavm,/tmp/szklfovzwg,,deny
2019-03-15 5:42:17,CREATE,0,14848,/usr/bin/irjsypzavm,/usr/lib/libudev.so,,deny
2019-03-15 5:42:18,CREATE,0,14848,/usr/bin/irjsypzavm,/usr/lib/libudev.so,,deny

例如其中第3条日志:

用户 ID=0 ,进程 ID=14848 ,
进程文件为 /usr/bin/irjsypzavm ,
想 CREATE 文件 /usr/lib/libudev.so ,被拦截了。

之前的假设得到了证实——程序在不停地复制自己。

同时,我们也找到了恶意程序自我复制的路径: /usr/bin 或 /tmp/ 下,文件名随机,复制到 /usr/lib/libudev.so 是固定的文件名。

解决

一波操作之后,终于可以痛下杀手,斩草除根了:

  • 再次 kill 掉100% CPU 的进程
  • rm /lib/libudev.so
  • 清理留下的恶意文件,清理crontab

如上所述,这些程序每次完成自我复制,就相应拉起一些新的进程,自己退出。

这次,且不用劳神一个一个找出这些进程:iLocker 运行,进程不再复制成功,自己退出。没复制成功,也就意味着不再拉起新的进程。

iLocker 出马,恶意进程原地自闭了!本局,安全团队借助 iLocker 轻松实现全垒打!

案例总结

该案例下,服务器只开了一个 ssh 服务和一个只提供静态页面的 web 服务,系统是最新的,还打了补丁,看起来无懈可击……

但是!

一个没有“但是”做ending的案例是不完美的!

……

返回去查看系统登录日志,发现了大量失败的登录记录,回想起最初工程师小张提供的登录信息,root 、弱密码…没错,弱密码被暴力猜解了!

安全是个整体
哪里都要注意
弱密码要慎用!

(陈国 | 天存信息)

posted @ 2021-06-02 15:44  天存信息  阅读(70)  评论(0编辑  收藏  举报