跳至主要內容

強化 RADIUS 以抵禦 MD5 碰撞攻擊 (BlastRADIUS)

緩解 CVE-2024-3596 BlastRADIUS 攻擊。強制執行 RADIUS Message-Authenticator、修補 FreeRADIUS 與 Cisco ISE,並遷移至 802.1X EAP-TLS。

作者:Iain Jewitt發佈於 更新於
📖 8 分鐘閱讀638 字數2 範例2 練習題5 關鍵定義

Video overview

收聽此指南

查看播客逐字稿
歡迎來到 Purple 技術簡報。我是今天的主持人,Purple 的資深技術內容策略師。今天,我們將探討一個對於運行企業級 WiFi 的所有組織而言都至關重要且迫在眉睫的問題:在一個擁有 30 年歷史的協定中,新發現了一個具備實用性的弱點,這可能讓攻擊者直接穿透您的數位前門。我們所指的是 RADIUS 協定以及被稱為 Blast-RADIUS 的 MD5 碰撞攻擊。 對於餐旅業、零售業和大型公共場館的 IT 經理、網路架構師和 CTO 等受眾而言,這不僅僅是一個理論上的問題。這對您的網路完整性、資料安全和合規性構成直接威脅。在接下來的十分鐘內,我們將解析此漏洞是什麼、它是如何運作的,最重要的是,為您提供清晰、可行的緩解策略路線圖。無論您是負責一間擁有 200 間客房的飯店、全國連鎖零售店還是擁有 60,000 個座位的體育場,本簡報都與您在本季度需要做出的決策直接相關。 讓我們首先了解一些背景資訊。RADIUS - 遠端用戶撥入驗證服務 - 設計於 1991 年撥接上網時代。它是一個用戶端 - 伺服器協定,負責處理網路存取的驗證、授權和計費。當工作人員或裝置連線到您的企業 WiFi 時,存取點會充當 RADIUS 用戶端,並向中央 RADIUS 伺服器發送驗證請求。伺服器檢查認證資訊,並回應 Access-Accept 或 Access-Reject。三十多年來,這種交換一直是企業網路安全的骨幹。 問題在於 RADIUS 的設計早於現代加密標準的出現。該協定使用 MD5 雜湊演算法對伺服器回應進行基本的完整性檢查 - 這個欄位稱為 Response Authenticator。MD5 首次在 2004 年被證實在密碼學上已被破解。然而到了 2024 年,RADIUS 仍在使用它。業界深知 MD5 很脆弱,只是該協定從未更新。 現在讓我們進行深入的技術剖析。Blast-RADIUS 攻擊(正式編號為 CVE-2024-3596)於 2024 年 7 月由波士頓大學、加州大學聖地牙哥分校、荷蘭國家數學與計算機科學研究中心 (CWI Amsterdam) 和 Microsoft Research 的研究團隊共同披露。它結合了協定層級的漏洞與 MD5 選擇前綴碰撞攻擊 - 至關重要的是,透過大幅提升運算速度,使此攻擊在實務上能即時進行。運作原理如下。中間人攻擊者會將自己定位在 RADIUS 用戶端(您的無線基地台)與 RADIUS 伺服器之間的網路路徑上。當使用者嘗試進行驗證時,攻擊者會攔截 Access-Request 封包,並在此請求中植入一個精心製作的惡意屬性。此屬性旨在引發數學碰撞:亦即兩種不同的輸入產生相同 MD5 雜湊值的情況。攻擊者會預先計算此碰撞,使來自伺服器的合法 Access-Reject 回應之 MD5 雜湊值,與攻擊者構建的偽造 Access-Accept 回應之 MD5 雜湊值相匹配。當伺服器傳回其 Access-Reject 時,攻擊者會將其替換為偽造的 Access-Accept。RADIUS 用戶端會檢查 Response Authenticator,並因 MD5 雜湊值相符而判定其有效,進而授予網路存取權限。 攻擊者完全不需要知道使用者的密碼,也不需要知道 RADIUS 用戶端與伺服器之間的共用金鑰。他們只需利用 MD5 的數學漏洞,就能讓偽造的回應看起來合法。而且利用現代硬體,計算出所需的 MD5 碰撞花費不到五分鐘。這並非理論上的攻擊,而是如今在操作上完全可行的威脅。 此漏洞會影響所有在 UDP 上使用 PAP(密碼驗證協定)、CHAP 和 MS-CHAP 驗證模式的 RADIUS 部署。這些模式在企業環境中極為常見,特別是在舊版部署中。唯一不受影響的驗證模式是使用 EAP(可延伸驗證協定)的模式,因為 EAP 會建立獨立於 MD5 Response Authenticator 之外的專屬密碼學通道。 讓我以具體條款來解說業務風險。以一家連鎖飯店為例,獲取企業網路未授權存取權限的攻擊者可以進行橫向移動,以接觸物業管理系統、存取房客記錄、接觸端點銷售系統(POS)終端,並可能外洩付款卡資料。餐旅業資料外洩的平均成本超過三百萬英鎊。在 GDPR 規範下,涉及房客個人資料的外洩事件最高可處以全球年度總營業額百分之四的罰鍰。在 PCI-DSS 規範下,涉及持卡人資料的外洩可能導致強制性的鑑識調查、發卡品牌罰鍰,以及可能喪失付款處理權限。這對財務與信譽帶來的風險極其重大。 接下來是實施建議。您該如何防範此威脅?因應對策分為兩個層面:立即強化與長期現代化。 最直接的行動是針對 CVE-2024-3596 套用設備商修補程式。每個主要的 RADIUS 設備商 - Cisco ISE、Microsoft NPS、FreeRADIUS、Juniper、Aruba、Ruckus - 都已發布更新。除了套用修補程式外,關鍵的設定變更是對所有 RADIUS 用戶端和伺服器強制執行 Message-Authenticator 屬性。此屬性定義於 RFC 2869 中,可對整個 RADIUS 封包提供基於 HMAC 的完整性檢查。與 Response Authenticator 不同,HMAC 結構不會受到選擇前綴碰撞攻擊的威脅。將您的基礎架構設定為需要此屬性 - 並拒絕任何未攜帶該屬性而傳入的訊息 - 即可封鎖最直接的攻擊媒介。對於 FreeRADIUS,這代表在您的用戶端設定檔中將 require_message_authenticator 設定為 yes。對於 Microsoft NPS,這是網路原則設定中的一項原則設定。這是一項低干擾的變更,通常可以在維護視窗內部署。 然而,強制執行 Message-Authenticator 只是權宜之計,而非根本解決方案。長期的策略性因應措施是轉移至基於 EAP 的驗證。黃金標準是採用 EAP-TLS 的 WPA3-Enterprise。EAP-TLS 使用基於憑證的雙向驗證 - 用戶端裝置和 RADIUS 伺服器都必須出示來自受信任憑證授權單位的有效數位憑證。這完全消除了共享金鑰,移除了對 MD5 的依賴,並提供了一種不受 Blast-RADIUS 所代表之整類攻擊影響的安全性等級。 對於部署完整 PKI 基礎架構較為複雜的環境 - 特別是裝置流動率高或實施員工自攜裝置(BYOD)原則的場所 - 只要用戶端已設定為驗證 RADIUS 伺服器憑證,採用 MSCHAPv2 的 PEAP 便是可以接受的過渡步驟。如果沒有進行伺服器憑證驗證,PEAP 就容易受到惡意無線基地台攻擊,這是另一種但同樣嚴重的風險。 現代化藍圖的最後階段是部署 RADIUS over TLS,即 RADSEC。RADSEC 將所有 RADIUS 流量封裝在雙向驗證的 TLS 工作階段中,為整個驗證交換提供完整的機密性與完整性。這使 Blast-RADIUS 等傳輸層攻擊變得不可能,因為沒有未加密的 RADIUS 流量可供攔截。RADSEC 在分散式環境中特別有價值 - 例如連鎖飯店、零售網路、體育場館 - 這些環境中的 RADIUS 流量可能會在存取點與中央驗證伺服器之間跨越多個網路區段。 讓我們進入快速問答環節。 問題一:我們使用 EAP。我們安全嗎?如果您使用的是 EAP-TLS、PEAP 或 EAP-TTLS,您就不會受到特定的 Blast-RADIUS MD5 碰撞攻擊的威脅。然而,您仍應套用設備商修補程式作為縱深防禦措施,並應稽核您的設定,以確保所有用戶端都強制執行伺服器憑證驗證。 問題二:我們的 RADIUS 流量位於專用的管理 VLAN 中。這能保護我們嗎?這減少了受攻擊面,但並不能消除漏洞。已經入侵管理網路中任何裝置的攻擊者,仍然可以執行中間人攻擊。網路分段是很有價值的防禦層,但必須與強制執行 Message-Authenticator 和 EAP 遷移結合使用。 問題三:立即緩解的難度如何?對於大多數環境而言,強制執行 Message-Authenticator 是一個簡單的設定變更。主要的挑戰在於確保所有網路裝置 - 包括基地台、交換器、控制器 - 都支援該屬性並已將其啟用。在伺服器端強制執行該要求之前,對裝置進行稽核是至關重要的,以避免舊型硬體上出現驗證失敗。 問題四:我能偵測到自己是否受到攻擊嗎?這非常困難。偽造的 Access-Accept 封包對 RADIUS 用戶端來說看似有效,因為 MD5 雜湊值檢驗無誤。您最佳的偵測方法是監控 RADIUS 帳務記錄,以尋找異常的成功驗證 - 例如未預期的裝置類型、與您的資產清單不符的 MAC 位址,或在異常時間的成功登入。將您的 RADIUS 帳務數據與 SIEM 整合以實現自動警報。 總結並概述您的後續步驟。對於任何在 UDP 上執行舊版 RADIUS 驗證的組織而言,Blast-RADIUS 漏洞都是一個嚴重且在實務上可被利用的威脅。該攻擊不需要知道任何憑證,且可在幾分鐘內執行。您的當務之急是稽核您的基礎設施、套用廠商修補程式,並在所有 RADIUS 用戶端和伺服器上強制執行 Message-Authenticator 屬性。您的中期目標是遷移至 EAP-TLS 和 WPA3-Enterprise。您的長期架構目標則是 RADSEC。 在 Purple,我們提供智慧層,協助您了解並保護您場域的 WiFi 網路。我們的平台為您提供可視性,以識別裝置類型、監控驗證模式,並確保在您資產中的每個基地台都有效執行您的安全性原則。 您的行動方案只有三個詞:稽核、修補與現代化。不要讓一個有 30 年歷史的協定成為您安全防護中的最弱環節。感謝您參與本次 Purple 技術簡報。祝您保持安全。

核心系列的一部分:企業級 WiFi 安全指南

Interactive IT Advisor

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.

Architecture Recommendation

Cloud RADIUS (Zero On-Prem Footprint)

Est. Annual Admin Savings£78,580
Maintenance Reduction65%
Profile: Optimal TCO & Low Maintenance
Setup Complexity: Low (No server maintenance)

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.

針對 MD5 碰撞攻擊強化 RADIUS 安全性

執行摘要

定義於 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 易受選擇前綴碰撞的影響,攻擊者會執行以下步驟:

  1. 攔截 Access-Request: 攔截由存取點傳送的合法 Access-Request。
  2. 植入碰撞前綴: 在將請求封包轉發到 RADIUS 伺服器之前,將精心設計的 Proxy-State 屬性插入封包中。
  3. **攔截 Access-Reject:**當 RADIUS 伺服器拒絕驗證嘗試並傳回 Access-Reject 時,攻擊者會攔截該封包。
  4. **偽造 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 的關鍵架構優勢

  1. 免輕觸 802.1X 憑證上線: 自動為託管裝置發行 SCEP 和 EST 憑證,消除手動設定密碼的繁瑣程序。
  2. 內建 RADSEC 代理架構: 透過加密的 TCP 連線保護遠端分部流量,無需建立複雜的站點對站點 IPsec 通道。
  3. 全面的訪客與企業安全: 將企業級 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。

與 RADIUS 安全專家聯絡


常見問題

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 存取:

  1. 封包擷取稽核:在 RADIUS 伺服器介面(UDP 連接埠 1812)上執行 Wireshark 或 tcpdump 以擷取傳入的 Access-Request 封包:tcpdump -i eth0 -n port 1812 -w radius_audit.pcap
  2. 屬性篩選器檢查:透過 radius.Message_Authenticator 篩選擷取到的封包。確認每種用戶端硬體類型(基地台、交換器、無線控制器)在初始請求中皆包含 Attribute 80。
  3. 廠商原則測試:在將全域強制執行套用到執行中的 FreeRADIUS、Cisco ISE 或 Microsoft NPS 伺服器之前,先在單一測試 RADIUS 用戶端設定檔上啟用 Message-Authenticator 要求。
考官評語: 在伺服器端強制執行之前先稽核用戶端功能,可防止舊型網路交換器或舊型 AP 在維護期間被鎖定在外。

多站點場域營運商在規劃零信任 EAP-TLS 遷移時,如何升級舊版 FreeRADIUS 安裝以阻擋 BlastRADIUS?

雙階段的補救計劃可維持網路營運連續性:

  1. 階段 1 (立即強化):將 FreeRADIUS 更新至 3.0.27 或 3.2.5 版本。編輯 clients.confrequire_message_authenticator = yes 進行設定,並更新 radiusd.conf 以拒絕未經身分驗證的封包。
  2. 階段 2 (架構升級):在分支機構基地台部署 RADSEC 代理伺服器,將 RADIUS 流量封裝於 TLS 1.3 通道(TCP 連接埠 2083)中,並將 Purple Cloud RADIUS 與企業裝置的自動化 SCEP 註冊進行整合。
考官評語: 階段 1 以零硬體支出立即防堵 CVE-2024-3596 漏洞利用途徑,而階段 2 則建立了長期加密隔離,以防止 WAN 封包攔截。

練習題

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 回應驗證器摘要進行身分驗證的依賴。

對於您的特定設置有任何疑問嗎?

我們的團隊與超過 80,000 個場域的場域營運商、IT 經理和網路工程師合作。立即預約 20 分鐘的通話,我們將向您展示其他與您相似的用戶是如何解決此問題的。