BMCファームウェアの脆弱性がOT/IoT デバイスのセキュリティに影響 - パート2

BMCファームウェアの脆弱性がOT/IoT デバイスのセキュリティに影響 - パート2

昨年、Nozomi Networks Labsは、Lanner Electronicsデバイスのベースボード管理コントローラ(BMC)に影響を及ぼす13の脆弱性を明らかにする調査結果を発表した。BMCはコンピュータのマザーボードに搭載されているコンポーネントで、独立したCPU、メモリ、LANインターフェイスを備えており、リモート管理者がPC/サーバーに接続したり、コマンドを送信してさまざまな操作を実行できるようになっている。コンピュータの遠隔監視および管理用に設計されたこれらのコントローラを操作すると、認証されていない敵対者によってデバイスが完全に侵害される可能性があります。

その調査に続いて、我々は、American Megatrends (AMI) MegaRAC BMC ソフトウェア・ソリュー ションに影響を及ぼす 5 つの新しい脆弱性を発見した。以下に説明する脆弱性は、特に AMI MegaRAC SP-X コードベースに影響を及ぼすもので、このコードベースは、複数の BMC デバイスのファームウェアのベースとなっています。このファームウェアは、多くのベンダーが独自のリモート管理ソリューションを構築するために広く採用し ているため、これらの脆弱性は、特定の製品範囲や個々のベンダーに限定されるものではない。むしろ、影響を受けるコードベースから派生した BMC ファームウェアを持つ、すべてのベンダーのすべての製品(OT 、IoT 、または IT デバイスである)に影響を与える可能性がある。注目すべきは、いくつかのデバイスについて、これらの脆弱性が、利用可能な最新のファームウェア・リリー スに影響を及ぼすという証拠を、私たちは得ているということである。

このブログでは、AMI MegaRAC SP-X サービスプロセッサーの概要、脆弱性の説明、および BMC Web インターフェース上の永続的なバックドアにつながる攻撃シナリオについて説明します。

BMCとAMI MegaRAC SP-X

ベースボード管理コントローラ(BMC)は、消費電力、温度、ファン速度、ストレージデバイスなど、システムのハードウェアのさまざまな側面を管理および監視するために、サーバーのマザーボードに統合された専用のマイクロコントローラです。BMCはメインCPUとは独立して動作するため、メインプロセッサーが正常に機能しない場合でも、管理者はサーバーにリモートアクセスして制御することができます。

American Megatrends(AMI)のMegaRACSP-Xは、市場で入手可能なBMCチップ用の最も有名な商用ファームウェア・ソリューションの一つである。Linuxカーネルをベースとし、リモート電源管理、キーボードとビデオ・マウスによる対話、仮想メディアのサポートなど、幅広い機能を提供する。管理者やオペレーターは、ウェブポータル、標準のRedfish API、IPMIサービスなど、さまざまなインターフェースを通じてBMCと対話することができます。

BMC ファームウェアが AMI MegaRAC SP-X をベースにしている、またはベースにしていたことが知られ ているベンダーには、Asus、Dell、Gigabyte、Hewlett Packard Enterprise、 Lanner、Lenovo、NVIDIA、Tyan などがある。これらのベンダーは、標準的な MegaRAC SP-X ファームウェア・イメージを「そのまま」導入することも、ニーズに応じて カスタマイズして構成することもできる。

我々の研究は、バックアップファイルと BMC ホストベースのウェブインターフェイスのファイルハッシュ検証における脆弱性を特定した。さらに、整合性チェックがマザーボード BIOS またはファームウェア(例えば、セキュア・ブート・プロセス中にファームウェアの整合性を測定する UEFI)によって実施されない場合、攻撃者がウェブベースの BMC 管理インターフェイスにバックドアを隠すことができる攻撃シナリオを発見し、提示しました。このバックドア・アクセスは、ホスト・オペレーティングシステムの再インストールや BMC コンフィギュレーション自体のハードリセットを超えても持続する可能性があります。最後に、資産所有者が利用可能な対策と推奨される対策について説明します。

MegaRAC SP-Xに脆弱性が見つかる

MegaRAC SP-Xの標準コードベースに見つかった脆弱性のリストは以下の通り:

リスクが高い:

  1. CVE-2023-34337:不十分な暗号化強度 (CWE-326), CVSS v3 7.6 (AV:A/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H)
  2. CVE-2023-34338:ハードコードされた暗号鍵の使用 (CWE-321), CVSS v3 7.1 (AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H)

中程度のリスクだ:

  1. CVE-2023-34473:ハードコードされた認証情報の使用 (CWE-798), CVSS v3 6.6 (AV:A/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H)
  2. CVE-2023-34471:暗号化ステップの欠落 (CWE-325), CVSS v3 6.3 (AV:A/AC:H/PR:H/UI:R/S:U/C:H/I:H/A:H)
  3. CVE-2023-34472:HTTP ヘッダにおける CRLF シーケンスの不適切な中和 ('HTTP Request/Response Splitting') (CWE-113), CVSS v3 5.7 (AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N)

CVE-2023-34337, CVE-2023-34473, CVE-2023-34471 は、update-2.00 (除外) までの SPx_12 に影響を及ぼしました。CVE-2023-34338 は、update-3.00 までの SPx_12 に影響します (除外)。CVE-2023-34472 は 2021/4/16 までの LTS_12、2021/7/14 までの LTS_13、update-5.00 (除外) までの SPx_12、update-3.00 (除外) までの SPx_13 に影響を及ぼします。

ファイル整合性ハッシュとバックアップ復元ファイルによるBMCへの攻撃

OT/IoT の目的でマザーボードのBMCウェブ・インターフェースをラボ環境でテストしているとき、BMCコンフィギュレーションのバックアップとリストアを実行する可能性があることに気づきました(図1)。この機能は、前回のパート1研究ブログで評価したLanner IAC-AST2500にはありませんでした。

図MegaRAC SP-X BMC インターフェースのバックアップとリストア機能
図 1. MegaRAC SP-X BMC Interface のバックアップとリストア機能。

バックアップファイルの内容を検査することで、ネットワーク設定ファイルや認証情報など、基盤となるLinuxシステムの機密データが含まれていることにすぐに気付きました。注目すべきは、バックアップ・ファイル内にBashスクリプトが含まれていたことで、BMC上でリモート・コード実行(RCE)を行う機会があったことが明らかです。しかし、バックアップ・ファイルの内容を変更しただけでは、バックアップ・ファイルは拒否されました。そこで、BMCがファイルの整合性をどのように検証しているかを調査することにしました。

デバイスのファームウェアを解凍し、IDA Proでspx_restserviceバイナリ(ウェブリクエストの処理を担当するメインバイナリ)をロードすると、すぐに、バックアップ/リストア機能がlibBackupConf.soという追加の共有オブジェクト、より具体的にはRestoreConfFileエクスポート関数によって処理されていることに気づいた(図2)。

RestoreConfFile
図2. リストアコンファイル

検証手順の中核は、VerifyFileIntegrity関数内で行われる。この関数を逆にしてみると、提供されたファイルに対して計算されたHMAC-SHA1ハッシュと、ファイル・トレイラーに含まれるハッシュを比較することで、完全性が検証されることがわかった。一致した場合、ファイルは受け入れられた。一致しない場合、ファイルは廃棄された。

しかし、その過程ですぐに次のような落とし穴があることに気づいた:

  • HMAC-SHA1 を計算するために使用されたシークレットは、ライブラリにハードコードされた 10 個の値のうちの 1 つであることが判明した。さらに、我々の特定のBMCファームウェアでは、バックアップ・ファイルを生成する関数をさらに分析した結果、シークレットとして使用される値は、常にリストの最初のものであることが判明した;
  • HMAC-SHA1の構造は、標準的な暗号プリミティブとアルゴリズムを定義した関連RFCに記述されているもの(H(K XOR opad, H(K XOR ipad, text) )ではなく、カスタムで簡略化したもの(H(text, K) )であった。)
  • この簡略化されたバージョンは、メッセージのSHA1の衝突(実現可能であることが証明されている)に対する耐性を提供しないため、標準的な暗号プリミティブよりも安全性が低い;
  • 最後に、結果として得られるHMAC-SHA1出力の全20バイトのうち、アルゴリズムによって検証されたのは2バイトだけであり、結果として65'536通りのHMAC-SHA1の組み合わせしか得られない。この制限により、このハッシュ関数はネットワーク・ブルートフォース攻撃を受けやすくなる。

短時間で、Bashスクリプトの1つにリバースシェルを追加する行をいくつか注入し、有効なHMAC-SHA1を作成することができた。

 BMCで得られたルートシェル
図3.BMCで得られたルートシェル

予想通り、バックアップとリストアの機能は認証されたユーザーのみに制限されていた。しかし、認証されていない攻撃者は、リポジトリ・サーバ内のバックアップ・リストア・ファイルにポイズニングを施し、そのファイルを使用してバックアップからリストアするよう、無自覚な被害者/ユーザーを待ち伏せ、あるいは信じ込ませることで、悪意のあるコードの実行を誘発することで、これらの問題のいくつかを間接的に悪用できる可能性がある。

ホストからBMCを攻撃し、リセット耐性の持続性を実現する

BMC のウェブインタフェースがいかに強力であるかを考えると、クロスサイトスクリプティング(XSS)は、攻撃者 が制御されたホスト上で密かにコマンドを起動できることを考えると、発生する可能性のある最も危険な脆弱性の一つです。私たちの分析では、XSS 脆弱性についてウェブ・アプリケーションを広範囲にテストしましたが、攻撃者が制御する可能性のある フィールドには何も見つけることができませんでした。このため、私たちは既成概念にとらわれず、通常は攻撃者が標的にしないと思われるフィールドの XSS をテストすることを試みました。

特に、BMC ウェブ・インターフェイスは、管理対象システムに関連する資産情報を表示します。例えば、「Field Replaceable Units」ウェブページです(図4)。

FRU情報ページ
図4. FRU情報ページ

いくつかの調査の後、我々はこのデータの一部がホストシステムのBIOS/UEFIにハードコードされた値から抽出されていることを発見した。以前はBIOSのアップデートは特別なマザーボード機能でブートすることによってのみ実行可能なタスクであったが、現在ではホストOSから直接BIOS/UEFIのアップデートを実行することがますます一般的になっている(例えば、メーカーのアドホックアプリケーションやWindows Updateサービスを介して)。したがって、私たちはこれらのフィールドのいくつかを悪用することで、ストアドXSSをテストするためにBIOSイメージを編集し、それをリフラッシュすることを探求することにしました。

概念実証として、インターネット上で入手可能なAMI BIOS編集ツールの1つを使用し、図5に示すように、BIOSイメージにハードコードされたベンダー名と製品名にXSSペイロードを注入しました。また、ブートプロセス中に通常表示されないフィールドを使用することもできました。

毒されたベンダー名と製品名のBIOS
図5.ベンダー名と製品名が偽装されたBIOS

その後、BMCウェブ・インターフェイスにログインし、FRUウェブページを再度開いた。すぐにアラートが表示され、任意のJavaScriptコードの実行が確認された。

FRUウェブページにXSSを保存
図6. FRUウェブページに保存されたXSS

比較的単純であるにもかかわらず、この攻撃は甚大な被害をもたらす。管理対象ホストの管理者権限を獲得した攻撃者は、横方向に移動し、ウェブベースのBMC管理インターフェイスにバックドアを隠すことができる。このアクセスは、ホストOSの再インストール、ハードドライブの変更、またはBMC設定自体のハードリセットが何度行われても持続する可能性があります。これを取り除く唯一の方法は、BIOS/UEFIをクリーンイメージでリフラッシュすることです。また、同様の攻撃が行われる可能性は低いが、不可能ではないことも注目に値する。国家がスポンサーとなった標的型攻撃において、ファームウェアのリフラッシュによって永続性が達成された事例がすでに登録されている。

AMI の脅威モデルによると、このようなシナリオに対する保護は BIOS/UEFI の整合性チェックによって提供され、BMC の製造元やエンドユーザーの責任である。そのため、この発見は脆弱性とはみなされず、CVE ID は割り当てられていません。

利用可能な改善策  

MegaRAC SP-X の Q3 2021 までのバージョンをベースとするすべてのデバイスのすべての BMC ファームウェアが影響を受ける(ベンダーがコードの脆弱な部分を変更または削除するために特定のカスタマイズを適用した場合を除く)。特筆すべきは、いくつかのデバイスについて、利用可能な最新のファームウェア・バージョンにお いて、これらの脆弱性を確認することができたことである。従って、BMC ファームウェアは、それぞれのベンダーが、その時点以降にリリースされた修正バ ージョンのいずれかをベースとすることを選択した場合(あるいは、ベンダーがコードの脆弱な部 分を変更または削除するための特定のカスタマイズを適用した場合)にのみ、前述のすべての CVE ID に対してパッチが適用される。

ウェブベースの BMC 管理インターフェイスは、MegaRAC SP-X のコードベース・バージョンに関する情報を明確に提 供していないため、デバイスの脆弱性ステータスに関する正確な情報は、各メーカーから提供されなけれ ばならない。我々は、資産所有者に対し、メーカーに確認し、BMC ファームウェアのパッチが入手可能な場合には、それを適用することを強く推奨する。

メーカーが何の情報も解決策も提供しない場合、次のような緩和策を適用することができる:

  • CVE-2023-34337、CVE-2023-34471、CVE-2023-34472、CVE-2023-34473: BMC にアクセスできるすべてのアカウントを見直して不要なアカウントを削除する;
  • CVE-2023-34338:ウェブベースのBMC管理インターフェイスからTLS証明書を手動で再生成する。

永続的な攻撃シナリオに関しては、完全にパッチが適用された BMC ソリューションであっても、まだ実現可能かもしれない。このケースの悪用を避けるために推奨されるのは、BIOS/UEFI の完全性保護(例えば、署名されたファームウェアのアップデートの実施、セキュアブートなど)を常に有効にすることです。

結論  

AMI MegaRAC SP-X は、データセンターおよびエンタープライズクラスのサーバー向けに設計された強力で包括的なリモート管理 BMC ファームウェアソリューションであり、幅広いベンダーに採用されています。BMCは、サーバーハードウェアの効率的な管理と監視において重要な役割を果たしますが、その継続的な運用とリモートアクセスは、セキュリティリスクをもたらす可能性もあります。

この記事では、さまざまな有名ベンダーが複数のデバイスに展開している標準的な MegaRAC SP-X コードベースに影響を及ぼす 5 つの新しい脆弱性を特定し、説明しました。また、攻撃者が BMC 上でリセット耐性永続化を達成する可能性のある攻撃シナリオも紹介しました。最終的には、すべての資産所有者に、公式パッチを適用するか、または利用できない場合は、上記の推奨される緩和策を実施することをお勧めします。