服务器挖矿病毒排查记录

2024-03-29

起因

事情的起因是前段时间,郭佬找到我说他们的实验室新配了一台 AI 服务器,不过在外地托管,问有没有什么远程 ssh 的方法,于是我给他推荐了内网穿透和 P2P 组网两种方案,并对比了两者的优劣,最终郭佬选择了内网穿透方案,当时特意嘱咐了郭佬,服务器密码千万别使用弱密码,否则可能会被别人扫描爆破,最好是直接关掉密码登录,只通过密钥登录。

2024-08-24-slqiiivi.jpg
2024-08-24-uqpxapmk.jpg

过了几天郭佬找到我,说服务器被入侵了,有几个非 Python 进程一直占用着显存。

2024-08-24-usratgza.jpg
2024-08-24-hkjayoba.png

图中可以看到有一个名为 /etc/system 的进程在每张显卡上都有占用显存,根据直觉,这个大概率就是挖矿病毒了,因为正常情况下 etc 目录是存放配置文件的,不排除有一些可执行的脚本,但是肯定不会有可执行的二进制程序,而且入侵者还起了个 system 这么迷惑性的名称,让受害者误以为是系统组件。

又过了一会,郭佬说进程杀不死,杀掉以后又自动重启了,于是我登上了服务器,准备排查一下。

初步排查

首先尝试使用 ps 查看了一下进程信息,看一下是谁启动的病毒进程,发现进程 PPID 是 1,在 Linux 中 PID 为 1 的进程为 systemd,主要用于管理系统服务,配置守护进程等功能,这里之所以杀不死病毒进程,大概率是配置了 Restart 策略。

接下来我查看了一下 systemd 配置文件里有哪些可疑的服务项

ls /etc/systemd/system/*service

2024-08-24-lrxynjtt.png

稍微有一点多,懒得一个个看内容了,一般情况下 service 配置文件中都会使用 ExecStart 指定程序的执行路径,于是我把病毒文件改了个名字,重启系统以后,病毒果然没有启动,于是就先把病毒文件删掉了。

这里因为改了病毒文件名称,导致其没有正常启动,在系统日志中肯定有报错,于是继续排查一下日志记录

journalctl | grep "/etc/system"

2024-08-24-knxwpsaf.png

这里日志中可以看到是又一个名为 k8s.service 的服务产生的报错,看到这里忽然恍然大悟,郭佬这台服务器是拿来跑 AI 的,怎么可能会安装 k8s,这又是入侵者的一个小把戏。

看一下 service 内容

cat /etc/systemd/system/k8s.service

2024-08-24-vgifwelv.png

看到了罪魁祸首 ExecStart=/etc/system ,于是把这个 service 文件删除。

做到这里病毒应该就解决掉了,不过不排除还留有其他后门,于是就让郭佬先观察几天,同时嘱咐郭佬换一个强度高一点的密码,或者去改一下配置文件,禁用密码登录。

再次排查

过了一会,郭佬再次找到我,说 /etc/ssh/sshd_config 文件一直改不了。

2024-08-24-wlyrbmsv.png

我想是不是权限问题,没有用 sudo 或者 root 用户没有写权限,郭佬告诉我用的 root 用户操作的,而且看了一下权限,是正常的 644

2024-08-24-vmhdqcva.png

这里我想到了可能是入侵者改了这个文件的属性,设置了 immutable 权限,被设置了 immutable 权限的文件不能被修改、不能被删除,于是让郭佬试一下用 chattr 改一下权限,但是没有成功,执行后返回了 chattr 的 usage

2024-08-24-sznzwejf.png

于是我再次登录了服务器,排查一下原因,为了方便登录,我想先把我的公钥加到服务器里,结果编辑 /root/.ssh/authorized_keys 后发现是同样的问题,而且文件里已经有一个公钥了,我问了一下郭佬之前有没有添加过公钥,郭佬说没有,那么,这个公钥应该就是入侵者留的后门了。

当尝试使用 lsattr 命令查看一下权限,发现一样是返回 Usage,网上搜了下资料,发现是 lsattr 和 chattr 被入侵者替换了,而且这两个命令也被设置了 immutable 属性。

这里参考了 阿里云服务器 chattr 文件被删问题 的方法。

# 下载chattr源码
wget https://raw.githubusercontent.com/posborne/linux-programming-interface-exercises/a93a73842cac2143c873d78a30df5f8f32f5dab8/15-file-attributes/chattr.c
# 编译
cc chattr.c
# 重命名
mv a.out chattr
# 修改权限
chattr -i /etc/ssh/sshd_config
chattr -i /root/.ssh/authorized_keys
chattr -i /usr/bin/chattr
chattr -i /usr/bin/lsattr
# 重装chattr
apt install --reinstall e2fsprogs

至此,后门问题也是基本上解决了。

通过此事也说明了任何处于公网的设备都有被入侵的风险,以下是一些防护措施

  1. 不要使用弱密码,尽可能使用包含数字、字母、符号多个组合的高强度密码

  2. 尽量不要使用 ssh 默认的 22 端口

  3. 禁用 ssh 密码登录,改为使用密钥、F2A 等认证方式

  4. 编写脚本,屏蔽高频 ssh 登录的 IP