バトルフィールド-ハイパーバイザー

ハッカー競争NeoQUEST-2013の学内ラウンドのタスクの1つで、クエストの参加者は恐るべき敵、ハイパーバイザーに直面しました！ 刑務所から脱出するために、彼らはプロセスの記憶から行を読むだけでした。 しかし、いくつかありました...ハイパーバイザーは、あらゆる点で競合他社の生活を困難にしました。
•プロセスメモリの読み取りを防止し、アドレススペースを制御
•アンチデバッガーとして機能
•プロセスイメージの整合性をチェックし、そのセクションのハッシュを計算しました
•プログラムをコンピューターなどにバインドします。

参加者は、ハイパーバイザーをバイパスするための重要な解決策を見つけるために頭を砕かなければなりませんでした！ 自分の場所を想像して、ハイパーバイザーと戦い、一歩一歩、「コーン」を詰めて、時折戻って、最後に、私たちは勝ち、鍵を手に入れます！ カットシーンの下で-ハイパーバイザーがキーへのアクセスを制御する方法、および参加者をバイパスする方法がキーを使用しようとした方法の詳細なレビュー。

すべての始まり

NeoQUEST-2013の対面ツアーの参加者（2月のNeoQUESTのオンラインツアーの勝者）には、勝つための強力なインセンティブがありました。 彼らは、完全にもっともらしい電気椅子で処刑されることを避けるために、刑務所の寒くて湿った壁から抜け出す必要がありました！ もちろん、刑務所は仮想でしたが、椅子は本物でした！



出場者は「逃げる」ために8時間を与えられ、各タスクを完了するのに約2時間かかることを期待して、5つのタスクを準備しました（1つは予備です！）が、誰も合格しなかったと思ったことがわかったので、 4つのタスクで十分でした）。
NeoQUEST 2013のタスクは、暗号化、クラウドおよびWebテクノロジー、ボットネットなど、情報セキュリティの共通領域の両方のセキュリティと、プログラミングさえ必要とする非標準のデバイスおよびテクノロジー（ハイパーバイザー、スマートカードなど）のセキュリティに関するものでした。 「むき出しの」鉄、特にArduino SDKコントローラー。 クエストの勝者である、 NeoQUEST 2013の対面ツアーの主な賞であったRSAカンファレンスからアムステルダムに戻ったばかりのAVictor は、それぞれのタスクについて少し書いています！ 2位はv0s （Vlad Roskov ）で、 Caterpillarから報酬で保護されたCat B15スマートフォンを受け取りました。

そして今、ハイパーバイザーについてです！

v0のみがハイパーバイザーをバイパスできました。 タスクは次のように定式化されました：KeyReader.exe実行可能ファイルが存在する2つの同一のWindowsコンピューターが利用可能です。 入力時に、彼は参加者のIDを受け取り、 「キーが正常に読み取られました。」と表示します。 終了するには任意のキーを押してください。 デフォルトでは、参加者は管理者権限を持つアカウントで作業します。 キーを受け取る必要があります。



これら2つ以外のマシンで起動すると、KeyReader.exeがエラーを報告します。



参加者の代わりに自分自身を想像し、真実に到達するようにしてください！ メッセージから判断すると、キーはプロセスメモリにあり、そこから読み取る必要があります。 簡単に聞こえますが、やってみてください。 Windowsタスクマネージャーを実行し、KeyReader.exeプロセスを見つけて、キーストロークの待機時にダンプし、ダンプをRussinovichの文字列にフィードします 。 ダンプの重量は3.3MBで、ユーティリティは55,000行を検出します。 それらの中からキーを検索する方法はあまり明らかではありませんが、キーという単語で検索すると、次の行が見つかります。



これは必要なものではないようです。 正確に何が起こったのか、ダンプにこの行が含まれている理由はまだ明らかではありませんが、これは明らかにパスワードではありません。 KeyReader.exeがIDAを使用してどのように機能するかを理解してみましょう。すでに何が起こっているかを十分に理解した上で、タスクを完了してください。 プログラムは簡単に逆コンパイルでき、一般的にはその意味が明確になります。 基本的なロジックは次のとおりです。



ページアラインメモリが割り当てられ、ゼロに設定された後、参加者のIDが読み取られ、 AcquireKey関数が呼び出されます。 AcquireKey関数は小さく、アセンブラー挿入であった次のコードが含まれています。



コードには、vmcall命令が含まれています。この命令は、レジスタを介して渡されるパラメーターを使用してハイパーバイザーへの呼び出しを実行します。 EAXレジスタには値「NeoQ」が含まれ、EDXレジスタには値「strt」が含まれ、EBXレジスタには以前に割り当てられたメモリページへのポインタが含まれ、ECXレジスタにはページサイズが含まれ、EDIレジスタには参加者IDが含まれます。 呼び出しの結果は、ESIレジスタを通じて返されます。 簡単にするために、ハイパーバイザーが存在する場合はvmcall命令がハイパーバイザーに制御を転送し、存在しない場合は#UDを呼び出すと想定できます。

命令の操作アルゴリズムの完全な説明は、Intelのドキュメント64-ia-32-architectures-software-developer-vol-2b-manualにあります 。 これで、キーがハイパーバイザーに保存され、特定のパラメーターでvmcall命令を使用してアクセスされたときにプログラムメモリにコピーされることが明らかになりました。

プログラムのステップをデバッグして、ハイパーバイザーにアクセスした後のメモリ内の内容を確認してみましょう。 OllyDbg 2.01をデバッガーとして使用します。 デバッグ中にKeyReader.exeを実行し、vmcallの後の次のステートメントにブレークポイントを設定します。 参加者IDを入力してEnterを押し、確立されたブレークポイントに到達します。 EBXレジスタにはアドレス0x1F5000が含まれていますが、ゼロがあります。 ESIも0です。



F9を押して、エラーが発生したことを確認します。



3つのデバッグメカニズムがあります。
•コードツールキットint3命令
•各命令の後に割り込みint1を使用した段階的なデバッグ
•デバッグレジスタD0〜D7。メモリアクセスをキャッチできます。
この場合、命令にブレークポイントをインストールするときに、命令の最初のバイトを0xcc（int 0x3）で上書きします。 プログラムがこの場所に到達すると、int3が実行され、制御がデバッガーに渡され、擦り切れたバイトが復元され、復元された命令が実行され、命令の上に再びint3が書き込まれます。 したがって、ブレークポイントは実行中のイメージを変更し、ハイパーバイザーは明らかに、キーをプログラムメモリにコピーする前にその整合性をチェックします。 エラーメッセージもこれを示唆しています。

この問題は、次の方法で簡単に解決できます。 vmcallの前にいくつかの命令をブレークポイントにインストールし、ブレークポイントに入った後、それを削除し、ステップごとにコードを実行します。 Vmcallを実行すると、次の結果が得られます。



EBXレジスタでは、アドレスは0x165000です。このアドレスには、既におなじみの文字列"key：NICE TRY、THIS IS NOT A KEY"があります。 ハイパーバイザーは、キーが読み取られないようにします。

KeStackAttachProcess関数とKeUnstackDetachProcess関数を使用してプロセスのメモリを読み取る小さなドライバーを作成できますが、すぐにこれも機能しないとしましょう。 厄介なパスに進み、Windowsに関心のあるプロセスのメモリをディスクに強制的にアンロードさせ、pagefile.sysを解析して、キーを持つバッファーに対応するページを見つけることができます。 しかし、このページには同じ行が表示されます。

次の方法を試してみましょう-dllをKeyReaderプロセスに挿入し、そこからキーが置かれているメモリを読み取ります。 まず、プロセスを開始し、Olly Dbgを使用してプロセスにアタッチし、キーを持つバッファーが配置されているアドレスを確認します。 バッファーへのポインターは0x40eb3cにあります。



この場合、バッファのメモリは0x600000に割り当てられ、デバッガとして、アプリケーションは引き続き動作します。 このアドレスのメモリを読み取り、a.txtファイルでディスクに保存するdllを作成します。 コードは次のようになります。



インジェクターとして、WindowsのC / C ++経由の例を使用しました 。 dllを挿入し、次の行を含むa.txtファイルを取得します。



これが鍵です。

KeyReaderプロセスイメージに入らないコードインジェクションの主題のバリエーションは解決策になります。 たとえば、デバッガーの参加者の1人が、getch関数によって呼び出されるkernel32.dllのReadConsoleInputA関数のコードを修正し、そこから既知のアドレスの行を読み取りました。 ご覧のとおり、タスクは最も難しいものではありませんが、最終的には1人だけがタスクを管理しました。 ほとんどの場合、これは時間の不足によるものであり、タスク自体は、答えにつながる論理的な連鎖をほとんど意味しないようなものです。 参加者は、ある時点で作業バージョンにつまずくために、他の誰かのプロセスの記憶を読むために知っているすべての方法を整理しなければなりませんでした。

一般に、このタスクを準備することは、おそらくそれを実行することよりもさらに興味深いでしょう:)。 ページへのアクセスを制御するには、仮想アドレスから物理アドレスへのページに関連付けられているすべての変換テーブルの変更を制御する必要がありました。 さまざまなマッピングオプションと、アクセスを制御する物理ページのアドレスを変更できるという事実を考えると、これはそれほど簡単ではありません。

ハイパーバイザーは、あるケースではキーへのアクセスを許可し、別のケースではそうではありませんか？ キーでページにアクセスするとき、彼は3つの条件をチェックしました。
•読み取りはユーザーモードから行う必要があります
•キーにアクセスするプロセスイメージのそのセクション.textのハッシュは厳密に定義する必要があります
•キーは、vmcallがキーを受信するために呼び出されたアドレス空間からのみ読み取ることができます。

最初の条件は、カーネルからキーを読み取るすべての試みを拒否しました。 これらには、ReadProcessMemory関数と独自のドライバーの作成が含まれます。 2番目の条件では、イメージコードの変更とブレークポイントの設定が許可されませんでした。 ところで、テキストセクションのみがチェックされたため、異なる方法で呼び出されるコードを使用して独自のセクションを追加し、エントリポイントを変更できます。 次に、コードからキーを取得する関数を呼び出して、ディスクに保存します。 3番目の条件では、KeyReaderプロセスのメモリがキーを読み取るために蓄積された他のプロセスは許可されませんでした。 このような状況を取得するには、Windows7でそのような機能を備えた既製のユーティリティが見つからなかったため、このような状況を取得するには、独自のドライバーとそれと通信するアプリケーションを作成する必要があるため、この条件はやや大げさです。 Windows XPでは、物理メモリの読み取り時にWinHex RAM Editorは同様の方法で機能しました。 条件の主な目標は、既成のユーティリティのみを使用して、1行のコードを記述することなくタスクを完了できないことでした。

そして結論として...

ハイパーバイザーを使用してタスクを準備する際、参加者にタスクの異常な性質に疑問を抱かせたいと思いました。 結局のところ、プロセスメモリから行を読み取る際の問題は何でしょうか？ そして、1人の参加者だけがタスクを完了したという事実から判断して、成功しました！ Habrの読者にとって興味深いことを願っています！ すぐに、最も「鉄」のタスクNeoQUEST-2013の詳細な分析を含む記事を期待してください！