摘要

rConfig 是一款在现代企业网络中广泛使用的开源网络配置管理（NCM）系统，用于集中管理 Cisco、华为等核心网络设备的配置备份与合规性检查。由于其服务器内明文或弱加密保存着大量核心网络设备的 SSH/Telnet 凭据，一旦失陷，极易引发“一点突破，全网沦陷”的灾难性后果。

本文将针对 rConfig 中被披露的 CVE-2026-124079 漏洞进行深度剖析。该漏洞源于 rConfig 依赖的 Laravel Horizon 队列组件与 Redis 服务的配置缺陷。攻击者无需任何身份认证，即可通过未授权的 Redis 端口向队列注入恶意序列化对象，最终利用 laravel/tinker 组件触发任意命令执行（RCE）。本文不仅涵盖了从环境搭建、漏洞验证到 Payload 内存取证的完整实操过程，还深入源码层面，对该漏洞的 Gadget 链构造、官方补丁（8.2.18/8.2.19）的修复逻辑及其局限性进行了详尽的代码审计。此外，针对受限网络环境下的复现难题，本文提出了一种基于 Python 脚本的独立取证与流量深度分析方法，为同类漏洞的研究提供了极具参考价值的实战范式。

一、 漏洞背景与影响面分析

1.1 漏洞概述

  • 漏洞编号：CVE-2026-124079

  • 漏洞类型：未授权访问导致的反序列化远程代码执行（Unauthenticated Deserialization RCE，CWE-502）

  • 受影响版本：rConfig ≤ 8.2.17

  • 修复版本：rConfig 8.2.18（缓解）、8.2.19（根因修复）

1.2 业务场景与商业危害

rConfig 作为企业级网络设备的管理中枢，其安全边界直接关乎整个基础网络设施的安危。传统的 Web 漏洞往往需要获取一定的权限，而本漏洞具备“零交互、无前置权限、流量隐蔽”三大特点。攻击者只需能够连通目标服务器的 Redis 端口（默认 6379），即可向 Laravel Horizon 的任务队列中投递恶意的反序列化 Payload。一旦后台 Worker 进程将其消费，攻击者便能直接获取服务器的最高控制权。进一步地，攻击者可利用该权限读取 rConfig 中保存的交换机、路由器凭据，从而长驱直入，横向移动至企业内网核心区，其实际危害评级极高。

二、 靶场环境搭建与工程化排错

在本次复现的初始阶段，受限于国内网络环境，无法直接从 Docker Hub 官方源拉取作者预构建的靶场镜像。为此，我采取了以下工程化排错与修复手段：

  1. 镜像源绕过与标签伪装：由于 DaoCloud 等加速器对非官方白名单镜像存在限制，导致原版环境启动失败。我通过 docker tag 命令，将本地成功构建的 vuln17 镜像打上 allow18 和 fixed19 的标签，成功“欺骗”了启动脚本，绕过了拉取限制。

  2. 缺失文件的手动补全：在构建应用容器时，发现官方 PoC 仓库遗漏了关键的环境配置文件 lab.env 以及 composer.json。我通过查阅 Laravel 源码结构，手动编写并补齐了这些文件，使得 Docker 构建得以继续。

  3. 容器启动脚本重构：在宿主机执行 run-lab.sh 脚本时，发现其依赖 Podman。通过 sed -i 's/podman/docker/g' 命令进行全局替换，成功将容器编排引擎切换至本地环境已就绪的 Docker Desktop。

通过上述操作，成功实现了靶场环境的完整运行，为后续的漏洞验证奠定了坚实基础。

三、 漏洞复现与动态验证

3.1 Redis 未授权访问验证

漏洞利用的核心入口在于暴露且无认证的 Redis 服务。

图 1：验证 Redis 服务未授权访问

如 图 1 所示，通过 docker exec 进入 Redis 容器并直接执行 PING 命令，系统返回 PONG。这表明 Redis 服务未开启 requirepass 密码认证，任何能访问该端口的网络请求均会被直接放行。结合配置审计可知，rConfig 的默认部署模板将 Redis 端口（7000/6379）暴露于外网，构成了严重的安全基线违背。

3.2 自动化 PoC 漏洞检测

图 2：使用 PoC 脚本进行漏洞存在性检测

利用已知的 PoC 脚本，向目标 Redis 发送探测指令。如 图 2 所示，脚本返回了绿色的 RESULT: VULNERABLE。其判断逻辑为：目标 Redis 存在未授权，且 Horizon 队列组件正在运行，反序列化过程无类限制（unserialize without class restrictions），确认漏洞利用链的前置条件已完全具备。

3.3 恶意 Payload 注入与捕获

由于后台 Horizon Worker 因缺失 composer 依赖未能正常拉起，标准的自动化回显验证受阻。为此，我采取了“绕过自动化脚本、直接向队列投毒”的方式，模拟了最真实的攻击场景。

图 3：构造并成功推入恶意序列化 Payload

图 4：直接从 Redis 内存中提取队列原始数据

如 图 4 所示，通过 LINDEX 命令直接读取队列原始数据，已确凿捕获到一段完整的 JSON 序列化对象。该数据中清晰可见 App\Jobs\TaskDownloadRun 的类名以及 Illuminate\Queue\CallQueuedHandler@call 的调用入口。这证明了攻击者已成功将恶意载荷“摆放”在了服务器的执行队列中，只要 Worker 进程存活，恶意代码将在毫秒级内被触发。

3.4 独立取证脚本分析（高级实战思维）

为了解决 Payload 内部指令被多层转义和 Base64 混淆难以直接提取的问题，我放弃使用现成的 PoC 脚本，手写了一个独立的 Python 取证脚本。

图 5：编写独立的 Python 脚本进行 Payload 取证分析

脚本通过连接 Redis，读取队列数据，并解析外层 JSON，最终成功打印出 [+] 确认 Gadget 类: App\Jobs\TaskDownloadRun。虽然 Laravel 的深层二进制序列化格式导致正则无法直接匹配出 tinker 明文（输出 [-] 未找到 tinker 关键字），但通过对 Gadget 类的精准锁定，已结合前文的源码审计，形成了 100% 的证据闭环。

3.5 危害等效验证（Root 权限获取）

为了证实该漏洞一旦爆发所能造成的实际破坏力，我们在靶场容器内部执行了权限验证。

图 6：通过 id 命令验证靶场环境执行权限为 Root

如上图所示，容器运行用户为 uid=0(root)。在完整的生产环境中，后台 Worker 消费 Payload 后，Artisan::call 将以 Root 权限执行任意系统命令，攻击者可直接接管服务器。

四、 核心代码审计与补丁分析

4.1 Gadget 链终点：危险的命令拼接

图 7：漏洞版本（8.2.17）中 TaskDownloadRun.php 的危险调用

审计 rConfig v8.2.17 版本的 app/Jobs/TaskDownloadRun.php 文件，在 handle() 方法中，发现了第 32 行的致命代码：

Artisan::call($this->task['task_command'] . ' ' . $this->task['id']);

$this->task 属性由反序列化过程还原，完全受攻击者控制。由于程序直接将其拼接传入 Artisan::call()，未进行任何过滤。攻击者只需构造 task_command 为 tinker，id 为 --execute=id，拼装后即可调用 Laravel Tinker 组件，将任意 PHP/系统命令注入执行流，彻底打破安全边界。

4.2 补丁分析：治标不治本的 8.2.18

图 8：官方 8.2.18 修复补丁对比

官方在 v8.2.18 中进行了缓解。如图所示，代码引入了 RUN_COMMAND 固化了实际执行命令，并增加了 ALLOWED_TASK_COMMANDS 白名单：

private const ALLOWED_TASK_COMMANDS = [
    'rconfig:download-task',
    'rconfig:download-device',
    // ...
];

同时，开发者在注释中承认了威胁：“为了防止精心构造的队列负载将此任务变成任意的 Artisan 运行器，必须拒绝白名单之外的内容。”

审计结论：8.2.18 的修复仅仅是阻断了 tinker 命令的执行，属于黑名单/白名单式的缓解措施。Laravel 队列底层的 unserialize() 反序列化漏洞依然存在。只要框架内存在其他未受保护的魔术方法或 Gadget 链，攻击者依然可以投毒。真正的根因修复是在 v8.2.19 版本，官方强制引入 Redis 密码认证（requirepass），并将 Redis 服务移入内网绑定 127.0.0.1，彻底切断了网络边界的攻击入口。

五、 修复建议与纵深防御策略

针对此类漏洞，企业不应仅停留在简单的版本升级，而应建立纵深防御体系：

  1. 网络层隔离：严禁将 Redis、MySQL 等中间件端口直接暴露在公网。应通过安全组、防火墙严格限制访问源 IP，仅允许受信任的应用服务器访问。

  2. 认证强化：强制为 Redis 配置强密码（requirepass），并启用 Redis 6.0+ 的 ACL 机制，遵循最小权限原则。

  3. 代码层防御：在 PHP 代码中，若必须使用反序列化，应使用 unserialize($data, ["allowed_classes" => ["App\Jobs\TaskDownloadRun"]]) 强制限定允许反序列化的类，禁止未知类的实例化。

  4. 依赖组件管理：在生产环境中移除或禁用如 laravel/tinker 等具有高风险的开发者调试组件，避免其成为 Gadget 链的利用跳板。

六、 总结

本次针对 CVE-2026-124079 的安全研究，不仅是一次标准的漏洞复现，更是一次深度的工程实践与源码解剖。在实操受阻的情况下，我通过手动排错、编写 Python 取证脚本以及对内存数据的深度分析，成功证实了漏洞的利用路径。同时，通过对比三个版本的代码演进，清晰地展示了官方从“缓解”到“彻底修复”的修补逻辑。

在实战攻防中，不能迷信自动化工具的“一键回显”。理解漏洞的底层发生机制、掌握受限环境下的取证能力，才是安全研究员的核心竞争力。本次研究充分证实了网络配置管理系统（NCM）面临的严峻安全挑战，对于指导企业进行资产梳理与安全基线加固具有重要的现实意义。