CVE-2024-24919: Check Point Security Gateway/VPN 未授权文件读取漏洞分析

CVE-2024-24919: Check Point Security Gateway/VPN 未授权文件读取漏洞分析

CVE-2024-24919 是 2024 年边界设备领域非常值得重点记录的一起高危事件。官方把它定性为信息泄露，但如果从真实攻击路径看，它远不只是“读到一个文件”这么简单，而是一个能够快速串成凭据获取、VPN 接管与内网横向的边界突破入口。

这也是为什么它虽然不属于经典意义上的 RCE，但在实战影响上仍然非常接近“高危边界设备接管事件”。

0x01 漏洞背景与影响范围

1. 这是 Remote Access VPN / Mobile Access 暴露面的高危 0day

CVE-2024-24919 影响 Check Point Security Gateway 相关产品线，风险集中在：

  • Remote Access VPN
  • Mobile Access

等面向远程接入的能力上。由于这些组件通常直接暴露在公网，它一旦可被未授权利用，攻击者就能在企业边界直接获取高价值敏感信息。

2. 官方定性与现实影响之间存在明显差距

官方和 NVD 将其标记为信息泄露 / 任意文件读取，这个结论从漏洞类型上没有错，但如果只看到这里，很容易低估风险。现实中的问题在于，攻击者读取的往往不是一个无关紧要的文件，而是：

  • 本地账号哈希
  • 系统敏感配置
  • SSH 相关材料
  • 与认证和远程接入有关的关键信息

一旦这些内容被拿走，后续就能快速升级为更完整的入侵链。

3. 影响产品与版本

公开资料与厂商公告显示，主要影响范围包括：

  • CloudGuard Network
  • Quantum Maestro
  • Quantum Scalable Chassis
  • Quantum Security Gateways
  • Quantum Spark Appliances

公开版本矩阵中可见的受影响分支至少涉及：

  • R80.40
  • R81
  • R81.10
  • R81.20

更精确的热修复适配应始终以 Check Point 官方 sk182336 / sk182357 为准。

4. 利用前提

该漏洞并不是“任何 Check Point 设备都能打”，而是通常要求：

  • 启用了 IPSec VPN
  • 设备加入 Remote Access VPN community

或：

  • 启用了 Mobile Access

这再次说明，真正高风险的是那些承担互联网远程接入职责的边界网关。

0x02 漏洞原理

1. 主流公开分析指向路径遍历导致的任意文件读取

公开补丁分析表明，修复逻辑新增了：

  • sanitize_filename
  • 与路径遍历攻击相关的日志提示

这类改动非常典型，说明漏洞核心不在于复杂内存破坏，而更像是：

  • 对外部文件路径输入校验不足
  • 请求处理链错误地允许跨目录读取

2. 危险入口与 /clients/MyCRL 处理逻辑相关

较成熟的第三方技术分析把问题定位到了与：

  • /clients/MyCRL

相关的请求处理路径。攻击者可以构造异常路径，使设备返回本不应该暴露给未授权用户的本地文件内容。

3. 本质不是“一个文件下载 bug”，而是边界设备信任边界失守

如果这个问题出现在普通业务系统里，它可能只是一次严重信息泄露；但放在 VPN 网关上，后果会被显著放大，因为边界设备往往同时掌握：

  • 本地认证材料
  • 远程接入配置
  • 用户接入链路
  • 与内网身份系统的连接关系

因此攻击者从中拿到的不是单个文件，而是后续进入企业网络的钥匙。

4. 本质总结

这条链可以概括为：

未授权请求 -> 路径遍历 / 文件名处理缺陷 -> 任意文件读取 -> 凭据与配置泄露 -> 后续登录与横向

这也是为什么它虽然不是传统 RCE，但仍应被纳入高危边界设备利用链知识库。

0x03 利用路径与攻击链

1. 初始访问：先拿敏感文件

攻击者首先利用 CVE-2024-24919 读取设备上的敏感文件。公开响应资料中，最常被提及的高价值目标包括：

  • /etc/shadow
  • 其他本地认证相关文件
  • 可能暴露密钥或配置的敏感路径

2. 从“读取”快速过渡到“凭据化利用”

攻击者拿到哈希或认证材料后，后续常见步骤不是继续在同一条路径上反复打洞，而是转向：

  • 破解本地口令哈希
  • 使用恢复出的账号登录
  • 继续进入网关、系统或相关管理入口

这一阶段的关键在于，漏洞本身虽然是读取，但对攻击者来说，它已经足够构造后续有效身份。

3. 进一步向内网横向

公开案例与安全厂商总结表明，攻击者在边界设备上取得初始立足点后，往往会：

  • 使用新获得的认证材料继续登录
  • 横向进入 Active Directory
  • 获取更高价值的域环境数据
  • 最终向勒索或大规模数据窃取扩展

4. 为什么这类链路特别危险

因为它不需要一开始就稳定实现命令执行，只要能在边界设备上读到正确的文件，就足以：

  • 降低后续入侵门槛
  • 提升攻击成功率
  • 避开某些直接 RCE 的高噪声特征

对攻击者而言，这是非常高性价比的初始突破方式。

0x04 POC 与验证思路

出于安全考虑，这里不提供可直接利用公网设备的 PoC 代码，只保留防守视角下的研究与自查思路。

防守型验证重点

更值得做的是确认：

  1. 设备是否启用了 Remote Access VPN 或 Mobile Access。
  2. 设备版本是否落在官方受影响范围。
  3. 是否已经安装对应热修复。
  4. 是否存在对可疑读取路径的异常请求。
  5. 是否出现利用后的登录、横向与凭据滥用行为。

一个现实问题

对于该漏洞，公开资料普遍认为“任意文件读取动作本身”并不总会留下足够直观、稳定的单点日志。因此，企业排查不能只盯着“有没有读取某个文件”的明确证据，而要把重点放到：

  • 利用后的认证行为
  • 异常登录
  • 新出现的横向访问
  • 本地账户与密钥被滥用的痕迹

0x05 高级利用姿势

1. 先读哈希，再转登录，比直接 RCE 更隐蔽

很多时候，攻击者更喜欢这种链路而不是直接尝试 noisy 的命令执行，因为：

  • 网络层噪声更低
  • 行为更像正常读取
  • 后续可以用“合法身份”继续推进

这种模式特别适合打 VPN 与边界设备，因为一旦取得合法或近似合法身份，后面的入侵动作更难与普通接入区分。

2. 凭据化利用是这类漏洞真正的 weaponization 核心

CVE-2024-24919 的武器化重点不在于花哨 payload，而在于：

  1. 读取最关键的认证材料
  2. 快速恢复或利用这些材料
  3. 用合法入口继续渗透

也就是说，它的危险不来自“漏洞本身很炫”，而来自它特别适合与后续真实入侵动作连接。

3. 可与勒索前置作业自然衔接

CISA 已明确把该漏洞标记为已知用于勒索软件活动。其合理原因在于，这类边界读取漏洞很适合作为：

  • 前置侦察
  • 凭据获取
  • 内网跳板建立
  • 域环境接管的起点

因此在知识库里，应把它理解成“可服务于完整勒索链的边界突破事件”，而不是孤立的信息泄露。

4. 对蓝队来说最难的是“看起来不像大动静”

与某些会直接触发崩溃、WebShell 落地或明显命令执行的漏洞不同，路径遍历和文件读取在很多环境里更像“静悄悄拿钥匙”。这类攻击如果后续用合法账号推进，就更容易拖延发现时间。

0x06 日志痕迹与应急排查

1. 直接读取痕迹未必好找

公开应急资料提到，对任意文件读取本身，未必总能拿到特别可靠的直接证据。因此排查时不能只问“有没有这条利用日志”，而应从更完整的时间线看问题。

2. 补丁后的日志变化很重要

主流补丁分析指出，修复后系统会增加与路径遍历可疑行为相关的日志提示，例如：

  • Suspected path traversal attack from

如果在已打补丁的设备上看到类似告警，应把它当成高优先级攻击尝试来处理。

3. 重点回看后续认证与系统行为

高优先级排查内容包括：

  • /var/log/messages
  • /var/log/audit/audit.log
  • /var/log/auth
  • Web 管理登录记录
  • SSH 登录记录
  • PAM 认证成功事件

尤其要关注：

  • 原本不应出现的本地账号登录
  • 历史上未见过的源地址
  • 边界设备之后立即出现的内网访问扩展

4. 时间窗回溯

公开通报建议，至少应回溯到 2024 年 4 月初，因为已知攻击活动可以追溯到：

  • 2024-04-07

如果企业暴露时间更长，建议以设备外网暴露历史和补丁时间点为基础，适当扩大回看范围。

5. 应急处置原则

若设备满足以下任一条件，应按疑似已失陷处理：

  • 启用了受影响的远程接入功能
  • 长时间公网暴露
  • 补丁部署明显滞后
  • 出现可疑登录或边界设备后续横向行为

建议执行：

  • 先保全日志与配置样本
  • 核查本地账号与密钥是否泄露
  • 重置可能受影响的口令与认证材料
  • 审核后续内网横向活动
  • 必要时对设备和相关信任链开展更彻底的重置

0x07 修复与缓解建议

1. 安装官方热修复

最直接的动作是根据设备分支与版本，安装 Check Point 官方提供的对应热修复或 Jumbo Hotfix。

2. 不要只看“大版本是否还新”

该漏洞的修复依赖具体分支与补丁级别，因此不能只凭“我们在 R81.x”就判断安全，必须对照官方矩阵逐项确认。

3. 不能只修漏洞，还要处理凭据风险

如果设备曾暴露在公网且补丁滞后，应同步评估并必要时轮换：

  • 本地账户密码
  • 与设备相关的认证凭据
  • 可能泄露的证书与密钥

4. 检查热修复前置条件

公开安全通报特别提醒，在部分场景下如果：

  • CCCD 仍处于开启状态

热修复可能不会按预期生效。因此部署修复时必须结合官方步骤逐项确认，而不能只做“补丁已下发”的表面检查。

5. 按边界设备事件做后续治理

后续治理建议包括：

  • 收缩远程接入暴露面
  • 对 VPN 网关做专项资产清点
  • 审计边界设备本地账号使用情况
  • 提高对“边界设备之后立即出现的内网异常活动”的关联告警能力

0x08 参考资料