runZero創業者のHD Mooreは2026年8月5日、Black Hat USA 2026で、企業サーバーのBMCに残る12件を超える新たな脆弱性と大規模な走査結果を発表した。インターネットに管理サービスを公開していたBMCは8万6,000台を超え、その54%超に少なくとも1件の重大な脆弱性が見つかったという。BMCはOSが停止していてもサーバーを操作できる。侵害されればOS側の防御を迂回する管理経路になる。13年前に公開されたIPMIの問題が最大7万5,000台に残り、そこへ新たな認証回避やセッション乗っ取りを連結できることが、今回の警告を重くしている。

AD

8万6,000台の管理口がインターネットへ出ていた

BMC（Baseboard Management Controller）は、サーバーのマザーボードに組み込まれた保守用コンピューターである。独自のファームウェア、ネットワークスタック、IPアドレスを持ち、管理者はBMCを通じて電源を入れ直し、更新を適用し、OSを再導入する。ブラウザー上のKVMや仮想メディアを使えば、機械の前にいなくてもコンソールと接続媒体を操作できる。

この権限は、ホストOSの稼働状態に左右されない。攻撃者がBMCの管理権限を得ると、OSを起動する前から機器を操作し、ファームウェアへ改変を残し、再導入後のOSにも再び手を伸ばせる。OS上で動くEDRが監視する範囲ともずれる。保守を支える経路が、同じ深さで攻撃を支える経路に変わるわけだ。

MooreがArs Technicaに示した外部走査では、管理サービスを公開するBMCが8万6,000台超あり、54%超に重大な脆弱性が1件以上あった。企業ネットワーク内で調べた12万6,761台では、29%近くが同じ条件に該当した。ただし、外部と内部では母集団が異なるため、この差をネットワーク分離の効果として直接比べることはできない。走査期間や重複除去を含む生データも公開されておらず、数字はMooreが公表した調査結果として読む必要がある。

なぜ13年前のRAKP問題が入口になり続けるのか

最大7万5,000台が影響を受けるとされたCVE-2013-4786は、IPMI 2.0のRAKP認証に起因する。BMCは認証が成立する前に、パスワードから計算したHMACを応答に含める。ネットワーク越しにこれを取得した攻撃者は、自分の環境へ持ち帰り、候補となるパスワードを照合できる。オンライン試行と違ってアカウントロックの影響を受けず、BMC側にも大量のログイン失敗を残さない。

NVDはこの問題を2013年7月8日に公開し、CVSS v3.0の基本値を7.5（High）としている。プロトコルのハンドシェイクに根差すため、ファームウェアを更新してもIPMI over LANを有効にする限り問題が残る製品がある。HPEは現在のiLO 7でIPMIを既定無効とし、使わない場合は無効のままにするよう案内している。代替にはiLO RESTful APIを推奨する。

初期認証情報が短い環境では、漏れたハッシュが管理者パスワードへ届く時間も縮む。Mooreによれば、工場でランダム化された認証情報でも探索空間が狭い例があり、HPE、Supermicro、Dellの方式が調査対象になった。したがって「初期値から変更済み」だけでは判定できない。十分に長く固有のユーザー名とパスワードへ変更したか、IPMI自体を停止できるかまで確認しなければならない。

AD

個別の欠陥より、連鎖で管理権限へ届く

今回報告された新しい問題は、1種類の実装ミスに収まらない。IPMI認証メッセージの順序を変えて限定的な接続を得る欠陥、交渉済みの暗号化と整合性をセッション中のパケットで強制しない実装、カウンターや時刻から推測できるセッションIDが含まれる。HPE iLOでは、管理用SSHサービスの長さ検証に起因する認証前のメモリ破壊も見つかった。BMC上で攻撃者のコードを動かす経路になるとMooreは説明した。

別の製品群では、署名されていないファームウェア、改変可能な検証設定、公開ファームウェアから回収できる鍵や定数が問題になった。認証後にしか使えない欠陥も、RAKPのハッシュ漏えい、弱い初期認証情報、認証前の不備と組み合わせれば前提が崩れる。限定的な足場からセッションを奪い、管理権限を得て、改変したファームウェアを残すという連鎖で評価する必要がある。

新規脆弱性の正確な件数、影響バージョン、修正版はまだ揃っていない。調査対象にはHPE、Supermicro、Avocentが含まれる。Huawei、Lenovo、Dellも挙げられたが、全製品が同じ欠陥を共有するわけではない。また、Mooreが今回報告した新規脆弱性について、実際の攻撃で悪用された証拠は示されていない。

一方、BMCが現実の攻撃対象であることは別の事例で確認されている。米CISAは2025年6月、AMI MegaRAC SPxの認証回避CVE-2024-54085を、実悪用の証拠に基づいてKnown Exploited Vulnerabilitiesカタログへ追加した。AMIは同脆弱性をCVSS 4.0で10.0と評価し、SPx 12.7以降とSPx 13.5を修正版としている。これは今回の新規欠陥の悪用を裏づけるものではないが、BMCの管理面が攻撃者に狙われるという前提を現実のものにしている。

OOBscanが調べる範囲と、残る空白

runZeroは研究に使ったOOBscanをBSD 2-Clauseライセンスで公開した。ツールはIPMI、Redfish、iLOを調べて機器とベンダーを識別する。HTTPとTLSを介した管理面やiDRACも対象とし、機器固有の検査とベンダー横断の検査を実行する。RAKPで漏れたハッシュのオフライン解析、既定認証情報、既知の脆弱なファームウェアも一つの走査で確認できる。

ただし、公開版はプレリリースである。ベンダーへの通知と協調開示が続く脆弱性について、詳細な検査はまだ収録されていない。OOBscanで検出がゼロでも、今回報告された問題が存在しないとは判断できない。まずBMCを資産として棚卸しし、外部公開、IPMIの有効状態、ファームウェア版、初期認証情報の残存を別々に確認する用途に向く。

Mooreは、長く固有のユーザー名と複雑なパスワードを設定し、不要なIPMIとKCSを無効にするよう勧めている。KCSはホスト側からBMCへ通じるため、停止できない場合はそのアクセス経路も制限する。さらに、複数のBMCを共有VLANへまとめず、各管理インターフェースを分離する。運用に必要な経路を先に特定してから遮断すれば、サーバー保守を止めずに攻撃面を狭められる。

ベンダーの協調開示が進めば、影響製品と修正版、OOBscanの検査項目が増える。管理者がそれを待つ理由はない。外部から到達できるBMCをゼロにし、不要なIPMIを止め、残る管理経路を個別に分離できているかが、いま確認できる防御の基準になる。