VMエスケープ：101

この記事では、VMware WorkStationとVirtualBoxからの明白な（そうではない）エスケープ方法についてお話しするとともに、いくつかの興味深い特別なケースを検討します。

VMware WorkStation、VirtualBox（Oracle VM VirtualBox）-コンピューターで複数のオペレーティングシステムを同時に実行できる仮想化ソフトウェア製品。

参加する代わりに

VMエスケープは、多くのセキュリティ研究者の心を刺激します。 ハッカーの間では、これらのエクスプロイトは非常に高度で複雑であると考えられています。 そのような例はありますが、非常に少数です（最も興味深いもののいくつか： VMware CloudBurst 、 Xen Hypervisor Sysret VM Escapeの高度な脆弱性 ）。 しかし、仮想マシンからのコードが実際に（または背面に）到達するためには、何かを発明する必要があるとは限りません。 そのため、通常のユーザーに対する攻撃の場合、aを取り、最も一般的なものを切り刻むことができます。 さらに苦労せずに行きましょう。

パブリックフォルダ感染

これまでで最も簡単で効果的な方法。 このバナリティについて特別なことは何もありません。共有ネットワークリソースを介した悪意のあるコードの拡散は、NTシステムの多くのワームで歴史的に実装されていることがわかります。

VMware Workstationの共有フォルダーオプション


VirtualBoxのパブリックフォルダーオプション

キャプチャされたUSBデバイスの感染

検討された以前の方法よりも有効性に劣りません。 また、実行可能ファイルの感染、不幸なautorun.infファイル、 LNK脆弱性などの転送によって自動的に拡散するUSB​​デバイスの接続を監視する組み込みのウ​​ォッチドッグを備えたITWマルウェア（ Flameのような ）がかなり実装されています。

当然、この方法の主な条件は、仮想マシン用の特定の構成を持つUSBコントローラーデバイスの存在です。

VMware Workstationでは、USBコントローラーの設定が正しく実装されていないようです。フィルターはすべてのデバイスですぐに動作し、これらの危険な設定は新しい仮想マシンの作成時にデフォルトで設定されます。

VMware WorkstationのUSBコントローラーオプション



それどころか、VirtualBoxはより柔軟性が高く、特定のデバイスにコントローラーフィルターを設定できますが、同時に空のフィルターをインストールしてUSBをキャプチャすることもできますが、これはセキュリティの面で不利です。

VirtualBoxのUSBコントローラーオプション

共有クリップボードへの攻撃

VMwareワークステーション

仮想マシンの設定

はじめに、DnD（Drag'n'Drop）のアーキテクチャと一般的なクリップボードを見てみましょう。 ゲストとホスト間のデータ転送は、GuestRpcメカニズムを介して実装されます。これは基本的にBackDoor I / O（0x1E）コマンドです（VMware BackDoor I / Oを知らない、または忘れた場合： https : //sites.google.com/ site / chitchatvmback / backdoor ）。

DnDのモデル、クラス階層に基づいた一般的なクリップボード（ OpenToolsソースから取得 ）：



同様に、GuestRpcにはコマンドのテーブルもあり、そのリスト全体はVMwareを完全に反転した後にのみ取得できます（ちなみに、RpcToolはゲストユーティリティの標準セットに含まれており、GuestRpcコマンドを適宜送信できます）。 DnDと共通クリップボードの場合、次のコマンドが使用されます（「トランスポートインターフェイス」とも呼ばれます）。
dnd.transport
copypaste.transport

各トランスポートインターフェイスには独自のコマンドセットがあり、データパケットのサービスヘッダーで既に送信されています。

したがって、たとえば、copypaste.transportのコマンドセットは次のようになります。

typedef enum { CP_CMD_REQUEST_CLIPBOARD = 2000, CP_CMD_REQUEST_FILES, CP_CMD_RECV_CLIPBOARD, CP_CMD_SEND_CLIPBOARD, CP_CMD_GET_FILES_DONE, CP_CMD_SEND_FILES_DONE, } CopyPasteCmdV4; 

パッケージCP_CMD_SEND_CLIPBOARD、クリップボードが直接赤で強調表示されます
クロスプラットフォーム形式：



したがって、一般的なVMwareクリップボードをスプーフィングするための可能なシナリオは次のとおりです。

• ユーザーが実行ファイルをゲストからホストにコピーするとき;
• ユーザーがゲストマシンで中間フォーカスを使用して実行ファイルをホストにコピーするとき。

したがって、これは、クリップボードモニターを作成する（BackDoor I / Oを介して直接リクエストを送信する）か、多数のフックをインストールし、悪意のあるコードをゲストユーティリティvmtoolsd.exeプロセスに（NTシステムで）挿入することで実現されます。

明らかに、実行可能ファイルの代わりに、Officeエクスプロイトドキュメントなどがあります。

この攻撃の簡単なデモ（ゲストユーティリティに直接注入）：

Virtualbox

残念ながら（攻撃者にとって）、VirtualBoxは実行可能ファイルのDnDおよび一般的なクリップボードへの転送を公式にサポートしていません。



しかし、私は公式のVirtualBoxフォーラムにあるサードパーティのプロジェクトVMTransferFilesについて言及せざるを得ません。

もちろん、機能を拡張してファイルを転送することもできますが、当然のことながら自分の責任とリスクで行ってください。

仮想化に間接的に関連するソフトウェアへの攻撃

情報セキュリティの分野の多くの多様な研究者が仕事で仮想マシンを何らかの形で使用していることは、秘密ではありません。 たとえば、マルウェアアナリストは、多くの場合、仮想化の利点を使用してトラフィックまたはマルウェアの動作を分析します。
ここから、このサブトピックのルーツが成長します。この作業中またはその作業中に使用したソフトウェアに応じて勝ちます。

Wireshark

さまざまな研究ソフトウェアにブラックリストを使用することは、あらゆる種類のマルウェアに長い間巻き込まれてきました。実際、Wiresharkはこのリストで最も人気のある候補の1つです。

Rovnixブートキットブラックリストの例：



そのため、Wiresharkの検出をバイパスするという単純で怠zyな決定を頻繁に観察しました。それを単にホストで実行し、仮想マシンのトラフィックを分析するだけです。 さらに、多くのサンドボックスシステムはトラフィックpcapファイルを自動的に生成します。これは通常、Wiresharkを使用してホスト上でも分析されます。 そのため、VMエスケープの目的でWiresharkディセクタのさまざまなリモートバグとローカルバグを使用することをお勧めします。

脆弱性の例として、 CVE-2014-2299 -MPEGファイルのパーサーのバッファオーバーフローを使用することにしました。 MetaSploitのモジュールであるエクスプロイトソースコードが既にあります 。

戦闘電卓を使用したビデオデモ：

Virtualkd

開始する前に、WinDbgデバッガーを有効にしたリモートカーネルデバッグプロトコルを介して仮想マシンからホストを攻撃する方法についての古くて興味深い記事に注目します。

VirtualKDは、VMwareまたはVirtualBoxでのカーネルデバッグパフォーマンスを向上させるために設計されたオープンソースプロジェクトです。 これは非常にカスタムな方法で実装されます（VMwareでの実装を検討します）-ホスト側では、dllがvmware-vmxプロセス（仮想マシンのプロセス）に挿入され、新しいコマンドとそのハンドラーがGuestRpcテーブルにパッチ/追加されます。 ゲスト側から、KDVM.DLLドライバーに実装された実装のために、多くのKd *関数（KDCOM.DLL）がインターセプトされます。

本質的に、シンプルなスキームが得られます-KDCOMプロトコルはVMware BackDoor I / O（GuestRpc）を介してホストにトンネリングされ、WinDbgがリッスンするパイプチャネルに直接展開されます。

VirtulKDアーキテクチャ（VMwareに固有）：



そして、すべてがうまくいくでしょう、ユーティリティは本当に動作しますが、私のテーマのために、私は簡単なバグを探してそのソースを調べることにしました。 実際、1時間以内に些細な整数オーバーフローが見つかりました。

そのため、ヘッダーファイルrpcdisp.hのKdRpcDispatcher :: SendPacketメソッドで、追加のサービス情報でラップされたKDCOMパケットのデータが処理されます。
このデータの一部は正しく検証されていません。



図からわかるように、pParams [1]とpParams [2]を追加した結果は簡単にオーバーフローする可能性があります（たとえば、結果としてpParams1 == 0xFFFF0000とpParams2 == 0x18000が0x8000になります）。 さらに、コードに沿ってpParams [1]がデータへのオフセットとして使用され、その結果、一般的な読み取りエラーが発生します。

このデータの処理は、vmware-vmx仮想マシンのプロセス内のjected.dllモジュールのコンテキストで行われることを思い出させてください。VMware仮想マシンプロセスがクラッシュする例外的な状況です。

当然のことながら、このバグについてsysprogsチームに書きました。彼らは「ありがとう。しかし、影響が見られないので、パッチを適用しません」というスタイルで返信しました。 さらに、何らかの理由で、ゲストの下でカーネルモードでのみバグが操作されると感じましたが、実際にはすべてが正反対であり、さらに優れています。操作には特権はまったく必要ありません。 実際、悪用パッケージはBackDoor I / Oに悪意のあるパッケージを直接送信します。概念のサイズは原則として非常に小さく、必要に応じて任意のマルウェアに簡単に実装できます。

また、このDoS VMのバグは非常に迅速に発見され、VirtualKdにはより重大な脆弱性が潜んでおり、実際のVMエスケープにつながる可能性があります。 エクスプロイトを詳しく調べたい人のために、そのソースコードを示します 。

そして、この攻撃の小さなデモ：

レガシー脆弱性テクノロジーの使用

VMGL

この特定のケースは、KVMとXenに関連しているものの、私には思えるが、この主題を完全に特徴づけている。

VMGLは、フロントエンドOpenGL 3dハードウェアアクセラレーションに関する長い間放棄されたプロジェクトですが、 KVMプロジェクトの公式ページなどにはまだリンクがあります。

ソースコードを入手できるプロジェクトサイト 。

大まかに言うと、VMGLは、ゲスト仮想マシンからホストGPUに直接送信されるTCP / IPプロトコルスタックGLコマンドをトンネリングするクライアントサーバーテクノロジーです。

VMGLアーキテクチャ

実装をより深く研究し、ソースコードを見て、 ChromiumプロジェクトがVMGLの基礎であることがわかりました。 したがって、この同じChromiumプロジェクトは、VirtualBox仮想マシンの3Dアクセラレーションの基礎にもなり、バグについてはすでに非常によく研究されています。

したがって、VMGLをインストールすると、Chromiumエンジンの設計の加速だけでなく、少なくとも3つの既知の脆弱性 （CVE-2014-0981; CVE-2014-0982; CVE-2014-0983）も得られます。

脆弱性のため、コードを直接実行することはできませんが、理論上のVMエスケープは依然として可能です。何らかの理由でこの放棄されたプロジェクトを使用している場合は、確実に心配する必要があります。

VirtualBoxの一部としてパッチを適用したChromium（util \ net.c）のフラグメント（現在、脆弱なコマンドハンドラーは単にホスト上に物理的に存在しません）：

おわりに

これらのシンプルでかなり使いやすい方法は結果をもたらし、一部の攻撃で実際に遭遇しました。 したがって、VMエスケープは、さまざまなセキュリティメカニズムを迂回するバイナリ脆弱性のハードコアな利用であるだけでなく、忘れられていた古いものでもあります。