Blast-RADIUSプロトコルスプーフィングの軽減(CVE-2024-3596)

はじめに

このドキュメントでは、Blast RADIUSプロトコルのスプーフィングを緩和する方法について説明します。

概要

2024年7月7日、セキュリティ研究者がRADIUSプロトコルの脆弱性を公開しました。CVE-2024-3596:RFC 2865のRADIUSプロトコルは、MD5応答オーセンティケータシグニチャに対するchosen-prefix collision攻撃を使用して、他の応答に対する有効な応答（Access-Accept、Access-Reject、またはAccess-Challenge）を変更できるパス攻撃者によるによる偽造攻撃ののの影響ををを受受受受受受けやすいです。同社は、このホワイトペーパーに自身の調査結果を詳述した論文を発表しました。このホワイトペーパーでは、Message-Authenticator属性を使用しないフローに対する応答偽造が成功したことを示しています。

この脆弱性の影響を受けるシスコ製品と修正を含むバージョンの最新リストについては、RADIUSプロトコルスプーフィングの脆弱性(Blast-RADIUS):2024年7月を参照してください。この記事では、一般的な緩和策と、すべてのシスコ製品ではなく一部の製品に対して緩和策がどのように適用されるかについて説明します。具体的には、個々の製品ドキュメントを参照する必要があります。シスコの主力製品であるRADIUSサーバであるCisco Identity Service Engineについては、さらに詳しく説明します。

背景

この攻撃は、MD5のコリジョンを利用する、MD5選択プレフィクス攻撃を利用します。これにより、攻撃者は応答パケットの既存の属性を変更しながら、RADIUS応答パケットにデータを追加できます。例として、RADIUS Access-RejectをRADIUS Access-Acceptに変更する機能が示されています。これが可能なのは、RADIUSではデフォルトでパケット内のすべての属性のハッシュが含まれていないためです。RFC 2869ではMessage-Authenticator（Mオーセンティケータ）属性が追加されていますが、この属性は現在、EAPプロトコルを使用する場合にのみ含める必要があります。つまり、RADIUSクライアント(NAD)にMessage-Authenticator（Mオーセンティケータ）属性が含まれていない非EAP交換に対しては、CVE-2024-3596で説明されている攻撃が可能できます。

緩和

メッセージ認証者

1.- RADIUSクライアントはMessage-Authenticator属性を含める必要があります。

ネットワークアクセスデバイス(NAD)がAccess-RequestにMessage-Authenticator属性を含めると、Cisco Identity Services Engineは、結果としてもたらされるAccess-Accept、Access-Challenge、またはAccess-RejectパケットにすべてのバージョンのMessage-Authenticatorを含めます。

2.- RADIUSサーバは、Message-Authenticator属性の受信を強制する必要があります。

攻撃によって、RADIUSサーバに転送される前にアクセス要求からメッセージオーセンティケータを削除することが可能になるため、アクセス要求にメッセージオーセンティケータを含めるだけでは不十分です。RADIUSサーバでは、NADがAccess-RequestにMessage-Authenticatorを含める必要もあります。これはCisco Identity Services Engine(ISE)のデフォルトではありませんが、許可されたプロトコルレベルで有効にできます。これはポリシーセットレベルで適用されます。Allowed Protocols設定の下のオプションは、すべてのRADIUS要求に対してRequire Message-Authenticatorです。

Identity Services EngineのAllowed Protocolsオプション

Allowed Protocols設定にはMessage-Authenticatorが必要であるのに、Access-RequestにMessage-Authenticator属性が含まれていないポリシーセットと一致する認証は、ISEによってドロップされます。

NADがRADIUSサーバによって要求される前にメッセージオーセンティケータを送信しているかどうかを確認することが重要です。これはネゴシエートされた属性ではありません。メッセージオーセンティケータを送信するかどうかはNADが決定します（デフォルトで送信するか、またはNADを送信するように設定します）。メッセージオーセンティケータは、ISEによって報告される属性の1つではありません。NADまたはユースケースにメッセージオーセンティケータが含まれているかどうかを判断するには、パケットキャプチャが最適な方法です。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サーバとNADの間でこれらのいずれかを使用できる場合は、暗号化方式をサポートする両側によって異なります。

RADIUSのTLS暗号化に業界で使用される幅広い用語は次のとおりです。

• RadSec:RFC 6614を指します
• RadSec TLS:RFC 6614を指します
• RadSec DTLS:RFC 7360を指します

TLS暗号化にはパフォーマンス上のオーバーヘッドがあり、証明書管理の考慮事項もあるため、制御された方法で暗号化を展開することが重要です。証明書も定期的に更新する必要があります。

DTLS上のRADIUS

RADIUSのトランスポート層としてのDatagram Transport Layer Security(DTLS)はRFC 7360で定義されています。RFC 7360では、証明書を使用してRADIUSサーバとNADが相互に認証し、TLSトンネルを使用して完全なRADIUSパケットが暗号化されます。転送方式はUDPのままであり、証明書をRADIUSサーバとNADの両方に展開する必要があります。DTLS経由でRADIUSを導入する場合、期限切れの証明書によってRADIUS通信が中断されないように、証明書の期限切れと交換を綿密に管理することが不可欠です。ISE 3.4の時点で、ISEはISEからNADへの通信のDTLSをサポートしています。RADIUS-ProxyまたはRADIUS Token Serverでは、DTLSを介したRadiusはサポートされていません。RADIUS over DTLSは、Cisco IOS-XE®を実行するスイッチやワイヤレスコントローラなど、NADとして機能する多くのシスコデバイスでもサポートされています。

TLS経由のRADIUS

RADIUSのTransport Layer Security(TLS)暗号化は、RFC 6614で定義されており、トランスポートをTCPに変更し、TLSを使用してRADIUSパケットを完全に暗号化します。これは、一般的に例としてeduroamサービスで使用されます。ISE 3.4の時点ではRADIUS over TLSはサポートされていませんが、Cisco IOS-XEを実行するスイッチやワイヤレスコントローラなど、NADとして機能する多くのシスコデバイスでサポートされています。

IPSec

Identity Services Engine(ISE)は、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トラフィックをセグメント化または暗号化できない場合は、IPソースガード、ダイナミックARPインスペクション、DHCPスヌーピングなどのリスクのあるセグメントでMITMが正常に機能しないように、追加機能を実装できます。TACACS+、SAML、LDAPSなど、認証フローのタイプに基づいて他の認証方式を利用することもできます。

Identity Services Engineの脆弱性ステータス

次の表に、Blast-RADIUSに対して認証フローを保護するためにCisco ISE 3.4で使用可能な機能を示します。

要約すると、次の3つの項目は、DTLS/RadSec/IPSec暗号化ではなく、Message-Authenticatorのみを使用するフローに対して設定されている必要があります。これは、フローが脆弱にならないようにするためです。

• ネットワークアクセスデバイス(NAD)は、Access-RequestでMessage-Authenticator属性を送信する必要があります。
• RADIUSサーバでは、Access-RequestにMessage-Authenticator属性が必要です。
• RADIUSサーバは、Access-Challenge、Access-Accept、およびAccess-RejectのMessage-Authenticator属性で応答する必要があります。

Cisco Bug ID CSCwk67747（登録ユーザ専用）を参照してください。このバグIDでは、Cisco ISEがRADIUSクライアントとして動作している場合に脆弱性を閉じるための変更が追跡されています。

RADIUSサーバとしてのISE

RADIUSクライアントとしてのISE

RADIUSクライアントとしてのISEの更新

RADIUSクライアントとして機能するCisco ISEの拡張機能は、リリース3.1パッチ10、3.2パッチ8、3.3パッチ5、3.4パッチ2、3.5以降のリリースに含まれています（Cisco Bug ID CSCwk67747を参照）。パッチまたはアップグレード後、新しく作成されたリソースは、デフォルトで新しい、より安全な設定になります。パッチまたはアップグレード後により安全な設定を使用するには、既存のリソースを変更する必要があります。新しいチェックボックス「Message Authenticator Required On Response」が追加されました。オンにすると、二重の目的で機能します。Cisco ISEは常にメッセージオーセンティケータを送信し、メッセージオーセンティケータなしで応答を受信すると認証に失敗します。動作は次のとおりです。

大文字と小文字を区別する	NADは要求にメッセージ認証者を含めました	NADは要求にメッセージ認証者を含めませんでした
パッチ/アップグレードの前	ISEがメッセージオーセンティケータをRADIUSトークン、外部RADIUSサーバ、またはCoAに送信	ISEはメッセージオーセンティケータをRADIUSトークン、外部RADIUSサーバ、またはCoAに送信しません
After patch/upgrade and Message Authenticator Required On Responseチェックボックスがオフになっている。	ISEがメッセージオーセンティケータをRADIUSトークン、外部RADIUSサーバ、またはCoAに送信	ISEはメッセージオーセンティケータをRADIUSトークン、外部RADIUSサーバ、またはCoAに送信しません
After patch/upgrade and Message Authenticator Required On Responseチェックボックスにチェックマークが付いている。	ISEがメッセージオーセンティケータをRADIUSトークン、外部RADIUSサーバ、またはCoAに送信	ISEがメッセージオーセンティケータをRADIUSトークン、外部RADIUSサーバ、またはCoAに送信

RADIUSトークンサーバ

RADIUSトークンサーバ設定のAuthenticationタブに、新しいチェックボックスMessage Authenticator Required On Responseが追加されました。

このチェックボックスをオンにすると、メッセージオーセンティケータなしでRADIUS応答を受信した場合に、詳細な認証ログにエラーメッセージが記録されます。このログには、ライブログまたはRADIUS認証レポートを使用してアクセスできます。

外部RADIUSサーバ

新しいチェックボックスである「Message Authenticator Required On Response」が外部RADIUSサーバ設定に追加されました。

このチェックボックスをオンにすると、メッセージオーセンティケータなしでRADIUS応答を受信した場合に、詳細な認証ログにエラーメッセージが記録されます。このログには、ライブログまたはRADIUS認証レポートを使用してアクセスできます。

認可変更(CoA)

CoAの変更は、認可変更(CoA)ドロワーの下でネットワークデバイスプロファイルに対して行われました。

Send Message-Authenticatorオプションは以前の機能であり、新しいオプションはMessage-Authenticator Required on responseです。Cisco ISEは、応答時にMessage-Authenticator Requiredがチェックされている場合、Send Message-Authenticatorがチェックされているかどうかに関係なく、Message Authenticator属性を送信します。送信メッセージ認証機能は、既存の設定に対して保持されます。NADがCoA応答にメッセージオーセンティケータを含めない場合、ライブログから入手可能な詳細な認証レポートに次のエラーが表示されます。

シスコが提供するデフォルトのネットワークデバイスプロファイルは変更できません。新しいオプションを使用するには、ネットワークデバイスプロファイルを複製し、複製されたプロファイルの設定を有効にします。次に、ネットワークデバイスに新しく作成したネットワークデバイスプロファイルを割り当てる必要があります。これは、Cisco ISEと既存のNADの間に非互換性を導入することで、パッチの適用後やアップグレード後にネットワーク停止が発生するリスクを軽減するために行われました。既存のユーザ定義プロファイルを使用している場合は、既存のネットワークデバイスプロファイルを変更する前に、プロファイルを複製し、そのプロファイルを使用しているネットワーク上の各デバイスタイプの少なくとも1つをテストすることをお勧めします。

更新履歴

改定	発行日	コメント
2.0	21-Aug-2026	主要な書式、代替テキストの変更、概要セクション、リンク
1.0	07-Aug-2024	初版