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゚スケヌプは、さたざたなセキュリティメカニズムを迂回するバむナリ脆匱性のハヌドコアな利甚であるだけでなく、忘れられおいた叀いものでもありたす。



All Articles