要約
- 5月6日の測定で見つかった36,872件は公開 IPMI アドレスの一時点の数であり、データセンター、サーバー、事業者、顧客の数ではない。
- 24,650件、全体の66.9％が、クライアント認証前に少なくとも一つのパスワード由来 RAKP 応答を返した。
- 空のユーザー名では6,240件が弱い候補と一致し、名前付きアカウントでは2,340件が一般的な候補と一致した。
- 匿名の GPU 事業者にある新しい Supermicro X13DEM 2台で工場形式のパスワードを復元したが、Lava はログインせず、開示後に事業者が是正した。
- CVE-2013-4786 は RAKP の仕組みを2013年から記録しており、2026年の新事実は公開配置の規模である。
- 優先策は UDP 623を外部で遮断し、BMC を専用管理網に隔離し、初期認証情報を変更して独立監視することだ。
第一の時計：2013年に仕組みは既に公知だった
CVE-2013-4786 は、IPMI 2.0の RAKP 認証において、第二メッセージからパスワード由来の HMAC を取得できると説明する。取得した側は候補を BMC へ何度も送らず、自分の計算環境で照合できる。脆弱性記録が最初に公開されたのは2013年7月である。
この時点で、ネットワーク側の補完策にも長い履歴が生まれた。管理インターフェースを公開経路から外し、許可された管理者だけが到達できるようにすれば、外部者は照合材料を受け取れない。パスワード強度とは別の防御である。
Supermicro の BMC セキュリティガイドも、インターネットやファイアウォール外の未許可利用者へ BMC を公開しないよう求める。安全でないネットワークでは UDP 623を遮断し、既知 IP だけを許可し、管理用 VLAN とファイアウォールで保護するという内容だ。
したがって2026年の問いは「未知の穴にどう対応するか」ではない。「既知の性質を持つ管理機能が、なぜいまも不特定のネットワークから呼び出せたのか」である。
第二の時計：5月6日の測定は配置を写した
Lava が観測した36,872件は、測定時点に公開 IP 上で IPMI へ到達できたユニークなエンドポイントである。IP アドレスは再割り当てされ得る。1件が1棟、1台、1社に対応するとは限らない。長期に同じ状態だったかも分からない。
この限定は弱点ではなく、数の用途を定める。36,872は世界のデータセンター数ではなく、外部から見えた管理面の入口数だ。母集団となる全設置台数がないため、業界全体の露出率も計算できない。
24,650件では、クライアントが本人であることを証明する前に、少なくとも一つの RAKP 応答が返った。これはパスワードそのものでも、成功したセッションでもない。候補をオフラインで検証するための材料である。
エンドポイント、応答、候補一致、認証情報の復元、ログイン、侵害は別々の状態だ。測定は前半を広く数え、後半を全体へ外挿していない。24,650件を侵害件数と呼べば、時間だけでなく証拠の段階まで混同する。
第三の時計：7月の公開は是正と検証を始めた
Lava の研究ページは7月29日付で、ベンダーと特定可能な運用者への責任ある開示を記録している。公開は5月のスキャンを新しい現在値に変えるものではない。測定日から公開日までに設定が変わった可能性を残す。
一方、開示は運用上の新しい時計を動かす。匿名の GPU 事業者にあった2台の Supermicro X13DEM について、研究者は文書化された10文字の大文字工場形式を復元したが、認証は行わなかった。事業者はその後、露出を修正したという。
これは2台に関する限定的な検証と一つの是正例である。GPU 事業者の名前を推測する根拠にはならず、すべての X13DEM や Supermicro 製品が同じ状態だとも示さない。
次に必要なのは、同じ方法による再測定だ。ただしアドレスの入れ替わりと実際の修正を分けなければならない。公開数が減っただけでは、管理プレーンが私設化されたのか、対象が消えただけなのかを判定できない。
BMC の時計はホスト OS が止まっても動く
ベースボード管理コントローラーは、ホストの OS とは独立して動作する。遠隔から電源を操作し、コンソールを見て、仮想メディアを接続し、ファームウェアを扱える。サーバーが起動しない時にも復旧できるのは、この独立性のおかげだ。
同じ理由で、BMC は別の障害領域になる。OS 上の認証、ホストファイアウォール、EDR が適切でも、管理コントローラーは別のポート、別の資格情報、別のログを使う。下位の制御経路が公開されれば、上位だけを強化しても境界は閉じない。
データセンターでは担当も分かれる。ベンダーは初期仕様を決め、インテグレーターは配線と VLAN を作り、運用者はファイアウォールを維持し、ホスティング顧客が委任コンソールを使う場合もある。設置時だけの経路を誰が閉じるかが曖昧なら、一時設定が恒久的な入口になる。
管理プレーンのインベントリーには、物理資産、BMC アドレス、運用責任者、顧客、アクセス規則を結び付ける必要がある。OS 資産台帳だけでは、下の階にある経路を見落とす。
工場パスワードには「同じ」と「狭い」の二問題がある
Supermicro は2019年11月以降、対象となる新規システムで共通のADMINではなく、個別に事前設定した BMC パスワードを出荷している。個別化は、一つの秘密が多数の機器を開く危険を抑える。
しかし個別であることと、探索空間が広いことは同じではない。一定の形式に候補が限定され、RAKP 材料を公開ネットワークから取得できるなら、各機器を別々に調べる計算はなお成立する。個別化は横への広がりを抑え、形式の複雑さは1台分の費用を決める。
HPE について Lava が示した32秒はラボの数値だ。文書化された8文字の iLO 工場形式を、8基の RTX 6000 PRO GPU で全探索した場合、捕捉した応答1件当たり約32秒だったという。公開 HPE 機器の全数を調べた結果ではない。
同様に、空のユーザー名で弱い候補と一致した6,240件と、名前付きアカウントで一般的候補と一致した2,340件は条件が違う。二つを曖昧な「ハッシュ解読率」に変換してはならない。
ベンダー比率と故障率は違う
応答した BMC の半数超が Supermicro ハードウェアだった。これは Lava のデータセット内での構成比だ。Supermicro 全設置台数に対する比率ではなく、他社と比較した脆弱性発生率でもない。
ベンダーが改善できる層はある。初期パスワードの長さと形式、ファームウェア、弱い方式を無効化する選択肢、配備時の警告である。Supermicro は公開隔離と VLAN・ACL を改めて説明し、Lava によればパスワード形式の拡張も検討している。
運用者が持つ層もある。公開経路を許すか、接続元を限定するか、初期パスワードを交換するか、異常を監視するかである。どちらか一方だけに全責任を載せると、即座に変更できる管理項目が見えなくなる。
外部測定は自社棚卸しの起点として使うべきだ。自社の BMC 全数とネットワーク規則を把握すれば、ベンダー順位より正確なリスク分母が得られる。
まず時間を止めるのはネットワーク隔離である
最初の対策は、公開ネットワークからの RAKP 交換を成立させないことだ。境界で UDP 623を遮断し、BMC を専用 VLAN または私設管理網へ置き、管理者には制御された VPN や踏み台を経由させる。既知の送信元だけを許可する規則も重ねる。
次に工場認証情報を変更し、不要なアカウントと古い方式を無効化し、ファームウェアを更新する。強いパスワードは必要だが、公開配置を正当化しない。二つは代替関係ではない。
Redfish を TLS で使う場合も、隔離管理網の内側という境界は維持する。暗号化は通信内容を守るが、インターネット上の誰がログイン画面へ到達できるかを決めない。
BMC の認証、設定変更、ファームウェア操作、通信フローは、ホスト OS とは別に監視する必要がある。管理コントローラーがホストを停止できる以上、ホストだけを証人にしてはならない。
侵害を立証する時計には、成功した認証、無許可の操作、ログ、確認済みインシデントが必要だ。今回の研究はそこまで進めていない。示したのは、古いプロトコルの時計が2026年の公開ネットワークでも動き続けたという事実である。