データセンターやホスティング環境でサーバーを遠隔管理するベースボード管理コントローラー(Baseboard Management Controller:BMC)について、インターネットから到達可能な多数の機器が、ログインの完了前にパスワード由来の認証情報を返していたことが分かりました。
データセンター向けセキュリティ企業Lavaが2026年7月29日に公開した調査によると、同社はインターネットへ公開されたインテリジェントプラットフォーム管理インターフェース(Intelligent Platform Management Interface:IPMI)対応ホストを3万6,872台確認しました。このうち2万4,650台、全体の66.9%が、クライアントの認証が完了する前に少なくとも1件のRMCP+認証鍵交換プロトコル(RAKP)応答を返したとしています。
問題の中心にあるのは、共通脆弱性識別子(CVE)として2013年に登録されたCVE-2013-4786です。IPMI 2.0の認証処理では、BMCがアカウントのパスワードを基に計算した認証コードを、利用者の認証が完了する前に返す場合があります。攻撃者がBMCのIPMIサービスへ到達できれば、この応答を入手し、BMCへ繰り返しログインを試さずにパスワード候補をオフラインで照合できます。
これは、2026年に新しく発見された脆弱性ではありません。また、2万4,650台すべてでパスワードが取得された、あるいは侵害されたという意味でもありません。今回の調査が示したのは、13年前にCVEが登録された問題が、インターネットへ直接公開されたBMC、弱いパスワード、予測しやすい工場出荷時のパスワード形式と組み合わさり、現在も現実的なリスクを生んでいることです。
調査で確認された主な数値
Lavaは、2026年5月6日にインターネットからIPMIへ到達可能な3万6,872台の一意なホストを確認しました。5月から7月まで測定を繰り返したところ、1日平均で約60件の未確認IPアドレスが新たに観測されたとしています。
| 確認項目 | 結果 |
|---|---|
| インターネットへ公開されたIPMIホスト | 36,872台 |
| 認証完了前に1件以上のRAKP応答を返したホスト | 24,650台(66.9%) |
| 空のユーザー名と弱いパスワード候補が一致したホスト | 6,240台(16.9%) |
| 名前付きアカウントで一般的なパスワード候補が一致したホスト | 2,340台(6.3%) |
2,340台では、ADMINやrootなどの名前付きアカウントに対応する認証情報が、公開されている一般的なパスワードリストの候補と一致しました。これはRAKP応答を返した2万4,650台の約9.5%に相当します。
Lavaは、取得した応答をBMCへのログインには使用せず、対象機器の管理画面へのアクセスや設定変更も行わなかったと説明しています。その一方で、一般的なパスワードや予測可能な工場出荷時形式を含めると、返された認証情報の30%以上でパスワードを復元できたと報告しました。
公開IPアドレス数は、組織数、データセンター数、物理サーバー数と同一ではありません。今回の数値は、測定時点でインターネットからIPMIへ応答した一意なホスト数として扱う必要があります。
BMCとIPMIとは
BMCは、サーバー本体に搭載される専用の管理プロセッサーです。オペレーティングシステム(OS)が停止している場合や、サーバーが正常に起動できない場合でも動作し、管理者は遠隔から電源操作、ハードウェア状態の確認、リモートコンソール、仮想メディアの接続、ファームウェア更新などを実行できます。
製品によって名称は異なり、HPEはiLO、DellはiDRAC、LenovoはXClarity Controllerを提供しています。IPMIに加えて、HTTPSベースの管理用アプリケーションプログラミングインターフェース(API)であるRedfish、Web管理画面、キーボード・画面・マウスを遠隔操作するKVM(Keyboard, Video and Mouse)などが併用される場合もあります。
最大の特徴は、BMCがホストOSから独立して動作する点です。一般的なエンドポイント検知・対応(Endpoint Detection and Response:EDR)やアンチウイルス製品は、主にOS、プロセス、ファイル、ネットワーク通信を監視します。しかしBMCは、その監視範囲より下に位置する別の管理領域です。
BMCが侵害されると、攻撃者はOSの外側から電源やコンソールを操作できる可能性があります。ファームウェアへ不正な変更が加えられた場合、OSの再インストールだけでは信頼性を回復できないこともあります。
CVE-2013-4786はどのような脆弱性か
CVE-2013-4786は、IPMI 2.0で使われるRAKPの認証処理に関する情報漏えいの脆弱性です。
米国国立脆弱性データベース(National Vulnerability Database:NVD)によると、リモートの攻撃者は、BMCが返すRAKP Message 2のハッシュベースのメッセージ認証コード(Hash-based Message Authentication Code:HMAC)を取得し、パスワードハッシュの入手とオフラインでのパスワード推測を行える可能性があります。
NVDは共通脆弱性評価システム(Common Vulnerability Scoring System:CVSS) v3.0の基本値を7.5(High)と評価しています。評価ベクトルは、ネットワーク経由で到達可能、攻撃条件が複雑ではない、事前の権限と利用者操作が不要、機密性への影響が大きい一方、脆弱性単体では完全性と可用性への直接影響を評価していない内容です。
重要なのは、CVE-2013-4786だけで直ちにBMCへログインできるわけではない点です。得られるのはパスワードそのものではなく、パスワード候補をオフラインで検証するために利用できる認証情報です。長く、予測困難で、機器ごとに異なるパスワードへ変更されていれば、現実的な復元は難しくなります。
反対に、初期パスワードを変更していない、複数台で同じパスワードを使っている、短い単語や一般的な文字列を使っている、工場出荷時の形式が限定されている場合には、オフライン推測のリスクが高まります。オンラインの総当たりとは異なり、BMCへ大量のログイン試行を送る必要がないため、失敗ログやアカウントロックだけに依存した対策では検知できません。
「Cipher Suite 0」とCVE-2013-4786は別の問題
IPMIのセキュリティでは、暗号化や認証を行わないCipher Suite 0、いわゆるCipher Zeroの問題も知られています。Cipher Suite 0が有効な実装では、認証を回避して管理操作を実行できる場合があります。
一方、CVE-2013-4786はRAKPの応答からパスワード由来の認証情報を取得できる問題です。両者は同じIPMI 2.0周辺で発生し、同時に調査されることが多いものの、同一の脆弱性ではありません。
今回Lavaが行った測定でも、Cipher Suite 0、空またはnullのユーザー名、認証方式NONE、一般的なベンダー既定ユーザー名へのRAKP応答、CVE-2013-4786などを別々の確認項目として扱っています。記事や診断結果を読む際には、「Cipher Zeroが無効ならCVE-2013-4786の影響もない」とは判断しないことが重要です。
なぜ13年前のCVEが2026年も問題になるのか
今回の報告で新しいのは、脆弱性そのものではなく、現在も大規模な露出が残り、現代の計算能力によって工場出荷時パスワードの復元が現実的になっている点です。
IPMI 2.0は2004年に導入されました。CVE-2013-4786はプロトコルの認証フローに由来するため、一般的なアプリケーション脆弱性のように、すべての製品へ共通する一つの更新プログラムを適用すれば解消する問題ではありません。ベンダーや世代によって実装、既定設定、無効化手段、推奨される回避策が異なります。
また、BMCは導入後に長期間使われます。OSや業務アプリケーションは定期的に更新されても、BMCファームウェア、管理用の仮想LAN(Virtual LAN:VLAN)、初期アカウント、IPMI over LANの設定は、サーバー導入時のまま残ることがあります。サーバーを別用途へ転用した際や、データセンターのネットワーク構成を変更した際に、管理用ポートだけが意図せず外部へ露出する可能性もあります。
さらに、BMCではWeb画面、IPMI、Redfishなどが同じユーザーデータベースを使う実装があります。その場合、IPMIの認証処理から推測された認証情報が、Web管理画面や別の管理APIでも使用できる可能性があります。実際の影響は製品と設定に依存しますが、IPMIだけを古い補助機能として軽視することはできません。
Supermicroの一意な初期パスワードも対象になった
Supermicroは2019年11月から、対象製品で共通のADMINパスワードを廃止し、機器ごとに異なる一意な初期パスワードを導入しました。公式資料によると、このパスワードは英大文字10文字で構成され、マザーボードやサービスラベルに記載されます。
一意なパスワードの導入は、すべての機器が同じ初期パスワードを使う状態より大きな改善です。ただし、初期値をそのまま使い続けた場合、文字種と長さが固定されていること自体が、オフライン推測時の候補範囲を限定します。
Lavaは、検査が許可された米国のAI・高性能演算向けGPU(Graphics Processing Unit)を提供するベアメタルサーバー事業者が運用する2台の2023年製Supermicroシステムで、工場出荷時形式に一致するパスワードを復元できたと報告しました。研究者は、その認証情報を実際のログインには使用せず、管理画面へのアクセスや設定変更も行っていません。事業者へ同日中に通知し、その後、公開状態は修正されたとしています。
研究者の測定では、応答したBMCの50%以上がSupermicroとみられました。ただし、これは公開IPMIの測定結果における構成比であり、Supermicro製品全体の半数が脆弱、あるいは同社製品だけに問題があるという意味ではありません。CVE-2013-4786はIPMI 2.0の認証方式に関係し、複数ベンダーの実装で扱われてきた問題です。
HPE iLOの工場出荷時パスワードも検証
Lavaは、自社ラボにあるHPE iLO搭載サーバーでも、工場出荷時パスワードを使った検証を行いました。HPEの初期パスワード形式はSupermicroと異なりますが、研究環境では現代のGPUを使うことで短時間に候補を検証できたとしています。
この結果も、すべてのHPE iLOの認証情報が容易に復元できることを示すものではありません。IPMI over LANが有効で外部から到達可能であること、対象アカウントのRAKP応答を取得できること、工場出荷時パスワードを変更していないことなど、複数の条件が重なる必要があります。
HPEはCVE-2013-4786に関する公式資料で、IPMIを使用していない場合はIPMI over LANを無効のままにすることを推奨しています。また、iLO 5ではIPMI over LANが既定で無効と案内されており、iLOファームウェアを最新状態に保つことも推奨されています。
実悪用は確認されているのか
Lavaは、インターネットへ公開されたBMCがすでに標的となり、侵害されていることを示す兆候を確認したと説明しています。調査中には、HPE iLO 4のログイン画面に身代金要求文が表示された例が見つかりました。
ただし、研究者は、そのサーバー内のデータが実際に暗号化されたか確認できなかったとしています。また、攻撃者がCVE-2013-4786を利用して認証情報を取得したのか、別の脆弱性、初期パスワード、漏えい済み認証情報などを利用したのかも確認されていません。
したがって、「CVE-2013-4786が大規模に悪用され、2万4,650台が侵害済み」と断定することはできません。正確には、CVE-2013-4786に関連する認証情報の返却が多数の公開BMCで確認され、別途、公開BMCが実際に侵害対象となっていることを示す事例も観測された、という状況です。
影響を受ける可能性がある環境
NVDのCVE情報は、特定の一製品や一バージョンに限定した影響一覧を示していません。IPMI 2.0のRAKP認証を実装するBMCが広く関係するため、管理者はベンダー名だけで対象外と判断せず、自組織の構成を確認する必要があります。
特に優先して確認したいのは、次の環境です。
- IPMIのUDP 623番ポートがインターネットから到達可能なサーバー
- BMC管理用ネットワークと業務ネットワークが分離されていない環境
- IPMI over LANを利用しているが、接続元IPアドレスを制限していない環境
- BMCの工場出荷時アカウントや初期パスワードを変更していない環境
- 複数のBMCで同じ管理パスワードを使い回している環境
- 古いiLO、iDRAC、Supermicro BMCなどを長期間更新していない環境
- ホスティング、GPUクラウド、ベアメタル提供など、多数の物理サーバーを共通の管理ネットワークで運用する環境
- Web管理画面は制限しているものの、IPMIやRedfishの到達範囲を個別に確認していない環境
一方、BMCが物理的または論理的に分離された管理ネットワークに置かれ、インターネットから直接到達できず、接続元が限定され、強固で一意なパスワードへ変更されている環境では、今回の調査と同じ攻撃経路が成立する可能性は大きく下がります。
管理者が優先すべき対処
1. インターネットへの公開を停止する
最優先の対処は、IPMIをインターネットへ直接公開しないことです。境界ファイアウォールやクラウド側のアクセス制御でUDP 623番ポートへの外部通信を遮断し、BMCのWeb管理画面、Redfish、リモートコンソールなど、関連する管理経路も併せて確認します。
単にIPMIのポートだけを閉じても、同じ認証情報を使うWeb管理画面が公開されたままでは、認証情報漏えいや使い回しによるリスクが残ります。BMCが提供するすべての管理サービスを棚卸しし、公開範囲を個別に確認することが重要です。
2. 専用管理ネットワークへ分離する
BMCは、業務用LANや一般利用者が接続するネットワークから分離し、専用の仮想LAN(VLAN)へ配置します。アクセスは仮想プライベートネットワーク(Virtual Private Network:VPN)、踏み台サーバー、特権アクセス管理基盤などを経由させ、許可された管理端末と管理者だけに限定します。
IBMのIPMIベストプラクティスでも、IPMI通信を信頼できる内部ネットワークへ制限し、強いネットワーク制御を備えた管理VLANへ分離することが推奨されています。管理ネットワーク内の異常通信は、業務ネットワークとは別に監視する必要があります。
3. 初期パスワードを変更し、機器ごとに一意にする
共通の初期パスワードだけでなく、機器ごとに割り当てられた一意な工場出荷時パスワードも、運用開始時に変更します。今回の調査は、一意であっても形式が固定された初期パスワードを長期間使うことにはリスクがあると示しました。
新しいパスワードは十分な長さと予測困難性を持たせ、他のBMC、OS管理者、ネットワーク機器、クラウド管理画面と使い回さないようにします。可能であれば、企業の認証基盤や特権アクセス管理を利用し、退職者や委託先のアクセス権が残らない運用へ移行します。
4. 不要なIPMI over LANと古い認証機能を無効化する
IPMIを使っていない場合は、ベンダーの手順に従ってIPMI over LANを無効化します。利用する場合も、IPMI 1.5、Cipher Suite 0、匿名または名前のないアカウント、認証方式NONEなど、不要な古い機能を無効にします。
Redfishを利用できる環境では、通信暗号化プロトコルであるTLS(Transport Layer Security)を使用するRedfishへ移行する選択肢があります。ただし、Redfishへ変更すればインターネットへ直接公開してよいわけではありません。Lavaは、IPMIとRedfishのどちらも公開インターネットへ直接露出させず、分離された管理ネットワーク内で利用するよう推奨しています。
5. BMCファームウェアとベンダー情報を確認する
サーバー本体のOSだけでなく、BMC、BIOS、プラットフォームファームウェアを資産管理の対象に含めます。利用中の製品名、世代、BMCファームウェアのバージョン、IPMI over LANの既定値と現在値を確認し、ベンダーが提供する最新のセキュリティ更新とハードニングガイドを適用します。
CVE-2013-4786はIPMI 2.0の認証方式に関係するため、更新だけでなく、無効化、ネットワーク分離、認証情報変更を組み合わせる必要があります。「最新ファームウェアだから外部公開しても安全」とは判断しないでください。
侵害が疑われる場合の確認
BMCがインターネットへ公開されていた、初期パスワードを使っていた、管理者が把握していないログインや設定変更がある場合には、単なるポート閉鎖だけで対応を終えず、侵害の可能性を調査します。
- BMCのログイン履歴、監査ログ、設定変更履歴、ユーザー追加履歴を確認する
- 認識していない管理者アカウント、APIキー、証明書、遠隔管理通信であるSecure Shell(SSH)の鍵がないか確認する
- リモートコンソール、仮想メディア、電源操作、ファームウェア更新の履歴を確認する
- 管理ネットワークから他のBMCや管理基盤への不審な通信がないか確認する
- BMCの認証情報と、同じパスワードを使っていた可能性がある他システムの認証情報を変更する
- ベンダーが提供する手順でBMCファームウェアの完全性とバージョンを確認する
- 不正なファームウェア変更が疑われる場合は、ベンダー支援の下で再フラッシュや交換を検討する
BMCはOSの外側で動作するため、ホストOS側のEDRで異常が見つからないことだけを根拠に、侵害なしとは判断できません。影響範囲には、同じ管理ネットワーク上の別サーバー、プロビジョニング基盤、認証基盤、ファームウェア配布基盤も含めて確認する必要があります。
今回の調査から分かること
CVE-2013-4786は、2026年に突然現れたゼロデイではありません。NVDでHighと評価され、ベンダーやセキュリティ機関が長年対策を案内してきた既知の問題です。それでも多数のBMCがインターネットへ公開され、初期パスワードや弱いパスワードが残っていました。
この状況は、脆弱性管理をCVEの新しさやOSの更新だけで判断できないことを示しています。BMC、ハイパーバイザー、ストレージ管理、ネットワーク機器の管理プレーンなど、通常の業務通信とは別に存在する管理経路も、継続的な資産管理と露出確認の対象にしなければなりません。
特に、GPUサーバーやベアメタルクラウドのように高価な物理サーバーを多数運用する環境では、1台のBMC侵害が共通管理ネットワークやプロビジョニング基盤への足掛かりになる可能性があります。利用者ごとに専用サーバーを割り当てていても、事業者側のBMC管理面が共有されていれば、テナント分離とは別の信頼境界が残ります。
管理者は、外部公開の停止、管理ネットワークの分離、工場出荷時パスワードの変更、不要なIPMI機能の無効化、ファームウェア更新、管理ログの監視を一つの対策セットとして実施する必要があります。
まとめ
Lavaの調査では、インターネットへ公開されたIPMIホスト3万6,872台のうち、2万4,650台が認証完了前にパスワード由来のRAKP応答を返しました。背景には、IPMI 2.0のCVE-2013-4786、公開された管理インターフェース、弱いまたは変更されていない初期パスワードが重なっています。
2万4,650台すべてのパスワードが復元されたわけでも、CVE-2013-4786を使った侵害が確認されたわけでもありません。しかし、BMCはOSから独立した強い管理権限で物理サーバーを管理できるため、認証情報が取得された場合の影響は大きくなります。
自組織で物理サーバーを運用している場合は、IPMIの利用有無だけでなく、BMCがどのネットワークから到達できるか、初期パスワードが残っていないか、Web管理画面やRedfishを含む管理経路が公開されていないかを確認してください。古いCVEであることは、対応を後回しにしてよい理由にはなりません。
コメント