SingleIDのBlast RADIUS(RADIUSとMD5の脆弱性攻撃)への対応

7月 15, 2024 | お知らせ, 技術ブログ

RADIUS (Remote Authentication Dial-In User Service) は、1991年に初めて設計されたものの、現在でもリモートアクセスのための軽量認証プロトコルとして広く使用されています。しかし、RADIUSはMD5という古い暗号化方式に依存しており、これが新たにセキュリティ研究者によって報告された「Blast RADIUS攻撃」(CVE-2024-3596)の対象となっています。

この攻撃は、RADIUSクライアント(ネットワークデバイスやサービス)とRADIUSサーバー間の中間者攻撃です。認証リクエストおよびレスポンスを偽造することが可能となり、攻撃者はパスワードや共有秘密鍵を推測または総当たりすることなく、ネットワークデバイスやサービスにアクセスできるようになります。

RADIUSクライアントとRADIUSサーバー間の通信を傍受・ブロック・変更できる中間者攻撃によってのみ実行可能なため、実際には、攻撃の障壁は非常に高いといます。ただし、クラウドRADIUSのように、インターネットを経由してRADIUSを利用している場合には、特に、憂慮すべき攻撃となります。

以下に、Blast RADIUSの説明とSingleIDの対策についてご説明します。

なお、SingleIDのクラウドRADIUSは、Blast RADIUSの攻撃から保護されていますので、ご安心ください。

影響を受ける環境

RADIUS/UDP通信のPAP、CHAP、MS-CHAP認証モードを使用している場合に、Blast RADIUSに対して脆弱です。

RADIUS over TLS(RadSec)の使用、EAP認証モード(IEEE802.1X認証)の使用の場合には、Blast RADIUSに対して脆弱ではありません。無線LAN通信の認証でよく使用されるWPA2/3 Enterpriseは、EAP認証モードに含まれますので、脆弱ではありません。

想定される被害

Blast RADIUS攻撃は、企業や通信ネットワーク上の多くのネットワークデバイスに影響を及ぼす可能性があります。攻撃者がRADIUSによる認証をバイパスできれば、ネットワークデバイスやサービスに不正アクセスできるようになります。これにより、攻撃者はネットワークの流れを制御し、トラフィックをリダイレクトしたり、ルートを追加・削除したりすることが可能になります。

攻撃手法

Blast RADIUS攻撃の具体的な手順は以下の通りです:

1. 誤ったユーザー名とパスワードの入力: 攻撃者がユーザーを装い、誤ったユーザー名とパスワードを入力します。
2. リクエストの送信: RADIUSクライアントがRADIUSサーバーにRADIUSリクエストを送ります。
3. リクエストの傍受と改変: 攻撃者は中間者攻撃を実行してRADIUSリクエストを傍受し、MD5衝突攻撃を行ってRADIUSサーバーへのRADIUSリクエストを改変します。
4. アクセス拒否の傍受と改変: 攻撃者はRADIUSサーバーからのアクセス拒否を傍受し、RADIUSクライアントへの応答を改変してアクセス許可に変更します。

この攻撃手順により、攻撃者はパスワードや共有秘密鍵を推測または総当たりすることなく、ネットワークデバイスやサービスにアクセスできるようになります。攻撃者はユーザーの資格情報を知ることはありません。

なお、この攻撃はRADIUSクライアントとサーバー間の中間者攻撃者が実行可能で、攻撃者が被害者のデバイスのRADIUSクライアントおよびサーバー間を通過するすべてのデータの読み取り・ブロック・変更が可能である場合に限ります。

対策

短期的な緩和策

SingleIDのクラウドRADIUSは、セキュリティ研究者から提供されているガイダンスに従った短期的な緩和策をすでに適用しているため、Blast RADIUSから保護されています。クラウドRADIUSと連携しているお客様のネットワーク機器との互換性を損なわないよう十分に検討し、最適な方法を採用しておりますので、お客様自身での対処は不要です。

恒久的な緩和策

将来的に、短期的な緩和策をかいくぐるような、より高度で洗練されたMD5衝突攻撃が報告されることは十分考えられます。そのため、長期的にBlast RADIUSを防ぐには、RADIUSを転送する際にTLSまたはDTLSを使用することが必要です。これは、通信の暗号化を強化し、攻撃者が通信を傍受・改ざんするのを防ぐための対策です。この対策には、RADIUSクライアント(ネットワークデバイス)側で、RADIUS over TLS(RadSec)をサポートしている必要があります。

以上、Blast RADIUSおよびSingleIDの対策についてお伝えしました。皆様の安全と信頼を守るために、我々は常に最善を尽くしてまいります。

参考文献

https://www.blastradius.fail/

https://blog.cloudflare.com/radius-udp-vulnerable-md5-attack

YAMAHA RTXのリモートアクセスVPNを二要素認証へ

Related Posts

【アーカイブ公開】当日見逃した方必見!ヤマハルーター×SingleIDで実現する「安全なリモートアクセスVPN」ウェビナー全編公開

【アーカイブ公開】当日見逃した方必見!ヤマハルーター×SingleIDで実現する「安全なリモートアクセスVPN」ウェビナー全編公開

ヤマハ株式会社主催のオンラインウェビナー「ヤマハルーター×外部認証で実現。安全なリモートアクセスVPNの導入と運用」のアーカイブ動画を公開しました。当日参加できなかった方や、設定手順を詳しく確認したい方向けに、重要ポイントを凝縮してまとめています。

本編では、脆弱性が指摘されるSSL VPNからIPsecへの移行の重要性や、クラウド型認証「SingleID」を組み合わせた多要素認証(MFA)の実装を解説。ゲストに株式会社レスキューナウ様を迎え、コンフィグ管理の課題や属人化を解消したリアルな導入事例も紹介します。ヤマハルーターを活かした“令和仕様”の認証基盤へのアップデート方法を、ぜひ動画でご確認ください。

続きを読む
第2回:SingleID連携Wi‑Fiでどこまで可用性を求めるか?SMB向けのベストプラクティス

第2回:SingleID連携Wi‑Fiでどこまで可用性を求めるか?SMB向けのベストプラクティス

はじめに 前回は、BUFFALO法人向けAPの Link Integrity を使って、SingleID連携SSID と緊急用SSID を切り替える構成を検証しました。 ただ、その構成がすべてのお客様に必要とは限りません。求める可用性は、業務内容やネットワークの使い方によって変わります。 そこで今回は、SingleID連携Wi‑Fiの可用性を3つのフェーズに分けて考えます。 まずは SingleID 側の可用性を前提に運用する 必要に応じて AP 側の設定を見直し、再認証の発生を抑える さらに必要な場合だけ Link...

続きを読む
第1回:BUFFALO法人向けAPの Link Integrity で何ができるのか?SingleID連携Wi‑Fiの検証レポート

第1回:BUFFALO法人向けAPの Link Integrity で何ができるのか?SingleID連携Wi‑Fiの検証レポート

はじめに クラウドRADIUSを使ったWi‑Fi認証の話になると、まず出てくるのが次の不安です。 「クラウドRADIUSに届かなくなったら、Wi‑Fi はどうなるのか。」 このテーマを気にするのは、主に導入を検討する販売店やSIerの方だと思います。エンドユーザーは、クラウドRADIUSの到達性や再認証のタイミングまで細かく意識することは多くありません。一方で、提案する側は、お客様のネットワークにとって無理のない構成か、障害時も含めて納得感のある提案になっているかを気にします。...

続きを読む

まずはお気軽にご相談ください

料金や契約形態は販売パートナーによって異なります。
お見積りや導入のご相談、または販売パートナーのご紹介をご希望の方は、下記よりお問い合わせください。