理解并加固 RADIUS 防御 MD5 碰撞攻击

执行摘要

自 1991 年以来，作为企业网络认证基石的 RADIUS 协议，存在一个严重且现已可实际利用的漏洞。该漏洞于 2024 年 7 月以 CVE-2024-3596 编号披露，被命名为“Blast-RADIUS”，允许位于 RADIUS 客户端与服务器之间的中间人 (MitM) 攻击者伪造有效的认证批准——将合法的“Access-Reject”转换为“Access-Accept”——而无需知晓用户密码或共享的 RADIUS 秘密。此攻击利用 MD5 选择前缀碰撞技术，在现代硬件上可在数分钟内完成。

对于场馆运营商和企业 IT 团队来说，业务风险是直接的：获得未经授权网络访问权限的攻击者可以横向移动到基础设施各处，访问销售点系统，窃取访客数据，并引发违反 PCI DSS 和 GDPR 的合规问题。所有使用 PAP、CHAP 或 MS-CHAP 认证模式运行 RADIUS/UDP 的组织都面临风险，直到应用补丁并规划架构变更。即时缓解措施——对所有 RADIUS 流量强制执行 Message-Authenticator 属性——是所有主要供应商均可提供的低干扰配置变更。战略性应对措施是分阶段迁移到 EAP-TLS 和基于 TLS 的 RADIUS (RADSEC)。

技术深入剖析

RADIUS 协议及其加密遗产

RADIUS（远程认证拨入用户服务）在 RFC 2865 中标准化，设计于网络安全需求截然不同的时代。该协议基于 UDP 运行，并使用 RADIUS 客户端（通常是接入点或网络接入服务器）与 RADIUS 服务器之间的共享秘密来提供一定程度的报文完整性。具体来说，服务器响应使用称为 Response Authenticator 的构造进行“认证”，其计算方式为：

MD5(Code || ID || Length || RequestAuthenticator || Attributes || SharedSecret)

该构造从未成为一个真正的报文认证码 (MAC)。它早于 HMAC，而 HMAC 于 1997 年标准化正是为了解决基于原始哈希的 MAC 的弱点。当 HMAC 被引入时，RADIUS 规范并未更新，在 2004 年首次演示 MD5 碰撞时也未更新。这种架构债务如今已成为一个关键责任。

Blast-RADIUS 攻击机理

Blast-RADIUS 攻击 (CVE-2024-3596) 结合了三个要素：RADIUS 构造其 Response Authenticator 时的一个协议级漏洞、一种 MD5 选择前缀碰撞技术，以及碰撞计算速度的显著提升，使得攻击在实时网络拦截场景中变得可行。 攻击过程如下：MitM 攻击者拦截从 RADIUS 客户端发送到服务器的 Access-Request 数据包。攻击者向该请求注入一个恶意属性——一个精心构造的有效负载，它将导致合法服务器响应的 MD5 哈希与攻击者期望的伪造响应的 MD5 哈希之间发生碰撞。当服务器返回 Access-Reject（认证失败）时，攻击者利用预先计算的碰撞伪造一个有效的 Access-Accept 数据包，并附带一个 RADIUS 客户端会接受为真实的 Response Authenticator。攻击者无需知道共享秘密或用户凭证。

波士顿大学、加州大学圣地亚哥分校、阿姆斯特丹 CWI 和微软的研究人员证明，借助优化算法，该攻击所需的 MD5 选择前缀碰撞可以在普通硬件上于五分钟内计算出来。这使得攻击对于能够访问 RADIUS 客户端与服务器之间网络路径的坚定对手来说，在操作上是可行的。

受影响的认证方式

该漏洞影响所有使用非 EAP 认证方法的 RADIUS/UDP 部署。下表总结了各认证方式的暴露情况：

关键区别在于，基于 EAP 的方法为其认证建立了自己的加密隧道，该隧道不依赖于 MD5 Response Authenticator。这使它们对具体的 Blast-RADIUS 攻击向量免疫。

为什么 VLAN 分段不够

一个常见的误解是，将 RADIUS 流量隔离在专用管理 VLAN 中就能提供足够的保护。虽然网络分段是一种合理的的安全实践，但它并不能消除 Blast-RADIUS 风险。已经通过钓鱼攻击、供应链入侵或利用其他漏洞入侵管理网络上某设备的攻击者，可以将自己定位为 RADIUS 流量路径上的 MitM。攻击只需要网络路径访问权限，不需要外部互联网访问权限。分段减少了攻击面，但不能消除底层的加密弱点。

实施指南

第一阶段：立即加固（第 1-2 周）

首要任务是在所有 RADIUS 基础设施上应用针对 CVE-2024-3596 的供应商补丁。所有主要供应商——包括 Cisco ISE、Microsoft NPS、FreeRADIUS、Juniper、Aruba 和 Ruckus——都已发布更新。在修补的同时，关键的配置变更是在所有 RADIUS 客户端和服务器上强制执行 Message-Authenticator 属性。

Message-Authenticator 属性（定义于 RFC 2869）对整个 RADIUS 数据包提供基于 HMAC-MD5 的完整性检查。与 Response Authenticator 不同，该构造不易受选择前缀碰撞攻击，因为 HMAC 构造将哈希与共享秘密绑定，从而阻止攻击者制造有效的伪造。配置客户端和服务器要求该属性——并拒绝任何不包含该属性的消息——即可关闭直接攻击向量。

对于 FreeRADIUS，这需要在 clients.conf 文件中设置 require_message_authenticator = yes。对于 Microsoft NPS，等效策略通过网络策略设置执行。对于 Cisco ISE，该设置可在认证策略下的 RADIUS 客户端配置中找到。有关具体配置步骤，请参阅供应商针对 CVE-2024-3596 的特定咨询。

第二阶段：认证现代化（第 1-3 个月）

中期目标是将 WiFi 认证从传统的 PAP/CHAP 模式迁移到基于 EAP 的方法。对于企业 WiFi 环境，推荐路径是 采用 EAP-TLS 的 WPA3-Enterprise。这需要部署公钥基础设施 (PKI) 来颁发设备和/或用户证书，配置您的 RADIUS 服务器以验证这些证书，并为客户端设备预配适当的证书和 RADIUS 服务器信任锚。

对于证书部署复杂的环境——例如设备周转率高或实行 BYOD 政策的场馆——采用 MSCHAPv2 的 PEAP 提供了一个可接受的临时步骤，前提是客户端配置为验证 RADIUS 服务器证书。如果没有服务器证书验证，PEAP 容易受到流氓接入点攻击。有线基础设施应同时实施 IEEE 802.1X 基于端口的访问控制，以确保整个网络中的认证策略一致性。

第三阶段：传输层安全（第 3-12 个月）

长期架构目标是使用 基于 TLS 的 RADIUS (RADSEC)（在 RFC 6614 中标准化）将所有 RADIUS 流量封装在 TLS 隧道内。RADSEC 用 TCP 取代 UDP，并将整个 RADIUS 会话封装在相互认证的 TLS 连接中。这为所有认证流量提供了机密性、完整性和重放保护，使 MD5 Response Authenticator 变得无关紧要，因为传输层本身在加密上是安全的。

RADSEC 在分布式部署中特别有价值——例如连锁酒店、零售网络或体育场环境——在这些环境中，RADIUS 流量可能穿越中间网络段。IETF 目前正在推进基于 TLS 和 DTLS 的 RADIUS 达到标准跟踪状态，反映了行业共识，即对于敏感部署应弃用 RADIUS/UDP。

最佳实践

以下供应商中立的最佳实践反映了企业 WiFi 认证安全性的当前行业标准和监管指南。

普遍强制执行 Message-Authenticator。 你的环境中的每个 RADIUS 客户端和服务器都应配置为发送并要求 Message-Authenticator 属性。这是当前影响最大、干扰最小的行动。根据 Blast-RADIUS 研究团队的指南，该属性应作为 Access-Accept 和 Access-Reject 响应中的第一个属性出现。

采用 EAP-TLS 作为认证标准。 结合 EAP-TLS 的 IEEE 802.1X 提供基于证书的相互认证，对 Blast-RADIUS 攻击类免疫，并符合 NIST SP 800-120 对无线网络访问中 EAP 方法的建议。WPA3-Enterprise 要求最高安全层级采用带 EAP-TLS 的 192 位安全模式。

定期轮换 RADIUS 共享秘密。 虽然 Blast-RADIUS 攻击不需要知道共享秘密，但强大、独特的共享秘密（最少 32 个字符，随机生成）可降低其他攻击类的风险。秘密应至少每年轮换一次，在任何怀疑泄露事件发生时立即轮换。

实施 RADIUS 记账和异常监控。 RADIUS 记账日志提供认证事件的审计跟踪。监控异常模式——例如来自意外设备类型、MAC 地址或异常时间的成功认证——可以提前预警被利用的情况。将 RADIUS 记账与您的 SIEM 集成，实现自动告警。

分段 RADIUS 流量。 虽然这不是完整的缓解措施，但将 RADIUS 流量放置在带有严格 ACL 的专用管理 VLAN 中，可减少可能被用作 MitM 支点的设备数量。结合网络访问控制，确保只有授权的设备才能到达 RADIUS 服务器。

符合 PCI DSS 要求。 PCI DSS v4.0 要求 8.6 强制所有帐户采用强认证。要求 1.3 要求网络分段控制。处理支付卡数据的组织必须确保其 WiFi 认证架构满足这些要求，而 Blast-RADIUS 漏洞直接影响任何适用范围内的网络段的合规状况。

故障排查与风险缓解

加固过程中的常见故障模式

强制执行 Message-Authenticator 时遇到的最常见问题是传统设备不兼容。较旧的接入点、交换机或 VPN 集中器可能不支持该属性，导致在服务器配置要求后出现认证失败。推荐的方法是在服务器端强制执行该要求之前，审计所有 RADIUS 客户端，并维护需要固件更新或更换的设备列表。

第二个常见问题是 EAP-TLS 迁移期间的证书验证失败。如果客户端设备未预配正确的 RADIUS 服务器证书信任锚，它们将拒绝服务器证书并导致认证失败。这在 BYOD 环境中特别普遍。部署移动设备管理 (MDM) 解决方案以推送证书配置文件是标准解决方案。

如果在 RADSEC 迁移期间，TLS 证书的通用名称与预期的客户端标识不匹配，可能会出现共享秘密不匹配。确保证书主题名称与服务器上配置的 RADIUS 客户端 IP 地址或主机名一致。

无法立即修补的环境的风险缓解

对于无法立即修补的环境——例如传统工业控制系统或嵌入式网络设备——可以通过实施严格的网络访问控制来部分缓解风险，这些控制限制哪些主机可以与 RADIUS 服务器通信，从而减少 MitM 攻击者拦截流量的机会。这仅是一种临时措施；必须建立修补和更换路线图。

投资回报与业务影响

量化风险

当从漏洞成本和合规责任方面进行阐述时，加固 RADIUS 的业务案例很简单。在酒店或零售环境中，一次成功的 Blast-RADIUS 利用可能为攻击者提供企业网络访问权限，可能到达销售点系统、访客数据存储库和后台基础设施。根据行业基准，酒店业数据泄露的平均成本超过 300 万英镑，而根据 GDPR 的监管罚款可能高达全球年营业额的 4%。

对于适用 PCI DSS 的组织来说，导致持卡人数据暴露的网络认证失败可能触发强制取证调查、卡品牌罚款以及潜在丧失卡处理特权——这些成本远超实施 EAP-TLS 和 RADSEC 所需的投资。

实施成本基准

下表提供了典型场馆环境中三阶段加固路线图的指示性成本和工作量估算：

超越安全性的运营效益

迁移到 EAP-TLS 和 RADSEC 除了安全加固外，还能带来运营效益。基于证书的认证消除了在庞大设备群中管理和轮换共享密码的运营开销。WPA3-Enterprise 提高了密集环境中的连接可靠性——这对于体育场和会议中心来说是一个可衡量的好处，因为那里有数百台设备竞争认证。RADSEC 的 TCP 传输在高延迟或有损网络条件下也能提供比 UDP 更好的可靠性，改善最终用户的认证体验。