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

はじめに

2024年7月7日、セキュリティ研究者がRADIUSプロトコルの次の脆弱性を公開しました。CVE-2024-3596:RFC 2865のRADIUSプロトコルは、MD5応答オーセンティケータシグニチャに対するchosen-prefix collision攻撃を使用して、他の応答に対する有効な応答（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を参照してください。この記事では、一般的な緩和策と、すべてのシスコ製品ではなく一部の製品に対して緩和策がどのように適用されるかについて説明します。具体的には、個々の製品ドキュメントを参照してください。シスコの主力RADIUSサーバである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属性を含めると、Identity Services Engineはすべてのバージョンで、結果として生成されるAccess-Accept、Access-Challenge、またはAccess-RejectパケットにMessage-Authenticatorを含めます。

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

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

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は、IOS-XE®を実行するスイッチやワイヤレスコントローラなど、NADとして機能する多くのシスコデバイスでもサポートされています。

TLS経由のRADIUS

RADIUSのTransport Layer Security(TLS)暗号化は、RFC 6614で定義されており、トランスポートをTCPに変更し、TLSを使用してRADIUSパケットを完全に暗号化します。これは、一般的に例としてeduroamサービスで使用されます。ISE 3.4の時点ではRADIUS over TLSはサポートされていませんが、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から保護するためにISE 3.4で使用可能な機能を示します。要約すると、DTLS/RadSec/IPSec暗号化ではなく、Message-Authenticatorのみを使用するフローに対して次の3つの項目が設定されている必要があります。フローに脆弱性が存在しないようにするためです。
1)ネットワークアクセスデバイスは、Access-RequestでMessage-Authenticator属性を送信する必要があります。

2) RADIUSサーバは、Access-RequestのMessage-Authenticator属性を必要とします。

3) RADIUSサーバは、Access-Challenge、Access-Accept、およびAccess-RejectのMessage-Authenticator属性で応答する必要があります。

ISEがRADIUSクライアントとして動作しているときに脆弱性を閉じるために変更を追跡しているCSCwk67747を参照してください。

RADIUSサーバとしてのISE

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

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

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

RADIUSトークンサーバ

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

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

**注：全体的な認証は、ポリシー設定に基づいて引き続き渡すことができます。認証を通じて、予期しないポリシーに一致する場合があります。

外部RADIUSサーバ

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

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

**注：全体的な認証は、ポリシー設定に基づいて引き続き渡すことができます。認証を通じて、予期しないポリシーに一致する場合があります。

認可変更(CoA)

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

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

 **注：NADはCoAを処理したがメッセージオーセンティケータを応答に含めていない可能性があるため、ISEに障害が記録されても、NADでCoAが成功する可能性があります。

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