大学や大手テクノロジー企業のサイバーセキュリティ専門家は、一般的なクライアントサーバー型ネットワークプロトコルに脆弱性があることを明らかにした。この脆弱性により、スヌープが中間者（MITM）攻撃を通じてユーザー認証を回避できる可能性がある。
CVSSの深刻度スケールで10段階中7.5と評価され、CVE-2024-3596として追跡されているこの脆弱性が悪用された場合（実行は容易ではありませんが）、攻撃者は理論上、認証情報を取得することなくネットワークデバイスやサービスにアクセスできるようになります。ただし、実際には、誰かのネットワークトラフィックを中間者攻撃（MITM）し、高速ハッシュクラッキングを実行する必要があります。
Cloudflare、Microsoft、カリフォルニア大学サンディエゴ校、CWIアムステルダム、BastionZeroの研究者によって「Blast RADIUS」と名付けられたこの脆弱性は、RADIUSネットワークプロトコルに影響を与えることは容易に想像できるでしょう。この脆弱性により、リモートRADIUSサーバーを介して認証チェックを実行するクライアントデバイスに、正しい認証情報なしでログインすることが可能になります。
これが自分にどのような影響を与えるのか疑問に思っている方のために、チームは次のように述べています。
しかし、彼らは、すべてが順調に進むわけではないと述べている。「RADIUSトラフィックへのこのようなアクセスは、さまざまなメカニズムを通じて発生する可能性があります。RADIUS/UDPをオープンインターネット経由で送信することは推奨されていませんが、実際にはこのようなケースが依然として発生していることが知られています。内部ネットワークトラフィックの場合、攻撃者はまず企業ネットワークの一部を侵害する可能性があります。」
RADIUSトラフィックが内部ネットワークの保護された部分に限定されている場合でも、設定やルーティングのミスによって意図せずトラフィックが公開される可能性があります。ネットワークに部分的にアクセスできる攻撃者は、DHCPなどのメカニズムを悪用して、被害者のデバイスから専用VPNの外部にトラフィックを送信させる可能性があります。
背景
RADIUS（リモート認証ダイヤルインユーザーサービス）プロトコルは1990年代に開発され、現在でもネットワークで使用されています。Blast RADIUSの脆弱性は、PAP、CHAP、MS-CHAPv2、その他のEAP以外の認証方式を使用するRADIUS環境に影響を与えると考えられています。IPSec、TLS、802.1x、Eduroam、OpenRoamはすべて安全と考えられています。
「RADIUSプロトコルは、世界中のほとんどのネットワークアクセスシステムの基盤要素です。7月9日現在、これらのシステムのほぼすべてが安全ではなくなりました」と、InkBridge NetworksのCEOであるアラン・デコック氏は主張した。
Blast RADIUS問題の発見は、ネットワーク技術者がネットワークセキュリティ、アイデンティティ、認証に関わるすべてのデバイスにファームウェアのアップグレードをインストールする必要があることを意味します。インターネットサービスプロバイダー、企業、そしてほとんどのクラウドアイデンティティプロバイダーがこの問題の影響を受ける可能性が高いと考えています。
Blast RADIUSは、RADIUSクライアントとサーバーが認証リクエストを処理する方法に依存しており、MD5ハッシュ関数に対する衝突攻撃を実行します。MD5は2000年代から明らかに破られていましたが、Blast RADIUSチームは、RADIUSプロトコルの脆弱性を悪用するためにこのアルゴリズムを悪用することは、「従来のMD5衝突攻撃を単純に適用するよりも複雑」であると述べています。彼らは、このアプローチは速度と規模の点で優れていると述べています。
前述の通り、Blast RADIUS攻撃が成功するには、被害者のクライアント・サーバー間RADIUSトラフィックを操作し、ルーターなどの標的クライアントの1つに認証させることで、有効なパスワードを必要とせずにさらなる悪意のある攻撃や混乱を引き起こすことが不可欠です。こうしたハードルの高さを考えると、この種の攻撃は、既にネットワーク内に侵入していて、さらに深く侵入したいと考えている攻撃者にとって非常に有効です。
Blast RADIUSの仕組み
これは簡略化された説明であり、詳細を知りたい人は、脆弱性のブランド Web サイトから技術論文 [PDF] を入手できます。
Blast RADIUS の悪用は、攻撃者が任意のユーザー名とパスワードの組み合わせを使用してクライアントに対して認証を試みるところから始まります。認証が成功する必要はありません。
次に、クライアントはネットワーク経由でRADIUSサーバーに接続し、Access-Requestメッセージを使用して実際の認証を実行します。サーバーは提示された資格情報が正しいと判断すると、Access-Acceptパケットをクライアントに返し、ユーザーのログインを許可することを通知します。もちろん、この場合は資格情報が間違っているため、サーバーはログインを許可しません。代わりにAccess-Deniedパケットを返します。
クライアントとサーバー間の通信をなりすましからある程度保護するため、両者は共有シークレットを使用します。クライアントがアクセス要求をサーバーに送信する際、クライアントは要求認証子と呼ばれる16バイトのランダム値をサーバーに含めます。サーバーは応答時に、クライアントのランダムな要求認証子、共有シークレット、およびその他のデータを使用して計算された応答認証子の値を含めます。
したがって、クライアントはサーバーからのレスポンスを受信すると、リクエスト認証子の値と、レスポンスに含まれる共有秘密鍵とデータを使用することで、サーバーが正しいレスポンス認証子を算出し、レスポンスと共に送信したことを確認できます。仮にサーバーになりすまそうとして秘密鍵を知らない場合、正しいレスポンスを送信することができず、クライアントはそれを無視できます。これにより、中間者攻撃（MITM）攻撃は理想的には阻止されるはずです。
技術論文より…図解による搾取のガイド。クリックして拡大
正しい認証情報を知らないユーザーを認証しようとするクライアントのケースに戻りましょう。ここでBlast RADIUS MITMが発生します。
スヌープは、クライアントの Access-Request とそのランダムな Request Authenticator 値を傍受してデータを操作できるため、この変更されたメッセージが攻撃者によってサーバーに送信されると、サーバーは Access-Denied メッセージで応答します。攻撃者はこの応答を再び傍受して改ざんし、サーバーの応答をクライアントの有効な偽造 Access-Accept メッセージに変換できます。
これは、Marc Stevensらによる以前の研究に基づくMD5選択プレフィックスハッシュ衝突攻撃を用いて行われます。攻撃者は、サーバーへのAccess-Requestメッセージのプロキシ設定属性に巧妙に細工されたゴミデータを追加し、それがサーバーのAccess-Denied応答に含まれるという事実を悪用します。少しの暗号技術を駆使すれば、クライアントのRequest Authenticator値に対して有効でありながら、共有秘密を知らなくても偽造されたAccess-Accept応答を作成することが可能です。
この二重の傍受と操作が必要なのは、攻撃者は秘密を知らないものの、メッセージ ペイロードの内容を制御し、衝突攻撃によってハッシュを制御して、攻撃者がクライアントに送信する内容がクライアントの期待と一致するようにするためです。
クライアント側から見れば、サーバーから有効な Access-Accept 応答を受信し、攻撃者にアクセスを許可します。
- 2002年: RADIUSの新たな脆弱性が明らかに
- 2014年：Windows Updateを乗っ取るために使われた暗号衝突が主流に
- 2016年：ナマケモノがやってくる！急いでインターネットプロトコルからMD5を排除しよう
- 2023年：NSAがマイクロソフトの証明書バグを公表してから数ヶ月、データセンターは未だパッチ適用されていない
Cloudflareのレポートによると、現場にあるほとんどのRADIUSキットに攻撃を仕掛けるには、標準的なクライアントタイムアウト許容範囲を考慮して、通常5分以内に実行する必要があるとのことです。ほとんどのデバイスは30秒から60秒のタイムアウトを許容しており、理論的には、十分なリソースを持つ攻撃者はクラウドコンピューティングプラットフォームを利用して攻撃を加速させる可能性があります。
緩和戦略
調査チームによると、RADIUS 認証スタックのメーカーは、このプロトコル レベルの脆弱性を悪用するのを阻止するためのアップデートを開発したとのことです。この脆弱性は 2 月に明らかにされましたが、アクセス要求交換のセキュリティ上の落とし穴は以前から知られていました。
次のような専門家のメモから判断すると、デプロイメントの更新に注意してインストールする必要があります。
クライアントサーバー型RADIUS導入における最善の緩和策は、RADIUS over TLS（RadSec）を実装し、強力に暗号化されたストリーム内のRADIUSパケットを悪意のある攻撃者から保護することだと言われています。詳細と緩和策については、脆弱性のウェブサイトをご覧ください。®
