CVE-2023-46805 + CVE-2024-21887: Ivanti Connect Secure 未授权 RCE 漏洞链分析

CVE-2023-46805 + CVE-2024-21887: Ivanti Connect Secure 未授权 RCE 漏洞链分析

CVE-2023-46805 与 CVE-2024-21887 是 2024 年最具代表性的边界设备漏洞链之一。前者是认证绕过，后者是命令注入，两者组合后会把原本需要登录才能触达的管理面命令执行，降级成未授权远程代码执行。

这条链的破坏力很高，原因不只是“设备上能执行命令”，而是目标本身就是企业远程接入与身份边界的核心节点。一旦失陷，攻击者往往能进一步：

  • 窃取 VPN 配置与凭据
  • 导出证书、密钥与会话材料
  • 篡改合法组件植入后门
  • 建立隧道与横向进入内网
  • 通过补丁欺骗、完整性检查绕过和持久化长期保留访问

文章以公开权威资料为基础，偏重研究与防守视角，不提供可直接攻击公网目标的一键利用代码。

0x01 漏洞背景与影响范围

1. 这不是两个孤立漏洞，而是一条完整的未授权 RCE 链

CVE-2023-46805 的本质是访问控制被绕过，攻击者可以在未完成正常认证流程的情况下进入原本受限的接口；CVE-2024-21887 则允许在这些受限接口中进一步触发命令注入。

组合后，利用路径可以抽象为：

未授权访问 -> 绕过认证 -> 调用受限管理接口 -> 命令注入 -> 设备级远程代码执行

2. 受影响产品

Ivanti 官方最初确认受影响的主要是：

  • Ivanti Connect Secure
  • Ivanti Policy Secure

后续公告中还提到：

  • Ivanti Neurons for ZTA Gateway

但需要注意，ZTA Gateway 的风险边界和生产环境部署方式有关。官方说明中提到，那些已经生成但尚未连接到 ZTA controller 的网关更值得重点排查。

3. 影响版本

官方初始结论非常激进，基本可理解为：

  • ICS/PS 所有受支持的 9.x
  • ICS/PS 所有受支持的 22.x

都在影响范围内，后续再按不同产品线分批发布补丁。

这类表述本身就说明一个现实问题：攻击面不是出现在某个冷门支线，而是直接命中了仍在广泛部署的远程接入平台主分支。

4. 在野利用时间线

这条链最危险的地方之一，在于公开披露时已经不是“可能会被利用”，而是明确存在在野攻击：

  • 研究与响应方把最早利用时间追溯到 2023-12-03
  • 2024-01-10 开始大规模公开披露
  • 2024-01-16 左右公开 PoC 出现后，全球扫描与批量利用显著上升

这也是为什么后续处置不应只围绕“补丁是否装上”，而要转向“设备是否已经被深度入侵”。

0x02 漏洞原理

1. 认证绕过：把原本受保护的接口直接暴露给未授权请求

CVE-2023-46805 的关键不在于“猜中密码”或“窃取令牌”，而在于 Web 组件对访问控制的检查存在缺陷。公开研究普遍认为，攻击者可以通过构造特定 URI 或路径样式，绕过原本用于限制未授权访问的控制逻辑。

这意味着某些本应只对已登录管理员或已认证用户开放的功能入口，会在攻击者完全未登录的情况下暴露出来。

2. 命令注入：把管理功能进一步升级成系统命令执行

CVE-2024-21887 则发生在多个 Web 组件对系统命令的封装调用链中。攻击者一旦能够触达这些接口，就可能通过参数污染、命令拼接或不安全调用方式，把输入升级为系统命令执行。

从工程视角看，这类漏洞的典型危险点是：

  • 接口本身是高权限管理能力
  • 输入参数最终进入 shell 或系统命令
  • 访问控制与参数处理都依赖“调用者已可信”的前提

当 46805 先把“可信调用者”这层假设拆掉后，21887 就会从“需认证命令注入”变成“未认证 RCE”。

3. 本质不是单点 bug，而是控制面信任链断裂

这条链之所以典型，是因为它不是单个接口上的简单命令注入，而是两类问题叠加：

  1. Web 控制面错误地让未授权请求触达到受限 API
  2. 受限 API 又错误地把外部输入带入高权限命令执行链

这种“权限边界被绕过 + 高权限功能缺乏输入安全”的组合，是很多边界设备重大 0day 的共同模式。

4. 本质总结

可以把这条链概括为：

访问控制缺陷 + 高权限管理接口命令注入 = 未授权 RCE

而且它发生在 VPN/远程接入设备上，决定了后续影响远大于一台普通 Web 服务器。

0x03 利用路径与攻击链

1. 先打通未授权访问入口

攻击者首先利用 CVE-2023-46805 命中受限接口，使设备错误地把本应要求认证的请求当作可访问操作处理。

2. 再把高权限管理接口转为命令执行面

一旦受限接口可以从外部触达，攻击者就会继续利用 CVE-2024-21887 触发系统命令执行。这样一来，整条链不再需要有效用户名、密码或正常会话。

3. 实战中通常不会止步于“打一条命令”

公开事件中，攻击者更常见的目标不是证明漏洞存在，而是立刻转入：

  • 导出配置与数据库信息
  • 窃取私钥、证书与账号材料
  • 篡改内置脚本或二进制
  • 写入后门与被动控制组件
  • 建立反向连接与横向通道

4. 为什么边界设备特别容易被“打成长期入口”

ICS/PS 这类设备天然位于：

  • 身份认证链路
  • 远程接入链路
  • 管理面与业务面之间

因此它一旦失陷，攻击者拿到的不只是一个 shell，而是一个可继续：

  • 看见内网结构
  • 触达认证材料
  • 利用合法接入路径深入环境

的高价值起点。

0x04 POC 与验证思路

出于安全考虑，这里不提供可直接复现对公网目标攻击的利用脚本，只保留研究与蓝队自查视角下的验证思路。

防守型验证重点

更有价值的核验动作包括：

  1. 确认设备型号与版本是否落在官方受影响范围。
  2. 回看 2023-12 以来是否存在异常受限接口访问。
  3. 检查是否出现本不应由未授权用户命中的管理功能调用。
  4. 检查是否存在后续文件篡改、异常组件、被动后门或出站连接。
  5. 使用官方最新恢复文档和最新版检测工具做离线或受控环境核查。

一个需要特别强调的事实

对于 Ivanti 这次事件，ICT 并不能被视为绝对可信的“清白证明”。公开分析已经表明：

  • 部分攻击者会篡改或欺骗完整性检查结果
  • 旧版或内部工具不能覆盖全部后门形态
  • “工具扫描没发现异常”不等于“设备没有被入侵”

因此，防守型验证不能只依赖单个扫描结果。

0x05 高级利用姿势

1. 最常见的不是直接回显，而是“补丁式后门化”

公开案例中，攻击者经常不急于投放一个显眼的新 WebShell，而是更倾向于：

  • 篡改已有 CGI
  • 篡改登录相关 JavaScript
  • 植入看起来像正常资源的 .egg、.css、图片或脚本文件

这种方式的优点是：

  • 更容易混入现有文件树
  • 更不容易被“找新增文件”发现
  • 可以直接复用设备原本的执行路径

2. 通过合法组件窃取凭据和会话

研究方观察到的后利用不只是命令执行，还包括：

  • 键盘记录或登录流程拦截
  • 会话与数据库信息窃取
  • 证书、私钥与配置文件导出

这说明攻击者真正看重的不是设备本身，而是设备所站的位置和它保管的秘密。

3. 持久化不一定依赖传统 WebShell

Mandiant 与 CISA 的公开资料说明，这次 Ivanti 事件中的武器化程度非常高。攻击者使用了多个家族化组件，例如：

  • GLASSTOKEN
  • GIFTEDVISITOR
  • LIGHTWIRE
  • CHAINLINE
  • BUSHWALK
  • ZIPLINE
  • THINSPOOL
  • WARPWIRE

这些组件的意义在于，它们把“打进设备”升级为：

  • 被动后门
  • 反向隧道
  • 持久化组件
  • 凭据窃取链
  • 多阶段后渗透框架

4. 设备即使补丁后也可能存在残留风险

Ivanti 事件里最需要高亮的一点是：公开处置建议已经明确从“打补丁”升级成“必要时重建”。这是因为：

  • 攻击者可能已获得高权限持久化
  • 设备上的信任材料可能已经外泄
  • 即使恢复表面功能，底层后门和篡改也可能仍在

这与普通应用补丁思路完全不同，属于典型“边界设备失陷要按入侵事件处理”的场景。

0x06 日志痕迹与应急排查

1. 日志缺失本身就是异常

Volexity 公开披露的一个高价值信号是：

  • 日志被清空
  • 日志记录被关闭
  • 设备本地取证线索被主动抹除

所以在 Ivanti 场景里，“没看到日志”并不一定是没事，反而可能是已被攻击者处理过。

2. 重点关注管理面异常访问与命令执行链

应优先排查：

  • 原本应受限的 API 被异常调用
  • 非正常来源对管理相关路径的访问
  • 设备发起的不明出站连接
  • 紧随可疑请求后的命令执行与系统行为变化

3. 文件与组件完整性检查

高优先级检查对象包括：

  • compcheckresult.cgi
  • querymanifest.cgi
  • 登录相关 JavaScript
  • 异常 .egg
  • 随机命名的 .css
  • 伪装成正常资源的图片或静态文件

如果这些位置出现不可解释的差异、时间戳异常或内容异常，应高度怀疑已遭植入。

4. ICT 结果不能单独作为结论

因为公开资料已经说明攻击者可能：

  • 修改 ICT 逻辑
  • 让其始终回报“没有变化”
  • 伪装成正常状态

所以更可靠的方式是：

  • 结合离线检查
  • 对照官方恢复文档逐项核验
  • 结合网络、日志、文件系统和业务侧异常做交叉判断

5. 应急处置原则

如果设备曾处于受影响版本并暴露在公网，应优先按“可能已失陷”处理：

  • 先限制设备外连与横向能力
  • 保全日志、镜像和配置样本
  • 使用最新版外部检查工具
  • 评估是否需要直接重建而不是原地修补
  • 轮换所有可能受影响的凭据、证书与密钥

0x07 修复与缓解建议

1. 立即升级到官方修复版本

最基础的动作仍然是安装 Ivanti 官方针对不同产品线发布的修复版本，并确认不是只更新了其中一个分支。

2. 不把“补丁已装”当作处置完成

这类设备一旦已经被利用，补丁只能阻止后续同路径攻击，不能自动清除：

  • 已存在后门
  • 篡改过的合法文件
  • 已泄露的凭据与证书
  • 已建立的横向路径

3. 必要时按官方指南重建

Ivanti 官方恢复建议明确倾向于：

  • 从已知良好状态重建
  • 重新核验组件完整性
  • 重新部署受影响设备

这说明对疑似失陷设备，简单的“继续在原机上修补运行”并不可靠。

4. 轮换所有高价值秘密

至少应考虑轮换：

  • 本地与远程管理口令
  • 用户和服务账号密码
  • VPN 相关凭据
  • 证书与私钥
  • 任何由设备保存或中转的共享密钥与会话材料

5. 限制设备外联与历史暴露面

后续治理建议包括：

  • 最小化设备的出站能力
  • 收缩管理面暴露
  • 将远程接入设备纳入持续完整性审计
  • 对边界设备异常行为建立更高优先级告警

0x08 参考资料