続・EMET - メモリアドレスを攻撃者より先に確保せよ

復活第2稿である。筆者の近況であるが、twitterでつぶやいていたりもする。こちらもアライ出しとあわせてどうぞ。

それでは前回に引き続き実際にEMETの使い方をご紹介したい。以下の表にEMETの使用法一覧を示す。EMETは基本的にEMET_conf.exeを使用することで設定が可能である。EMETを上書きなどの心配がないフォルダにコピーないし移動させてから、EMET_conf.exeを使用する。なお、パラメータの実行ファイル名にはフルパス名は入れてはならない。あくまでも実行ファイル名のみである。ご注意されたい。

EMETの設定方法一覧

目的	コマンド
EMETの保護対象に実行ファイルを追加	EMET_conf --add 実行ファイル名
EMETの保護対象の実行ファイル一覧を表示	EMET_conf --list 実行ファイル名
EMETの保護対象から実行ファイルを削除	EMET_conf --delete 実行ファイル名
EMETの保護対象からすべての実行ファイルを削除(リセット)	EMET_conf --delete_all

実際に設定した例を図に示す。

Microsoftによると、EMETは実際に次のプラットフォームでテストされたという。

• 32 bit: Windows XP、Server 2003、Vista、Server 2008、Windows 7
• 64 bit: Vista、Windows 7、Windows 2008 R2

また、次の実行ファイルに対してもテストされたという。

• iexplore.exe(Internet Explorer)
• winword.exe(Microsoft Word)
• excel.exe(Microsoft Excel)
• acrord32.exe(Adobe Reader)
• firefox.exe(FireFox)
• outlook.exe(Microsoft Outlook)
• powerpnt.exe(Microsoft PowerPoint)

一般に我々がよく使用するアプリケーションに対してテストが行われていると考えてよいだろう。

さて、実際にEMETを適用するとどのような変化が現れるのだろうか? 外見上は、何ら変わりはない。そこで、EMETを適用した実行ファイルを起動し、Immunity Debuggerを使用してそのプロセスにアタッチしてみることで、内部的な変化を確認してみよう。ちなみにImmunity Debuggerは米国のフロリダ州に所在しているImmunity社によって開発されているフリーのデバッガである。コマンドラインからExploitコードの開発を効率よく進めることのできるコマンドが付随しており、Pythonスクリプト用のAPIを用意することで特定の目的のためのスクリプトを作成することができるといった、情報セキュリティ技術者は必携のソフトウェアのひとつである。

さて、ではImmunity Debuggerの出力を見てみよう。「m」ボタンを押下すると、アタッチしたプロセスで現在マッピングされているメモリの状況を確認できるサブウィンドウが開く。その際、図のようなアドレスマッピングに気づくことだろう。

これは、0x06060606や0x07070707、0x08080808、0x09090909、0x0A0A0A0AといったHeap Sprayingでよく使用されるメモリ領域がすでに確保されていることを示す。実のところ、これらのHeap Spraying対策として確保されるメモリ領域は以下のレジストリに「heap_pages」という値でEMETの初期設定時に自動的に入力され、使用されるようになる。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET

一般的にHeap Sprayingを使用すると、これらのアドレスにシェルコードが埋め込まれるような大量のデータを埋め込むことが実現できる。そして、これらのメモリアドレスを命令ポインタの移し先とすることで攻撃を成功させることができた。しかし、EMETを使用するとそれらのアドレスはHeap Sprayingが行われるより前に確保されているため「早い者勝ち」のルールが適用されるメモリアドレスの確保において、それらのアドレスにはシェルコードが書き込まれなくなる。また、命令ポインタを移したとしてもアクセス例外が発生するだけであり、シェルコードが実行されることはない。よって、Heap Sprayingを使用した脆弱性悪用からはPCを保護することができる---そうしたシナリオをEMETは実現できるのである。

むろん、先に紹介したEMETの初期設定時のメモリアドレスを避けるようなテクニックが使用された場合を想定すると、完璧とは言い難いだろう。それは、前回紹介したとおりMicrosoftも「一般的な方法ではない」と述べている通りである。それでも、従来のテクニックが使用できなくなることは、攻撃者側の武器であるシェルコードの信頼を低下させるには十分だろう。