深入理解與強化 RADIUS 以防範 MD5 碰撞攻擊

執行摘要

RADIUS 協定自 1991 年以來一直是企業網路驗證的基石，但它存在一個關鍵且目前在實務上可被利用的漏洞。該漏洞於 2024 年 7 月披露，編號為 CVE-2024-3596，被稱為「Blast-RADIUS」。此缺陷允許位於 RADIUS 用戶端和伺服器之間的「中間人」（MitM）攻擊者偽造有效的驗證核准——將合法的「Access-Reject」轉換為「Access-Accept」——而無需知道使用者的密碼或共用的 RADIUS 密鑰。該攻擊利用了 MD5 選擇前綴碰撞技術，利用現代硬體，可在數分鐘內完成執行。

對於場域營運商和企業 IT 團隊而言，業務風險是直接的：獲得未授權網路存取權限的攻擊者可以在基礎設施中進行橫向移動、存取銷售點（POS）系統、外洩顧客資料，並觸發 PCI DSS 和 GDPR 的合規性違規。在套用修補程式並規劃架構變更之前，每個使用 PAP、CHAP 或 MS-CHAP 驗證模式執行 RADIUS/UDP 的組織都會暴露在風險之中。立即的緩解措施是在所有 RADIUS 流量上強制執行 Message-Authenticator 屬性，這是所有主要廠商都提供、且低干擾的設定變更。策略性的因應措施則是逐步遷移至 EAP-TLS 和 RADIUS over TLS (RADSEC)。

技術深度剖析

RADIUS 協定及其密碼學歷史遺產

在 RFC 2865 中標準化的 RADIUS（遠端用戶撥入驗證服務）是在網路安全需求根本不同的時代設計的。該協定在 UDP 上運作，並在 RADIUS 用戶端（通常是無線基地台或網路存取伺服器）與 RADIUS 伺服器之間使用共用密鑰，以提供一定程度的訊息完整性。具體而言，伺服器回應是使用稱為 Response Authenticator 的結構進行「驗證」，其計算方式如下：

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

這種結構從未是合適的訊息鑑別碼（MAC）。它早於 1997 年標準化的 HMAC，而 HMAC 的推出正是為了解決原始雜湊型 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：立即強化（第 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 不同，這種結構不易受到選擇前綴碰撞攻擊（chosen-prefix collision attack）的影響，因為 HMAC 結構將雜湊值與共享金鑰綁定，從而防止攻擊者製造出有效的偽造。將用戶端和伺服器設定為需要此屬性，並拒絕任何不包含此屬性的訊息，即可封鎖此直接攻擊媒介。

對於 FreeRADIUS，這涉及在 clients.conf 檔案中設定 require_message_authenticator = yes。對於 Microsoft NPS，對應的原則是透過「網路原則」設定來強制執行。對於 Cisco ISE，該設定位於驗證原則下的 RADIUS 用戶端設定中。請參閱您廠商針對 CVE-2024-3596 的特定安全性建議，以取得確切的設定步驟。

階段 2：驗證現代化（第 1-3 個月）

中期目標是將 WiFi 驗證從舊有的 PAP/CHAP 模式遷移到基於 EAP 的方法。對於企業級 WiFi 環境，建議的路徑是搭配 EAP-TLS 的 WPA3-Enterprise。這需要部署公開金鑰基礎架構 (PKI) 以發行裝置和/或使用者憑證、設定您的 RADIUS 伺服器以驗證這些憑證，並為用戶端裝置配置適當的憑證和 RADIUS 伺服器信任錨點。

對於憑證部署較為複雜的環境（例如裝置流動率高或實施 BYOD 政策的場域），PEAP 搭配 MSCHAPv2 提供了一個可接受的過渡方案，前提是必須將用戶端設定為驗證 RADIUS 伺服器憑證。若沒有伺服器憑證驗證，PEAP 很容易受到惡意存取點（rogue access point）攻擊。有線基礎架構應同時實施 IEEE 802.1X 基於連接埠的存取控制，以確保整個網路中驗證政策的一致性。

第三階段：傳輸層安全（第 3 至 12 個月）

長期的架構目標是使用 RADIUS over TLS (RADSEC)（於 RFC 6614 中標準化）將所有 RADIUS 流量封裝在 TLS 隧道中。RADSEC 以 TCP 取代 UDP，並將整個 RADIUS 工作階段包裝在雙向驗證的 TLS 連線中。這為所有驗證流量提供了機密性、完整性和重放攻擊防護，由於傳輸層本身在密碼學上是安全的，因此 MD5 回應驗證器（Response Authenticator）將不再重要。

RADSEC 在分散式部署中特別有價值，例如連鎖飯店、零售網路或體育場館環境，在這些環境中，RADIUS 流量可能會跨越中間網路區段。IETF 目前正在將 RADIUS over TLS 和 DTLS 推動至標準軌道狀態，這反映了業界對於在敏感部署中應淘汰 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 憑證的通用名稱 (Common Name) 與預期的用戶端識別碼不相符，則可能會發生共用金鑰不相符。請確保憑證主體名稱與伺服器上設定的 RADIUS 用戶端 IP 位址或主機名稱一致。

針對無法立即修補之環境的風險緩解

對於無法立即修補的環境（例如舊版工業控制系統或嵌入式網路裝置），可以透過實施嚴格的網路存取控制來部分緩解風險，限制哪些主機能與 RADIUS 伺服器進行通訊，從而減少 MitM 攻擊者攔截流量的機會。這僅是一項臨時措施；必須建立修補和更換時程表。

ROI 與業務影響

量化風險

從資料外洩成本與合規責任的角度來看，強化 RADIUS 的商業效益顯而易見。在飯店或零售環境中，若被成功利用 Blast-RADIUS 漏洞，攻擊者將能存取企業網路，進而可能觸及銷售點（POS）系統、顧客資料庫以及後勤基礎設施。根據產業基準，餐旅業資料外洩的平均成本超過 300 萬英鎊，且依據 GDPR 規範，監管罰鍰最高可達全球年度總營業額的 4%。

對於適用 PCI DSS 規範的組織而言，若因網路驗證失敗而導致持卡人資料外洩，可能會引發強制性的鑑識調查、發卡品牌罰鍰，甚至可能喪失信用卡交易處理權限——這些成本遠遠超過導入 EAP-TLS 與 RADSEC 所需的投資。

實作成本基準

下表針對典型場域環境，提供三階段強化路線圖的預估成本與工作量估算：

安全性之外的營運效益

遷移至 EAP-TLS 與 RADSEC 除了能強化安全性，還能帶來顯著的營運效益。基於憑證的驗證方式消除了在龐大裝置群中管理與定期變更共用密碼的營運負擔。WPA3-Enterprise 提高了高密度環境中的連線可靠性——這對於有數百台裝置競爭驗證的體育場館與會議中心而言，是可衡量的實質效益。此外，在高度延遲或易丟包的網路環境中，RADSEC 的 TCP 傳輸提供了比 UDP 更好的可靠性，進而提升終端使用者的驗證體驗。