不正な VIB(E) パート 2: ESXi ハイパーバイザー内での検出と強化

パート 1では、攻撃者が悪意のあるvSphere インストール バンドル(「VIB」) を使用して、ESXi ハイパーバイザー全体に複数のバックドアをインストールする方法を取り上げ、VIB ペイロード内に存在するマルウェアに焦点を当てました。この記事では、タイムスタンプなどの他の攻撃者のアクションについてさらに詳しく説明し、プロセス メモリをダンプして YARA スキャンを実行する ESXi 検出方法について説明し、ハイパーバイザーをさらに強化して ESXi ホストの攻撃面を最小限に抑える方法について説明します。詳細については、 VMware がvSphere の保護に関する追加情報をリリースしています。

ESXi ロギング

VIRTUALPITA と VIRTUALPIE はどちらも、起動時にvmsyslogdプロセスがアクティビティを記録するのを停止しますが、ハイパーバイザー全体に複数のログ プロセスが存在し、攻撃者のアクティビティを追跡するために引き続き使用できます。

悪意のある VIB のインストール

許容レベルが記述子 XML で変更された場合でも、ESXi システムでは最小許容レベルを下回る偽造 VIB ファイルが許可されないことがパート 1で以前に確認されました。これを回避するために、攻撃者は--force フラグを悪用して、悪意のあるCommunitySupported VIB をインストールしました。このフラグは、 ホストが要求するよりも低い許容レベルを持つ VIB またはイメージ プロファイルを追加します。

VIB をインストールするための--forceフラグの使用の証拠は、ESXi ハイパーバイザーの複数の場所で見つかりました。 ESXi プロファイル XML ファイルは、システムにインストールされたすべての VIB を記録し、各 VIB のインストールに使用される日付、時刻、およびフラグを指定します。このファイルは、パス/var/db/esximg/profileの下にあります。図1 プロファイル XML ファイルに記録された攻撃者の--forceフラグの使用例が含まれています。

/var/log/ファイルesxupdate.logにも、VIB のインストール時に--forceフラグの使用が記録されました。図 2 には、悪意のある VIB が強制的にインストールされていることを記録したイベントが含まれています。

さらに、 VMware では、セキュア ブートの有効化を推奨しています。これにより、ESXi は最初のシステム ブート時に暗号化方式を使用してソフトウェア、ドライバー、およびその他のコンポーネントを検証し、それらのコンポーネントが正当であるかどうかを判断できます。 VMware のガイダンスによると、「vSphere でのトラステッド プラットフォーム モジュール (TPM) 2.0 のセキュア ブート サポートは、システム構成だけでなく、セキュア ブートからのデータを調べることで、vCenter Server が環境の状態を証明または検証できるようにすることで、ESXi セキュア ブート上に構築されます。情報。 vSphere 7 で導入された vSphere Trust Authority は、vSAN および VM 暗号化に使用される暗号化キーへのアクセスを継続的なホスト認証に結び付けます。 vSphere 信頼機関での構成証明に失敗したホストは、シークレットへのアクセスを拒否されます。

タイムスタンプ

Mandiant は、早くも 2013 年 10 月 9 日に--forceフラグが設定された VIB インストールに関するログが記録されていることを確認しましたが、これは攻撃のタイムラインと一致していませんでした。ログ ファイル/var/log/vmkwarning.logは、システム時間が操作されていることのさらなる証拠を提供しました。図 3には、攻撃者のアクションが発生する直前と直後にシステム クロックが変更されたことを記録した 2 つのイベントが含まれています。この動作は、攻撃者がマシンに VIB を最初にインストールした実際の時間を隠蔽するために、タイムスタンプが実行されたことを示唆しています。

sysclogの作成

VIRTUALPITA サンプルrhttpproxy-io (2c28ec2d541f555b2838099ca849f965) を分析すると、サンプルが VMCI ポート番号18098でリッスンしていることがわかりました。リスナーが設定されると、マルウェアは IOCTL 要求コード 1977 を発行して、システムの CID (コンテキスト ID) をフェッチします。バックドアの PID、CID、およびリッスン ポートは、次の形式で/var/log/sysclogに記録されます[<date/timestamp>]nr[!]<<PID>>:<CID>:<port>nn (図 4 参照)。

ゲスト マシンの相互作用

ハイパーバイザーとそれぞれのゲスト マシン間のさらなる相互作用は、 vmware.logという名前の複数のログで発見されました。これらのログは、パス/vmfs/volumes/…/<virtual machine hostname>/vmware.logにあり、エンドポイントに記録されていないホストとハイパーバイザー間の基本的な操作を記録します。このログに記録されるアクションには、ゲスト マシンのログイン、ファイル/ディレクトリの作成と削除、コマンドの実行、およびゲスト マシンとハイパーバイザー間のファイル転送が含まれます。 vmware.log でハイパーバイザーとそのゲスト マシン間のやり取りに注目するには、GuestOps vmware.log含む行をフィルター処理します。

大規模な VIB 検証

以前のブログ投稿では、コマンドesxcli software vib signature verifyを使用して、ESXi ハイパーバイザーによって行われた署名検証チェックに合格しない VIB を特定することに触れました。署名検証チェックを回避できる代替 VIB 構成が存在します。 Mandiant は、VIB がCommunitySupportedとしてインストールされている場合、インストール後にペイロードが改ざんされていない場合、 Signature VerificationフィールドはそれをSucceededとラベル付けすることを確認しました。これは、VMWare またはそのパートナーからの検証なしで VIB を作成しても、検証済みとしてラベル付けされる可能性があることを意味します。

適切に署名されたCommunitySupported VIB および悪意のあるアクティビティを示す可能性のあるその他の異常な構成を説明するために、 VMware は、軽減ガイドの「脅威ハンティング」セクションで、環境の監査プロセスを自動化する検出スクリプトを利用できるようにしました。

さらに、環境内のすべての VIB を既知の正常な VIB のリストと比較できます。 VMware Front Experienceによって作成されたマトリックスは、それぞれの ESXi ビルドにデフォルトで存在すると予想される各 VIB の名前とビルドを分類します。 ESXi ビルド全体で VIB が変更されるたびに、その VIB の追加、変更、または削除を示す公式の VMware パッチ リリース ノートへのマトリックス リンクが作成されます。このマトリックスのサンプルを図 5に示します。

ESXi の検出方法

ESXi は Linux と多くの類似点 (コマンド、ディレクトリ構造など) を共有していますが、完全に VMkernel と呼ばれる独自のオペレーティング システムであるため、ファイル システムをスキャンしてプロセス メモリをダンプする一般的な方法は機能しません。 Mandiant は、今後のインシデント発生時に調査担当者が ESXi ハイパーバイザーをより適切に把握できるように、代替の検出方法を策定しました。

SSHFS を使用したリモート ESXi YARA スキャン

Linux および ESXi 環境全体で VIRTUALPITA および VIRTUALPIE を検出するために複数の YARA ルールが生成されており、このブログ投稿の最初の部分で見つけることができます。これらの検出には、マルウェアの保存と実行に基づいた 2 つの警告があります。攻撃者が ESXi 上の VIB からいずれかのマルウェア ファミリを起動している場合、.vgz 形式で圧縮されているため、VIB 内のサンプルは検出されません。第 2 に、バイナリがメモリ内で実行されているがディスクから削除されている場合、そのバイナリは YARA のファイル システム スキャンによって検出されません。

YARA は ESXi ホスト上で直接実行されないため、Mandiant はsshfsを利用して ESXi ハイパーバイザーのリモート YARA スキャンを実行しました。

前提条件

ESXi マシンをスキャンする前に、いくつかの前提条件を満たす必要があります。メモリがダンプされている ESXi マシンの場合、次の両方が必要です。

• マシンへのルートアクセス
• ESXi サーバーでSSH が有効になっている

ESXi マシンが正しく構成されたら、SSH 経由で ESXi マシンと通信できるように Linux マシンをセットアップする必要があります。この Linux マシンには、以下もインストールする必要があります。

• sshfs
• 子供

YARA スキャンの実行

ESXi プロセス メモリのダンプ

Linux マシンのように ESXi ハイパーバイザーからプロセス メモリをダンプしようとすると、/proc/ ディレクトリが空であるか、メモリのダンプを試みるために使用されるコマンドの単一の PID が含まれていることがすぐに明らかになります。 ESXi からプロセス メモリ (および場合によっては完全なバイナリ自体) を回復するには、ネイティブ ツールgdbserverとcore2ELF64と呼ばれる github ツールを組み合わせて使用できます。

前提条件

プロセス メモリをダンプする前に、いくつかの前提条件を満たす必要があります。 ESXi マシンの場合、次の両方が必要です。

• マシンへのルートアクセス
• ESXi サーバーでSSH が有効になっている

ESXi マシンが正しく構成されたら、SSH 経由で ESXi マシンと通信できるように Linux マシンをセットアップする必要があります。この Linux マシンには、以下もインストールする必要があります。

• gdb
• core2ELF64

メモリのダンプ

ESXi プロセス メモリをダンプするには、gdbserver を使用して、PID で指定された現在実行中のプロセスにフックし、任意のポートでリッスンします。

リッスンすると、Linux マシンは ESXi サーバーのリッスン ポートへの SSH トンネル (ポート転送) を作成します。ここで、指定されたプロセスのコア ダンプを作成するために gdb が使用されます。

プロセス抽出

コア ファイルが作成されると、Github プロジェクト core2ELF64 を使用してプログラムを再構築できます。

ソース

• gdbserver を使用した ESXi プロセスへのフック

ESXi の強化

ネットワークの分離

ESXi ホストでネットワークを構成する場合は、分離された管理ネットワークで VMkernel ネットワーク アダプタのみを有効にします。 VMkernel ネットワーク アダプタは、ESXi ホストにネットワーク接続を提供し、vSphere vMotion、vSAN、vSphere レプリケーションなどの機能に必要なシステム トラフィックを処理します。仮想化インフラストラクチャが使用する vSAN やバックアップ システムなどのすべての依存テクノロジが、この分離されたネットワークで利用できることを確認します。可能であれば、この分離されたネットワークに排他的に接続された専用の管理システムを使用して、仮想化インフラストラクチャのすべての管理タスクを実行します。

ID とアクセス管理

ESXi および vCenter Server を Active Directory から分離し、vCenter Single Sign-On を使用することを検討してください。 Active Directory から ESXi と vCenter を削除すると、侵害された Active Directory アカウントを使用して仮想化インフラストラクチャを直接認証することができなくなります。管理者が仮想化インフラストラクチャの管理とアクセスに個別の専用アカウントを使用していることを確認してください。 vCenter Server インスタンスへのすべての管理アクセスに多要素認証 (MFA) を適用し、すべての管理資格情報を Privileged Access Management (PAM) システムに保存します。

サービス管理

ESXi ホストのサービスと管理をさらに制限するには、ロックダウン モードを実装します。これにより、vCenter Server を介してのみ ESXi ホストにアクセスできるようになり、一部のサービスが無効になり、一部のサービスが特定の定義済みユーザーに制限されます。組み込みの ESXi ホスト ファイアウォールを構成して、隔離されたネットワーク上の管理システムに関連する特定の IP アドレスまたはサブネットからのみ管理アクセスを制限します。 vSphere Installable Bundle (VIB) の適切なリスク許容レベルを決定し、ESXi ホストのセキュリティ プロファイルで許容レベルを適用します。これにより、ホストの整合性が保護され、署名されていない VIB をインストールできないようになります。

ログ管理

潜在的な悪意のある動作をプロアクティブに検出し、実際のインシデントを調査するには、ESXi 環境の集中ログが重要です。すべての ESXi ホストと vCenter Server のログが組織の SIEM ソリューションに転送されていることを確認します。これにより、通常の管理アクティビティ以外のセキュリティ イベントを可視化できます。

謝辞

Brad Slaybaugh、Joshua Kim、Zachary Smith、Jeremy Koppen、Charles Carmakal の各氏には、このブログ投稿で説明したマルウェア ファミリの調査、技術レビュー、および検出/調査手法の作成を支援していただき、特に感謝しています。さらに、この調査に協力してくれた VMware にも感謝します。