Blast-RADIUS(CVE-2024-3596)通訊協定詐騙緩解

簡介

2024年7月7日，安全研究人員披露了RADIUS協定中的以下漏洞：CVE-2024-3596:RFC 2865下的RADIUS協定易受路徑上攻擊者的偽造攻擊，攻擊者可以利用針對MD5響應身份驗證器簽名的選擇字首衝突攻擊，將任何有效的響應（訪問接受、訪問拒絕或訪問質詢）修改為任何其他響應。他們在https://www.blastradius.fail/pdf/radius.pdf上發佈了一篇論文，詳細描述了他們的發現，這篇論文證明了對不使用Message-Authenticator屬性的流的響應偽造是成功的。

有關受此漏洞影響的思科產品的最新清單以及包含修復程式的版本，請訪問：https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-radius-spoofing-july-2024-87cCDwZ3。本文將介紹一般緩解技術，以及它們如何適用於某些（但不是全部）思科產品，如需詳細資訊，請參閱個別產品檔案。作為思科的旗艦RADIUS伺服器，身份服務引擎將詳細介紹。

背景

此攻擊利用MD5中利用衝突的MD5選擇字首攻擊，使得攻擊者能夠在修改響應資料包的現有屬性的同時，向RADIUS響應資料包新增其他資料。演示的示例是將一個RADIUS訪問拒絕更改為RADIUS訪問接受的能力。可行的原因是RADIUS預設不包括封包中所有屬性的雜湊值。RFC 2869確實新增了Message-Authenticator屬性，但當前僅要求使用EAP協定時包含它，這意味著對於任何非EAP交換(其中RADIUS客戶端(NAD)不包含Message-Authenticator屬性)，都可能出現CVE-2024-3596中描述的攻擊。

緩解

消息驗證器

1)RADIUS客戶端必須包括Message-Authenticator屬性。

當網路接入裝置(NAD)在Access-Request中包含Message-Authenticator屬性時，身份服務引擎將在所有版本中生成的Access-Accept、Access-Challenge或Access-Reject資料包中包含Message-Authenticator。

2)RADIUS伺服器必須強制接收Message-Authenticator屬性。

只在Access-Request中包括Message-Authenticator是不夠的，因為攻擊使得在將Message-Authenticator轉發到RADIUS伺服器之前可以從Access-Request中將其刪除。RADIUS伺服器也必須要求NAD在Access-Request中包括Message-Authenticator。這不是身份服務引擎的預設設定，但可以在允許的協定級別（在策略集級別應用）啟用。Allowed Protocols配置下的選項是「Require Message-Authenticator」 for all RADIUS Requests」：

Identity Services Engine中的Allowed Protocols選項

與Allowed Protocols配置需要Message-Authenticator但Access-Request不包含Message-Authenticator屬性的策略集匹配的身份驗證，ISE將丟棄該身份驗證：

在需要由RADIUS伺服器發出之前，必須驗證NAD是否正在傳送消息驗證器，因為這不是一個協商屬性，預設情況下由NAD傳送或配置為傳送它。Message-Authenticator不是ISE報告的屬性之一，資料包捕獲是確定NAD/Use Case是否包括Message-Authenticator的最佳方法。ISE在Operations -> Troubleshoot -> Diagnostic Tools -> General Tools -> TCP Dump下內建資料包捕獲功能。請記住，來自同一NAD的不同用例可以包括或不包括消息驗證器。

以下是包含Message-Authenticator屬性的Access-Request的捕獲示例：

Radius access-request中的message-authenticator屬性

以下是不包含Message-Authenticator屬性的Access-Request的示例捕獲：

使用TLS/IPSec加密

保護RADIUS的最有效的長期解決方案是加密RADIUS伺服器和NAD之間的流量。與僅依賴MD5-HMAC派生的消息驗證器相比，這增加了隱私性和更強的加密完整性。如果可在RADIUS伺服器和需要加密的裝置之間使用其中任一裝置，則取決於支援加密方法的兩端。

業界對RADIUS的TLS加密所使用的廣泛術語包括：

•  「RadSec」 — 指RFC 6614
• "RadSec TLS" — 引用RFC 6614
• "RadSec DTLS" — 引用RFC 7360

必須以受控的方式推廣加密，因為TLS加密有效能開銷以及證書管理注意事項。證書也必須定期更新。

使用DTLS的RADIUS

RFC 7360將資料包傳輸層安全性(DTLS)定義為RADIUS的傳輸層，此層使用憑證對RADIUS伺服器進行相互驗證，然後NAD使用TLS通道加密完整的RADIUS封包。傳輸方法仍為UDP，需要在RADIUS伺服器和NAD上部署證書。請記住，通過DTLS部署RADIUS時，必須嚴格管理證書到期和替換，以防止過期的證書中斷RADIUS通訊。ISE支援ISE到與非的DTLS通訊，因為RADIUS代理或RADIUS令牌伺服器不支援通過DTLS的ISE 3.4 Radius。許多思科裝置(例如運行IOS-XE®的交換機和無線控制器)也支援使用DTLS的RADIUS。

使用TLS的RADIUS

RADIUS的傳輸層安全(TLS)加密由RFC 6614定義，將傳輸變更為TCP並使用TLS完全加密RADIUS資料包。通常以eduroam服務為例。自ISE 3.4起，不支援使用TLS的RADIUS，但許多思科裝置支援使用NAD，例如運行IOS-XE的交換機和無線控制器。

IPSec

身份服務引擎對ISE和NAD之間的IPSec隧道提供本地支援，同時支援終端IPSec隧道。這是一個很好的選項，其中不支援RADIUS over DTLS或RADIUS over TLS，但應謹慎使用，因為每個ISE策略服務節點僅支援150個隧道。ISE 3.3及更高版本不再需要用於IPSec的許可證，它現在在本地可用。

部分緩解

RADIUS分段

將RADIUS流量分段到管理VLAN和安全的加密鏈路，例如可以通過SD-WAN或MACSec提供。這種策略不會使攻擊風險為零，但可以大大降低漏洞的攻擊面。當產品推出郵件驗證器要求或DTLS/RadSec支援時，這可以作為一種很好的停止間隙措施。此漏洞需要攻擊者成功通過RADIUS通訊進行中間人(MITM)，因此，如果攻擊者無法通過該流量進入網段，則無法進行攻擊。這僅是部分緩解的原因是，網路配置錯誤或網路部分受到危害可能暴露RADIUS流量。

如果無法分段RADIUS流量或對其加密，則可以實施其他功能來阻止高風險網段上成功的MITM，例如：IP源保護、動態ARP檢測和DHCP監聽。還可以利用基於認證流型別的其它認證方法，例如TACACS+、SAML、LDAPS等。

身份服務引擎漏洞狀態

下表介紹從ISE 3.4開始可用於使身份驗證流針對Blast-RADIUS進行保護的功能。要重述，以下三項必須適用於僅使用消息驗證器而不使用DTLS/RadSec/IPSec加密的流，以便該流不易受攻擊：
1)網路接入裝置必須傳送Access-Request中的Message-Authenticator屬性。

2)RADIUS伺服器必須要求Access-Request中的Message-Authenticator屬性。

3)RADIUS伺服器必須使用Access-Challenge、Access-Accept和Access-Reject中的Message-Authenticator屬性進行響應。

請參閱CSCwk67747，該工具在ISE充當RADIUS客戶端時跟蹤更改以關閉漏洞。

作為RADIUS伺服器的ISE

作為RADIUS客戶端的ISE

作為RADIUS客戶端更新的ISE

在發行版中包括ISE作為RADIUS客戶端的增強功能：3.1修補程式10、3.2修補程式8、3.3修補程式5、3.4修補程式2、3.5及更高版本，通過CSCwk67747獲得。在修補程式或升級後，建立的任何新資源都將預設採用更安全的新配置。必須修改現有資源，才能使用更安全的補丁或升級後配置。新增了一個新覈取方塊：「響應時需要消息驗證器」（如果選中），則此驗證器具有雙重用途：ISE將始終傳送消息身份驗證器，如果收到沒有消息身份驗證器的響應，ISE將拒絕身份驗證。行為如下：

RADIUS權杖伺服器

在RADIUS令牌伺服器配置的Authentication頁籤下新增了一個新覈取方塊：「Message Authenticator Required On Response」：

選中此框後，如果收到不帶消息驗證器的RADIUS響應，則會將故障消息記錄到詳細的驗證日誌中，該日誌可通過「即時日誌」或RADIUS驗證報告訪問：

**附註：整體身份驗證仍可基於策略配置通過，通過身份驗證可能與意外策略匹配。

外部RADIUS伺服器

在外部RADIUS伺服器配置中新增了一個新覈取方塊：「響應時需要消息驗證器」：

選中此框後，如果收到不帶消息驗證器的RADIUS響應，則會將故障消息記錄到詳細的驗證日誌中，該日誌可通過「即時日誌」或RADIUS驗證報告訪問：

**附註：整體身份驗證仍可基於策略配置通過，通過身份驗證可能與意外策略匹配。

授權變更(CoA)

在授權變更(CoA)抽屜下對網路裝置配置檔案進行了CoA更改：

「Send Message-Authenticator」選項是以前的一項功能，新選項是「Message-Authenticator Required on response。無論是否選中「傳送消息驗證器」，如果選中了響應所需的消息驗證器，ISE都將傳送「消息驗證器」屬性。「Send Message-Authenticator」保留用於現有配置。如果NAD在CoA響應中未包括消息驗證器，則將在即時日誌中提供的詳細驗證報告中看到以下錯誤：

 **附註：即使在ISE上記錄故障，CoA也可能在NAD上成功，因為NAD可能已經處理了CoA，但在響應中不包括消息驗證器。

無法修改預設的「思科提供的」網路裝置配置檔案，以使用新選項「網路裝置配置檔案」可以複製，並在複製的配置檔案上啟用設定。然後，需要為網路裝置分配新建立的網路裝置配置檔案。這樣做是為了通過引入ISE和現有NAD之間的不相容性來降低在補丁或升級後導致網路中斷的風險。如果使用的是現有的使用者定義配置檔案，則建議複製該配置檔案，並在更改現有的網路裝置配置檔案之前，使用該配置檔案測試網路上每種裝置型別的至少1種。