GitHub Enterprise Server 身份验证绕过漏洞 (CVE-2024-4985) 深度解析

CVE-2024-4985 漏洞背景与影响范围

GitHub Enterprise Server (GHES) 在 2024 年 5 月发布的安全更新中修复了一个编号为 CVE-2024-4985 的关键身份验证绕过漏洞。该漏洞的 CVSS 评分高达 10.0，属于最高严重级别。漏洞根源在于 GHES 在处理 SAML 单点登录（SSO）请求时，未能正确验证加密断言（Encrypted Assertions）的签名。攻击者利用该漏洞可以伪造 SAML 响应，从而绕过身份验证机制，获取对 GHES 实例的管理员访问权限。由于 GHES 通常部署在企业内部网络或云端的受控环境中，存储着大量的核心代码资产及 CI/CD 配置，该漏洞的潜在威胁极大，可能导致供应链攻击或敏感知识产权泄露。

漏洞主要影响启用了 SAML SSO 且配置了可选的“加密断言”功能的 GHES 实例。在这种配置下，GitHub 在处理来自身份提供者（IdP）的 SAML 响应时存在逻辑缺陷。通过利用 Zondex 等互联网测绘工具，安全研究人员可以识别暴露在公网或特定网段中的 GHES 登录界面，进而通过指纹识别确定其版本是否处于受影响范围内。

受影响版本系列 受影响版本范围 安全修复版本
GitHub Enterprise Server 3.13 < 3.13.0 3.13.0
GitHub Enterprise Server 3.12 < 3.12.4 3.12.4
GitHub Enterprise Server 3.11 < 3.11.10 3.11.10
GitHub Enterprise Server 3.10 < 3.10.12 3.10.12
GitHub Enterprise Server 3.9 < 3.9.15 3.9.15

SAML 身份验证机制与漏洞成因

在标准的 SAML SSO 流程中，服务提供者（SP，此处为 GHES）接收来自身份提供者（IdP）的 SAMLResponse。该响应通常包含用户的身份信息（Assertions），并由 IdP 的私钥进行签名。为了增强安全性，企业可以选择加密这些断言，确保敏感信息在传输过程中不被泄露。CVE-2024-4985 的核心问题在于 GHES 的 XML 解析器和 SAML 处理引擎在解密断言后，未能强制执行严格的签名验证流程。

具体而言，当 EncryptedAssertion 被使用时，GHES 的身份验证逻辑在某些特定条件下会跳过对 XML 签名的完整性检查。攻击者可以通过构造一个不包含合法 IdP 签名、但符合预期 XML 结构的加密断言包。如果 GHES 无法正确关联解密后的数据与信任锚点（Trust Anchor），它可能会错误地信任断言中的 NameID 或 Attribute 声明。这意味着攻击者只需知道目标用户的用户名或电子邮件，即可通过伪造的 SAML 响应登录为该用户，甚至获取 Site Administrator 权限。

XML 签名包装与解密逻辑缺陷

在 CVE-2024-4985 中，攻击者利用了对 XML 处理库的误用。当 SAML 响应被接收时，系统首先进行解密。然而，解密后的内容在重新进入验证流程时，逻辑上出现了断层。如果攻击者构造了一个看似合法但实际是由非法密钥（或完全没有有效签名）生成的加密元素，GHES 的漏洞逻辑可能会在解密后直接接受其中的声明，而不再追溯该声明是否源自受信任的 IdP 根签名。这种绕过方式绕过了基于非对称加密的信任链，使得 SSO 的安全防护形同虚设。

<!-- 简化版的伪造 SAML 响应结构示例 -->
<samlp:Response xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_faked_id" Version="2.0">
  <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://idp.attacker.com</saml:Issuer>
  <saml:EncryptedAssertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
    <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
      <!-- 攻击者通过特定手段生成的加密数据，旨在利用 GHES 的解密逻辑漏洞 -->
      <xenc:CipherData>
        <xenc:CipherValue>BASE64_ENCODED_PAYLOAD</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </saml:EncryptedAssertion>
</samlp:Response>

漏洞触发条件分析

要成功利用 CVE-2024-4985，必须满足以下几个先决条件：

  • SAML SSO 已启用：实例必须配置为通过外部 IdP 进行身份验证，而不是使用内置的用户名/密码。
  • 加密断言（Encrypted Assertions）已启用：这是该漏洞触发的关键配置项。该功能本意是增加安全性，但在受影响的版本中反而引入了攻击路径。
  • 攻击者拥有网络可达性：攻击者需要能够访问 GHES 的 /login 或相关 SSO 回调端点。

在安全审计过程中，研究人员可以使用 Secably 对企业内部的 GHES 实例进行针对性扫描，以检测是否存在此类配置缺陷及版本过旧的问题。由于该漏洞不需要初始权限（Pre-authentication），因此其风险等级被定为最高等级。

技术细节：解密后的二次验证缺失

深入分析 GHES 处理 SAML 的 Ruby 代码（GHES 核心主要基于 Ruby on Rails），可以发现其使用的 ruby-saml 库或其上层的封装代码在处理 EncryptedAssertion 时存在逻辑分支判断错误。正常流程应该是：

  1. 接收 SAMLResponse。
  2. 验证 SAMLResponse 的顶级签名。
  3. 如果是加密断言，使用 SP 私钥解密。
  4. 关键步骤： 验证解密后的 Assertion 内部签名。
  5. 提取用户信息。
在 CVE-2024-4985 的漏洞场景中，第 4 步被意外跳过或由于某种解析歧义导致验证失效。攻击者如果能注入一个解密后不带签名或带虚假签名的断言，GHES 会因为信任第 3 步的成功而认为整个过程是安全的。这种“解密即信任”的错误逻辑是此类高危漏洞的典型特征。

此外，由于 GitHub 企业版支持通过管理控制台直接配置 SAML，某些管理员可能在配置时并未强制要求签名，这进一步放大了漏洞的利用空间。然而，即便配置了“强制签名”，由于代码逻辑中的验证路径绕过，防御措施仍然可能失效。

利用场景模拟

在实战渗透测试中，攻击者通常会进行以下操作：

  1. 通过 Recon 确认目标 GHES 的版本，识别其是否开启了 SAML。
  2. 分析目标的 IdP 协议格式，构造包含目标管理员 NameID 的 SAML 断言。
  3. 使用特定的加密库（如 xmlsec1）对断言进行包装，确保其符合 EncryptedAssertion 的语法结构。
  4. 向 GHES 发送 POST 请求，将伪造的 SAMLResponse 发送至 /saml/consume 端点。
  5. 如果漏洞利用成功，服务器将返回一个带有 user_session Cookie 的响应，攻击者随后即可访问管理控制台。
为了隐藏真实的攻击来源或绕过基于地理位置的访问控制，研究人员在测试此类漏洞时常利用 GProxy 来实现流量的匿名化和路由伪装。这种方式可以模拟来自企业分支机构或特定合规区域的请求，从而更真实地评估漏洞的利用难度。

修复建议与防御策略

针对 CVE-2024-4985，GitHub 官方已通过更新补丁彻底修复了 SAML 响应解析逻辑中的缺陷。最直接且有效的修复措施是将 GitHub Enterprise Server 升级到官方发布的最新版本。升级过程不仅修复了身份验证绕过逻辑，还加固了 XML 处理器对恶意结构的解析防御。

临时缓解措施

如果因业务原因无法立即升级，可以考虑以下临时补救措施：

  • 禁用加密断言：如果 IdP 和 GHES 之间的通信通过加密通道（如强制 HTTPS/TLS）进行，且安全策略允许，可以暂时在 GHES 管理设置中禁用 SAML 的“Encrypted Assertions”功能。这会切断漏洞触发的必要条件，但会降低断言数据本身的机密性。
  • 增强网络限制：通过 IP 白名单严格限制访问 GHES 登录端点的范围，仅允许企业内网或受信任的 VPN 网段访问。
  • 监控审计日志：密切关注 auth.log 和 SSO 登录日志，寻找异常的登录行为，特别是那些来源不明、且以管理员身份登录的记录。

升级后的版本引入了更严格的断言验证机制。修复后的代码强制要求在解密 EncryptedAssertion 后进行二次签名校验，并确保解密出的 XML 节点与预期的命名空间和父节点属性完全一致。这种深度防御策略有效防止了任何形式的 XML 签名包装攻击（XSW）或逻辑绕过。对于任何依赖 SAML 进行身份认证的企业级软件，CVE-2024-4985 提供了一个重要的警示，即加密并不等同于完整性验证，安全系统必须在每一个处理阶段维持信任链的连续性。