強化 RADIUS 以抵禦 MD5 碰撞攻擊 (BlastRADIUS)
緩解 CVE-2024-3596 BlastRADIUS 攻擊。強制執行 RADIUS Message-Authenticator、修補 FreeRADIUS 與 Cisco ISE,並遷移至 802.1X EAP-TLS。
Video overview
收聽此指南
查看播客逐字稿
核心系列的一部分:企業級 WiFi 安全指南 →
- 執行摘要
- MD5 碰撞攻擊的技術機制 (CVE-2024-3596)
- RFC 2865 中的密碼學漏洞
- 逐步緩解指南
- 步驟 1:強制執行 Message-Authenticator (RFC 2869)
- 比較安全矩陣:RADIUS 安全強化選項
- 轉移至 RADSEC (RFC 6614) 與 EAP-TLS
- Purple Cloud RADIUS 的關鍵架構優勢
- 企業合規與稽核影響
- PCI DSS v4.0 要求
- 符合 ISO 27001 與 GDPR 規範
- 使用 Purple 評估您的 RADIUS 安全態勢
- 常見問題
- EAP-TLS 是否容易受到 BlastRADIUS 的攻擊?
- Message-Authenticator (RFC 2869) 如何防範 CVE-2024-3596?
- UDP RADIUS 與 RADSEC (RFC 6614) 有何不同?
- 網路團隊如何稽核舊版存取點對 Message-Authenticator 的支援?
- 後續步驟與相關資源
Cloud RADIUS vs On-Premise TCO & Architecture Calculator
Select your network profile below to evaluate TCO, maintenance overhead, and optimal RADIUS deployment architecture for enterprise 802.1X security.
Cloud RADIUS (Zero On-Prem Footprint)
Key Architectural Takeaway: Managing individual RADIUS servers per branch causes massive maintenance overhead and certificate sync drift. Cloud RADIUS provides centralized 802.1X policy across all locations.

執行摘要
定義於 IETF RFC 2865 的遠端用戶撥入驗證服務 (RADIUS) 協定,三十多年來一直是企業網路的核心驗證架構。然而,CVE-2024-3596 (稱為 BlastRADIUS) 的揭露,暴露了 RADIUS 處理基於 MD5 的 Response Authenticator 欄位時,存在著嚴重的協定漏洞。
透過利用 MD5 選擇前綴碰撞技術,位於 RADIUS 用戶端 (例如無線存取點或交換器) 與 RADIUS 伺服器之間網路路徑上的中間人 (MitM) 攻擊者可以偽造驗證核准。攻擊者可以在不需要擁有使用者憑證或知道 RADIUS 共用金鑰的情況下,即時將合法的 Access-Reject 封包轉換為 Access-Accept 封包。
本技術指南概述了 BlastRADIUS 攻擊的密碼學機制,詳細說明了透過強制執行 Message-Authenticator 的即時廠商緩解策略,並為將 WiFi 基礎架構遷移到零信任 EAP-TLS 和 Purple Cloud RADIUS 提供了企業藍圖。
MD5 碰撞攻擊的技術機制 (CVE-2024-3596)
要瞭解 BlastRADIUS,需要檢視 RFC 2865 下建立的 RADIUS 封包標頭結構:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RFC 2865 中的密碼學漏洞
當 RADIUS 伺服器回應 Access-Request 時,它會對回應代碼、識別碼、長度、請求驗證器、屬性和共用金鑰計算 MD5 雜湊值:
Response Authenticator = MD5(Code + ID + Length + Request Authenticator + Attributes + Shared Secret)
由於 MD5 易受選擇前綴碰撞的影響,攻擊者會執行以下步驟:
- 攔截 Access-Request: 攔截由存取點傳送的合法 Access-Request。
- 植入碰撞前綴: 在將請求封包轉發到 RADIUS 伺服器之前,將精心設計的 Proxy-State 屬性插入封包中。
- **攔截 Access-Reject:**當 RADIUS 伺服器拒絕驗證嘗試並傳回 Access-Reject 時,攻擊者會攔截該封包。
- **偽造 Access-Accept:**攻擊者將回應代碼修改為 Access-Accept 並更改屬性負載。由於預先計算的碰撞前綴會產生相同的 MD5 輸出摘要,因此無線基地台會驗證該偽造的 Access-Accept 為真實有效。
逐步緩解指南
步驟 1:強制執行 Message-Authenticator (RFC 2869)
Message-Authenticator 屬性 (Attribute 80) 使用 HMAC-MD5 計算整個 RADIUS 封包(包括標頭欄位與屬性負載)的數位簽章:
Message-Authenticator = HMAC-MD5(RADIUS Packet, Shared Secret)
由於 HMAC-MD5 能夠抵禦選擇前綴碰撞攻擊,因此在所有用戶端請求與伺服器回應上強制執行 Attribute 80,即可使 BlastRADIUS 攻擊失效。
供應商實作指令
| RADIUS 供應商 | 設定指令 / 操作 | 最低支援版本 |
|---|---|---|
| FreeRADIUS | 在 clients.conf 中將 require_message_authenticator 設定為 yes |
v3.0.27 / v3.2.5 |
| Cisco ISE | 啟用 Require Message-Authenticator for all RADIUS Requests |
v3.1 Patch 8 / v3.2 Patch 4 |
| Aruba ClearPass | 在 RADIUS 服務中切換啟用 Enforce Message-Authenticator |
v6.11.7 / v6.12.2 |
| Microsoft NPS | 應用登錄檔 DWORD RequireMessageAuthenticator 數值 1 |
Windows Server 2019/2022 KB5040442 |
| Ruckus SmartZone | 在 AAA Server 下啟用 Message-Authenticator Enforcement |
v6.1.2 Patch 1 |
# FreeRADIUS clients.conf 安全強化管理程式碼片段
# 確保將 client 區塊的 require_message_authenticator 設定為 yes
client branch_ap_cluster {
ipaddr_range: 192.168.10.0/24
secret_key: EnterpriseSecret2026!
require_message_authenticator_option: yes
limit_connections: 16
idle_timeout_sec: 30
}
# 透過 PowerShell 進行 Microsoft NPS 登錄檔安全強化
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy" `
-Name "RequireMessageAuthenticator" -Value 1 -PropertyType DWORD -Force
Restart-Service IAS
對於您的特定設置有任何疑問嗎?
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。
比較安全矩陣:RADIUS 安全強化選項
| 安全強化措施 | 漏洞防護 | 實作工作量 | 用戶端相容性 | 營運影響 |
|---|---|---|---|---|
| Message-Authenticator (RFC 2869) | 阻擋 CVE-2024-3596 | 低(修改設定) | 相容於現代無線基地台 | 極短的停機時間 |
| RADSEC (RFC 6614) | 完整的 WAN TLS 1.3 加密 | 中(部署代理伺服器) | 需要支援 TCP 2083 | 消除 MitM 風險 |
| 802.1X EAP-TLS 遷移 | 零信任雙向憑證驗證 | 中至高 (PKI / SCEP) | 支援所有企業級作業系統 | 消除密碼使用 |
| Purple Cloud RADIUS | 端到端雲端 RADIUS + RADSEC | 低(即開即用的雲端整合) | 支援通用 802.1X | 自動化憑證生命週期管理 |
轉移至 RADSEC (RFC 6614) 與 EAP-TLS
傳統的 RADIUS 在未加密的 UDP 連接埠 1812 和 1813 上運作。在不受信任的 WAN 連結上傳輸驗證流量,會使封包標頭暴露於主動攔截的風險中。
部署 RADSEC (RADIUS over TLS) 可將 RADIUS 封包封裝在加密的 TCP TLS 1.3 通道內:
- 連接埠: TCP 2083
- 加密: 採用 AES-256-GCM 加密套件的 TLS 1.3
- 驗證: 用戶端代理程式與伺服器端點之間進行雙向 X.509 憑證驗證
flowchart LR
A["Wireless Endpoints (Laptops/IoT)"] -->|WPA3-Enterprise 802.1X| B["Access Points / Switches"]
B -->|RADSEC TLS 1.3 Port 2083| C["Purple Cloud RADIUS"]
C -->|REST / SCIM API| D["Cloud IdP (Entra ID / Okta / Google)"]
Purple Cloud RADIUS 的關鍵架構優勢
- 免輕觸 802.1X 憑證上線: 自動為託管裝置發行 SCEP 和 EST 憑證,消除手動設定密碼的繁瑣程序。
- 內建 RADSEC 代理架構: 透過加密的 TCP 連線保護遠端分部流量,無需建立複雜的站點對站點 IPsec 通道。
- 全面的訪客與企業安全: 將企業級 802.1X 驗證與符合 GDPR 規範的 Captive Portal 訪客上線系統相結合。
企業合規與稽核影響
PCI DSS v4.0 要求
在 PCI DSS v4.0 規範下,未經修復的 RADIUS 基礎架構會使付款卡環境面臨嚴重的稽核不合規風險:
- 要求 8.3: 強制要求對所有管理存取進行多因素驗證與強大的憑證管理。
- 要求 8.6: 禁止依賴弱密碼演算法(例如無金鑰的 MD5 摘要)。
- 要求 1.3: 要求在訪客、IoT 和持卡人資料環境 (CDE) 之間進行嚴格的網路隔離。
符合 ISO 27001 與 GDPR 規範
維持未加密或易受攻擊的 RADIUS 驗證違反了 ISO 27001:2022 控制措施 A.8.20(網路安全)與 GDPR 第 32 條(處理安全性)。升級至 EAP-TLS 和 RADSEC 可建立已文件化的密碼學合規性。
使用 Purple 評估您的 RADIUS 安全態勢
您的企業 WiFi 基礎架構是否容易受到 BlastRADIUS (CVE-2024-3596) 的攻擊?Purple 提供零信任雲端 RADIUS 解決方案,內建 RADSEC 加密、自動化 SCEP 憑證佈署,以及無縫的識別提供者整合。
- 自動化 802.1X EAP-TLS 上線: 在企業端點中淘汰傳統密碼。
- 即開即用 RADSEC 雲端代理: 透過 TLS 1.3 加密分部驗證流量,無 VPN 額外開銷。
- 統一安全與分析: 在管理企業 802.1X 安全性的同時,管理符合 GDPR 規範的訪客 WiFi。
常見問題
EAP-TLS 是否容易受到 BlastRADIUS 的攻擊?
否。EAP-TLS、PEAP 和 EAP-TTLS 在用戶端裝置與 RADIUS 伺服器之間建立獨立的 TLS 通道。此加密通道的運作獨立於舊版 RADIUS 回應驗證器 MD5 摘要,使 EAP 驗證免受 CVE-2024-3596 的影響。
Message-Authenticator (RFC 2869) 如何防範 CVE-2024-3596?
Message-Authenticator (屬性 80) 使用 HMAC-MD5 並透過共用金鑰對整個 RADIUS 封包進行簽章。與標準 MD5 回應驗證器不同,HMAC-MD5 在密碼學上能夠抵禦選擇前綴碰撞攻擊,使封包偽造變得不可能。
UDP RADIUS 與 RADSEC (RFC 6614) 有何不同?
標準 RADIUS 透過未加密的 UDP 連接埠 1812 和 1813 以純文字傳輸驗證封包。RADSEC 則將 RADIUS 封包封裝在連接埠 2083 上的加密 TLS 1.3 TCP 串流中,在不受信任的網路上提供雙向 X.509 憑證驗證和完整的機密性。
網路團隊如何稽核舊版存取點對 Message-Authenticator 的支援?
網路團隊應使用 tcpdump -i eth0 -n port 1812 擷取連入的 RADIUS 流量,並針對 radius.Message_Authenticator 進行篩選。確認所有存取點型號中皆存在屬性 80,可確保伺服器端的強制執行不會中斷用戶端連線。
後續步驟與相關資源
若要探索相關的企業級 WiFi 安全架構與診斷指南,請參閱以下資源:
關鍵定義
BlastRADIUS (CVE-2024-3596)
RADIUS (RFC 2865) 中一個嚴重的協定級安全性漏洞,攻擊者能利用 MD5 選擇前綴碰撞技術來偽造身分驗證回應。
於 2024 年 7 月披露,影響在 UDP 上執行未加密 RADIUS 身分驗證的企業網路基礎設施。
Message-Authenticator (Attribute 80)
RFC 2869 中定義的 RADIUS 標頭屬性,使用 HMAC-MD5 計算整個 RADIUS 封包的數位簽章。
強制執行 Attribute 80 可阻擋 BlastRADIUS 攻擊,因為 HMAC-MD5 在密碼學上對選擇前綴碰撞操縱具有免疫力。
Response Authenticator
RFC 2865 RADIUS 封包標頭中的 16 位元組欄位,透過對請求驗證碼、屬性以及共用秘密進行 MD5 摘要計算而得。
接收端基地台依賴此摘要來驗證封包真實性,而 BlastRADIUS 正是利用了這一點。
RADSEC (RADIUS over TLS)
一項 RFC 6614 標準,將 RADIUS 身分驗證封包封裝在連接埠 2083 上的加密 TLS 1.3 TCP 串流中。
防止在基地台與 RADIUS 伺服器之間不受信任的 WAN 連結上發生中間人封包攔截。
EAP-TLS
可延伸驗證協定 - 傳輸層安全。一項使用 X.509 數位憑證的 IEEE 802.1X 雙向身分驗證標準。
經 NIST 與 ISO 27001 框架推薦,作為取代舊型 PAP/CHAP RADIUS 身分驗證的主要方案。
範例
網路管理員在 RADIUS 伺服器上啟用強制執行之前,要如何驗證現有的無線基地台與交換器是否已強制執行 Message-Authenticator?
若要稽核 Message-Authenticator 合規性且不中斷運作中的 WiFi 存取:
- 封包擷取稽核:在 RADIUS 伺服器介面(UDP 連接埠 1812)上執行 Wireshark 或
tcpdump以擷取傳入的Access-Request封包:tcpdump -i eth0 -n port 1812 -w radius_audit.pcap。 - 屬性篩選器檢查:透過
radius.Message_Authenticator篩選擷取到的封包。確認每種用戶端硬體類型(基地台、交換器、無線控制器)在初始請求中皆包含 Attribute 80。 - 廠商原則測試:在將全域強制執行套用到執行中的 FreeRADIUS、Cisco ISE 或 Microsoft NPS 伺服器之前,先在單一測試 RADIUS 用戶端設定檔上啟用 Message-Authenticator 要求。
多站點場域營運商在規劃零信任 EAP-TLS 遷移時,如何升級舊版 FreeRADIUS 安裝以阻擋 BlastRADIUS?
雙階段的補救計劃可維持網路營運連續性:
- 階段 1 (立即強化):將 FreeRADIUS 更新至 3.0.27 或 3.2.5 版本。編輯
clients.conf將require_message_authenticator = yes進行設定,並更新radiusd.conf以拒絕未經身分驗證的封包。 - 階段 2 (架構升級):在分支機構基地台部署 RADSEC 代理伺服器,將 RADIUS 流量封裝於 TLS 1.3 通道(TCP 連接埠 2083)中,並將 Purple Cloud RADIUS 與企業裝置的自動化 SCEP 註冊進行整合。
練習題
Q1. 為什麼 MD5 選擇前綴碰撞能讓攻擊者在不知道共用秘密的情況下繞過 RADIUS 身分驗證?
提示:重點在於無線基地台如何驗證 MD5 Response Authenticator 摘要。
查看標準答案
在 RFC 2865 RADIUS 中,Access-Reject 與 Access-Accept 封包摘要取決於封包內容與共用金鑰組合後的 MD5 雜湊值。具有中間人攻擊權限的攻擊者會在轉發 Access-Request 之前,將碰撞前綴插入代理狀態屬性中。當伺服器回傳 Access-Reject 時,攻擊者會將封包代碼修改為 Access-Accept。由於 MD5 選擇前綴碰撞(chosen-prefix collision)會針對不同的輸入產生相同的雜湊輸出摘要,因此存取點會驗證該偽造的 Access-Accept 為真,而完全不需要知道共用金鑰。
Q2. 哪些 RADIUS 驗證方法容易受到 BlastRADIUS 的威脅,而哪些方法在密碼學上具有免疫力?
提示:區分透過 UDP 運作的舊版 PAP/CHAP,與封裝在 TLS 中的 EAP 協定。
查看標準答案
依賴透過 UDP 傳輸 PAP、CHAP 和 MS-CHAP 的 RADIUS 驗證模式很容易受到攻擊,因為它們直接依賴 MD5 回應驗證器(Response Authenticator)的驗證。EAP-TLS、PEAP 和 EAP-TTLS 對 BlastRADIUS 具有免疫力,因為 EAP 在用戶端與伺服器之間建立了獨立的密碼學 TLS 工作階段,繞過了對舊版 RADIUS 回應驗證器摘要進行身分驗證的依賴。
繼續閱讀本系列
網路管理員指南:如何為訪客 WiFi 設定 RADIUS 驗證
為網路管理員提供部署訪客 WiFi RADIUS 驗證的全面技術參考。涵蓋架構、不限廠商的設定步驟、安全最佳實作,以及常見部署失敗的疑難排解。
為訪客與員工 WiFi 網路配置 RADIUS 驗證
本技術參考指南概述了企業訪客和員工 WiFi 網路的 RADIUS 驗證架構、配置與部署。它為網路架構師和 IT 經理提供了構建安全、可擴展的無線存取控制系統所需的確切協定、安全標準與疑難排解方法。
Passpoint and OpenRoaming: 完整指南
本技術參考指南針對企業 WiFi 網路中的 Passpoint (Hotspot 2.0) 和 WBA OpenRoaming 架構提供全面分析。內容詳述了建立安全、無摩擦的訪客連線所需的底層驗證協定、架構元件和部署策略。網路架構師和 IT 領導者將學習如何設計、實作這些標準並進行疑難排解,以便在維持企業級安全性的同時,消除手動登入的障礙。
對於您的特定設置有任何疑問嗎?
我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。