Blast-RADIUS (CVE-2024-3596)協定偽裝緩解

簡介

2024年7月7日，安全研究人員在RADIUS協定中披露了以下漏洞：CVE-2024-3596：RFC 2865下的RADIUS協定容易受到路徑上攻擊者的偽造攻擊，該攻擊者可以利用針對MD5響應身份驗證器簽名選擇的字首衝突攻擊修改任何有效的響應（Access-Accept、Access-Reject或Access-Challenge）到任何其他響應。他們在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。本文將介紹一般緩解技術以及它們如何應用於某些（但不是全部）思科產品，具體資訊請參閱單個產品文檔。身為Cisco的旗艦級RADIUS伺服器，身份服務引擎將詳細介紹。

背景

此攻擊利用MD5中的衝突進行MD5選擇字首攻擊，使得攻擊者能夠在修改響應資料包的現有屬性的同時，向RADIUS響應資料包增加附加資料。一個示例展示了將RADIUS Access-Reject更改為RADIUS Access-Accept的能力。可行的原因是RADIUS預設不包含封包中所有屬性的雜湊。RFC 2869確實增加了消息驗證器屬性，但是當前僅當使用EAP協定時才需要包括它，這意味著對於任何RADIUS客戶端(NAD)不包含消息驗證器屬性的非EAP交換，都可能發生CVE-2024-3596中描述的攻擊。

緩解

消息驗證器

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

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

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

僅僅在訪問請求中包含消息身份驗證器是不夠的，因為攻擊使得可以在將消息身份驗證器轉發到RADIUS伺服器之前從訪問請求中刪除該消息身份驗證器。RADIUS伺服器還必須要求NAD在Access-Request中包含消息身份驗證器。這不是身份服務引擎的預設設定，但可以在允許的協定級別（在策略集級別應用）啟用。「Allowed Protocols」配置下的選項為「Require Message-Authenticator」（對於所有RADIUS請求）：

身份服務引擎中的「允許的協定」選項

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

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

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

Radius access-request中的Message-authenticator屬性

以下是不包含Message-Authenticator屬性的訪問請求的示例捕獲：

使用TLS/IPSec加密

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

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

•  「RadSec」-指RFC 6614
• 「RadSec TLS」-指RFC 6614
• 「RadSec DTLS」-指RFC 7360

由於存在TLS加密的效能開銷以及證書管理注意事項，因此以可控的方式推廣加密非常重要。證書也必須定期更新。

使用DTLS的RADIUS

RFC 7360將資料包傳輸層安全(DTLS)定義為RADIUS的傳輸層，它使用證書對RADIUS伺服器進行相互身份驗證，然後使用TLS隧道加密完整的RADIUS資料包。傳輸方法仍為UDP，並且需要在RADIUS伺服器和NAD上部署證書。請記住，在透過DTLS部署RADIUS時，必須嚴格管理證書到期和替換，以防止過期的證書中斷RADIUS通訊。ISE支援DTLS進行ISE到需要通訊，自ISE 3.4 Radius over DTLS不受RADIUS-Proxy或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屬性做出響應。

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

ISE作為RADIUS伺服器

作為RADIUS客戶端的ISE