CVE-2024-4985 漏洞机制与 SAML 响应伪造分析
GitHub Enterprise Server (GHES) 的 CVE-2024-4985 漏洞是一个影响极其严重的身份验证绕过漏洞，其 CVSS 评分达到了最高级别的 10.0。该漏洞源于 GHES 在处理使用 SAML 单点登录（SSO）且启用“加密断言”（Encrypted Assertions）时的逻辑缺陷。远程攻击者可以利用该漏洞，在无需事先获得有效凭据的情况下，伪造 SAML 响应以获取对 GHES 实例的管理员权限。由于 SAML 协议通常用于企业环境中的跨域身份验证，此类漏洞一旦被利用，攻击者将能够访问组织存储在 GitHub 上的所有源代码、机密信息以及开发管道。
SAML 断言加密过程中的验证失效
在标准的 SAML 流程中，身份提供者（IdP）会对 SAML 断言（Assertion）进行签名，以确保数据的完整性和真实性。当 GHES 启用加密断言功能时，IdP 会使用 GHES 的公钥对断言内容进行加密。GHES 接收到加密后的 XML 响应后，应首先解密内容，随后严谨地验证签名的有效性。然而，CVE-2024-4985 的核心在于其解密与验证逻辑的解耦：在特定的配置组合下，GHES 的 SAML 解析引擎未能对解密后的 XML 结构进行严格的架构验证，导致攻击者可以构造包含恶意断言的响应，使系统误认为该响应已通过 IdP 签名验证。
通过使用 Zondex 等互联网空间资产测绘工具，安全研究员可以发现大量暴露在公网或内网边界的 GHES 实例。如果这些实例配置了 SAML 并启用了加密断言，它们极易受到该漏洞的攻击。这种漏洞通常与 XML 签名包装（XML Signature Wrapping, XSW）攻击技术相关，攻击者通过在 XML 文档中操纵已签名部分和恶意构造部分的位置，欺骗逻辑验证层，使其在解密后错误地信任了攻击者注入的用户身份信息。
受影响版本与修复基线
该漏洞影响了多个主版本的 GHES 实例，其修复工作涉及多个维护分支。GitHub 官方已通过发布针对性的补丁包解决了此问题。下表列出了受影响的版本范围及其对应的安全修复版本：
| GHES 主版本系列 | 受影响的版本范围 | 修复版本（安全更新） |
|---|---|---|
| 3.12 | 3.12.0 至 3.12.3 | 3.12.4 |
| 3.11 | 3.11.0 至 3.11.9 | 3.11.10 |
| 3.10 | 3.10.0 至 3.10.11 | 3.10.12 |
| 3.9 | 3.9.0 至 3.9.14 | 3.9.15 |
需要注意的是，GitHub Enterprise Server 3.13 版本在发布时已经内置了针对此漏洞的防御代码，因此不受 CVE-2024-4985 的影响。对于无法立即升级的组织，评估当前是否启用了 Encrypted Assertions 是识别风险的关键步骤。在 GHES 的管理控制台（Site Admin）中，可以通过查看 SAML 设置下的 "Encrypt Assertions" 选项来确认配置状态。
技术分析：XML 签名验证缺陷
在 CVE-2024-4985 的漏洞场景中，问题在于后端 Ruby 代码在处理 ruby-saml 库及其相关中间件时，对 Assertion 节点的解密处理流程存在不一致性。当断言被加密时，GHES 预期的处理逻辑是：
1. 接收 SAMLResponse 2. 识别并解密 EncryptedAssertion 节点 3. 将解密后的 Assertion 替换回原 XML 树中 4. 验证 Assertion 的 Signature 节点
由于代码逻辑错误，攻击者可以提供一个既包含合法但过期的 EncryptedAssertion（用于通过初步结构检查），又包含一个伪造的普通 Assertion 节点的响应。由于解密逻辑在某些版本中未能正确清除或验证被替换节点的完整性，验证引擎可能会跳过对伪造 Assertion 节点的签名强制检查，直接根据其中的 NameID 或 AttributeStatement 授予登录权限。攻击者只需将 NameID 设置为具有 site_admin 权限的用户（如实例初始化时创建的第一个管理员），即可实现完全接管。
为了检测此类配置层面的漏洞，安全团队可以使用 Secably 等专业的漏洞扫描工具，通过模拟 SAML 握手过程来探测服务端对非预期断言格式的响应特征。此类自动化测试能够有效识别受影响的中间件版本及其配置缺陷。
攻击面探测与环境重现
在研究环境重现 CVE-2024-4985 时，研究人员通常会使用拦截代理工具来捕获和修改 SAML 流量。攻击者利用该漏洞的过程如下：首先，定位一个开启了 SAML 且支持加密断言的 GHES 目标。接着，通过正常的登录流程获取一个由 IdP 生成的有效 SAML 响应。此时，攻击者不需要私钥来读取加密内容，而是利用解析引擎在处理解密后数据流时的“宽容度”，构造一个混合结构的 XML 负载。
<samlp:Response ...>
<!-- 恶意构造的未加密 Assertion -->
<saml:Assertion ID="_attack_id">
<saml:Subject>
<saml:NameID>admin_user</saml:NameID>
</saml:Subject>
<!-- 缺失或伪造的签名，但在特定条件下被 GHES 忽略 -->
</saml:Assertion>
<!-- 合法但可能不相关的加密断言 -->
<saml:EncryptedAssertion>
...
</saml:EncryptedAssertion>
</samlp:Response>
这种攻击成功的关键在于利用了后端组件对解密结果的二次解析逻辑。如果解密后的输出流直接被传递给下一个解析函数而不重新进行签名路径锚定，攻击者注入的 _attack_id 节点可能会被提升为主要的身份凭证来源。此外，对于在受限网络环境下进行安全测试的研究人员，通常需要借助 GProxy 来维持稳定的代理通道，以确保在复杂的网络跳跃中 SAML 令牌的有效性不会因为源 IP 的频繁变动而导致非预期的失效。
日志取证与异常活动识别
在 GHES 实例中识别该漏洞是否已被利用，可以通过分析 /var/log/github/audit.log 中的身份验证事件来进行追踪。安全管理员应重点关注以下几类异常指标：
- SAML 响应解析错误： 搜索包含
saml_authentication_error或invalid_assertion的错误日志。虽然成功的攻击可能不会触发错误，但多次尝试伪造 XML 结构的失败记录是明显的攻击征兆。 - 非预期源 IP 的管理员登录： 审计
auth_success事件，特别是针对site_admin角色的登录。如果发现管理员账号从以往未见的 IP 地址登录，且登录方式记录为saml，则需高度警惕。 - XML 签名不匹配告警： 在
exceptions.log中，如果出现大量关于解密失败或签名验证逻辑跳过的 Ruby 回溯信息，通常意味着攻击者正在尝试调试其伪造的 SAML 负载。
修复实施与增强防御
针对 CVE-2024-4985 的修复不仅限于简单的版本升级。GitHub 在补丁中引入了更严格的 XML 路径验证，强制要求所有解密后的断言必须包含在已签名的范围内，并禁用了对不完整 XML 结构的解析。对于企业用户，执行以下操作是加固系统的必要步骤：
- 强制升级： 使用
ghe-upgrade命令将 GHES 提升至上述修复版本。升级过程中会重新配置内建的 Web 服务容器，确保新的ruby-saml补丁生效。 - 轮换 SAML 证书： 虽然漏洞本身不涉及私钥泄露，但作为纵深防御的一部分，建议在升级后轮换用于 SAML 签名的证书，以使攻击者可能持有的旧令牌完全失效。
- 监控配置更改： 禁用“未签名响应”选项。在 GHES 设置中，确保要求响应和断言均经过签名。虽然 CVE-2024-4985 专门针对加密断言，但强化整体签名校验能抵御类似的 XSW 攻击。
- 实施多因素身份验证 (MFA)： 即使 SAML 断言被伪造，如果 GHES 强制要求在 SSO 之外进行二次 MFA 验证，攻击者仍然无法轻易获取管理员会话。
在执行版本更新后，务必运行 ghe-config-apply 确保所有配置更改已在所有节点上同步，并使用 ghe-diagnostics 检查身份验证子系统的健康状态。确保所有这些管理操作都在一个受控的环境中进行，以防止配置错误导致企业开发者的大面积登录中断。