CVE-2024-4985 漏洞成因与技术背景
GitHub Enterprise Server (GHES) 在 2024 年 5 月发布的安全更新中修复了一个编号为 CVE-2024-4985 的严重身份验证绕过漏洞。该漏洞的 CVSS 评分高达 10.0，属于最高级别的安全威胁。其核心缺陷在于 GHES 处理 SAML 单点登录 (SSO) 响应时的逻辑错误，特别是在开启了“加密断言”（Encrypted Assertions）功能的情况下。当此功能激活时，攻击者可以通过发送伪造的 SAML 响应，在无需知晓真实用户凭据的情况下，绕过身份验证并直接获得对 GitHub 实例的管理员权限。
SAML (Security Assertion Markup Language) 是一种基于 XML 的开放标准，用于在身份提供者 (IdP) 和服务提供者 (SP) 之间交换身份验证和授权数据。在典型的 GHES 环境中，GHES 作为 SP 信任外部 IdP（如 Okta, Azure AD 或 ADFS）。为了增强安全性，SAML 支持对断言（Assertion）进行加密，以确保数据在传输过程中不被第三方窃听。CVE-2024-4985 的根源在于 GHES 在解析这些加密断言时，未能正确验证 XML 签名的完整性，导致系统误信了攻击者构造的恶意断言内容。
受影响版本与修复方案
该漏洞影响所有启用了 SAML SSO 且激活了可选加密断言功能的 GHES 实例。需要注意的是，如果实例未使用 SAML SSO 或未启用加密断言，则不受此特定漏洞的影响。通过使用 Zondex 进行资产普查，安全团队可以快速识别暴露在互联网或内网环境中的 GHES 实例及其版本分布情况。
| 受影响的分支 | 受影响的版本范围 | 修复版本 |
|---|---|---|
| GHES 3.12 | < 3.12.4 | 3.12.4 |
| GHES 3.11 | < 3.11.10 | 3.11.10 |
| GHES 3.10 | < 3.10.12 | 3.10.12 |
| GHES 3.9 | < 3.9.15 | 3.9.15 |
SAML 身份验证绕过深度分析
在正常的 SAML 流程中，IdP 会生成一个包含用户身份信息（如 Username, Email, Role）的 XML 断言。该断言会被 IdP 的私钥签名。GHES 收到响应后，会使用 IdP 的公钥验证签名。如果启用了加密断言，断言的内容会被加密，只有持有对应私钥的 GHES 才能解密并读取其中的声明。
CVE-2024-4985 的技术细节显示，GHES 在处理 EncryptedAssertion 节点时存在逻辑缺陷。攻击者可以构造一个特殊的 SAML Response，其中包含一个不受保护的（未加密或伪造签名的）断言，或者利用 XML 转换过程中的差异性，诱导 GHES 的解析引擎在解密前或解密后跳过了严格的签名校验步骤。由于 GHES 的管理员账户通常由 SAML 属性（如特定的 Group 声明）决定，攻击者只需在伪造的断言中注入具有 administrator 权限的属性，即可实现提权。
<!-- 简化的攻击载荷示例：伪造的 SAML 断言结构 -->
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" ID="_fake_assertion_id">
<saml:Subject>
<saml:NameID>[email protected]</saml:NameID>
</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute Name="administrator">
<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<!-- 关键点：此处的签名可能被伪造或通过某种 XML 包装攻击被绕过 -->
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
</saml:Assertion>
</samlp:Response>
这种漏洞利用无需任何预存账户，对于攻击者而言，只要能够访问到 GHES 的登录接口，并知道目标企业的 SAML 配置细节（有时甚至可以通过公开的元数据获取），即可尝试发起攻击。为了评估内部系统的安全性，研究人员可以使用 Secably 提供的漏洞扫描能力，针对 SAML 注入和逻辑绕过进行自动化检测。
攻击场景与利用路径
在实际的企业环境中，GHES 通常部署在内网，但开发人员往往需要通过 VPN 或反向代理远程访问。为了确保这些关键路径的安全，建议企业采用 VPNWG 建立加密隧道，以降低漏洞被外部直接利用的风险。以下是典型的利用路径：
- 侦察阶段： 攻击者确认目标 GHES 启用了 SAML SSO。通过检查登录页面重定向的 URL 参数（如
SAMLRequest），可以判断其使用的 IdP 类型。 - 构造载荷： 攻击者利用已知的 XML 签名绕过技术（如 XML Signature Wrapping, XSW），将合法的加密断言替换为自定义的恶意断言。
- 提权攻击： 攻击者向 GHES 的
/consume端点提交伪造的SAMLResponse。 - 接管实例： 如果绕过成功，GHES 会为攻击者创建一个具有管理员权限的会话。攻击者随后可以访问敏感代码库、修改组织设置，甚至通过集成（Integration）获取第三方系统的访问令牌。
防御加固建议
针对 CVE-2024-4985 的首要防御措施是立即升级到 GitHub 官方发布的修复版本。除此之外，安全管理员应采取以下纵深防御策略：
1. 审计 SAML 配置
检查 /setup/settings 页面中的 SAML 设置。如果目前并不强制要求加密断言，可以暂时关闭该选项以规避漏洞路径。但最根本的解决方法仍然是版本升级，因为简单的配置调整可能无法覆盖所有的解析逻辑缺陷。
2. 强化日志监控
监控 auth.log 和 audit-log 及其相关的 XML 解析错误。由于此漏洞涉及异常的 SAML 响应，系统中可能会出现非典型的“签名校验失败”或“解密异常”日志，这些是攻击尝试的早期预警信号。
3. 管理员账户限制
限制具有管理员特权的用户数量，并强制要求管理员账户在 SAML SSO 之外开启二次身份验证（如 FIDO2 安全密钥）。即使攻击者通过 SAML 绕过进入系统，额外的身份核验也能起到最后一道防线的作用。
在 GHES 的解析代码中，GitHub 团队对 ruby-saml 和 xmlsec 等底层库的调用方式进行了重构，增强了在解密 EncryptedAssertion 后对整个 XML 文档结构的重新校验。这确保了即便攻击者在 XML 结构中插入了干扰节点，解析引擎也会因为断言的“来源不可信”而拒绝处理。这种对 XML 文档对象模型 (DOM) 的严格一致性检查，是修复此类复杂逻辑漏洞的关键手段。