セキュリティキャンプ講義「仮想化技術を用いたマルウェア解析」にチャレンジしてみた(プラグイン開発編)
前回のエントリでDECAFをコンパイル、仮想マシンの用意・起動とプラグインを読み込ませるところまでやった。
今回は講義の本題であるプラグインの開発をやっていく。
私自身はQemu, DECAFや関数Hook，PEB構造体とかも全く知らず，マルウェア解析の経験もない状態で始めてみたが，何とかなったので興味があるならチャレンジしてみれば楽しいと思う．
最終的なプラグインはpoppycompass/red · GitHubに置いてある．適宜参照してほしい．
プラグイン基礎
プラグインの基本をIsDebuggerPresentをHookするプラグインgeteipを使って説明する．
Hookとは，プログラムの特定の箇所にユーザが定義した処理を追加することらしい．
今回で言うと，IsDebuggerPresentが実行される前と後に任意の処理を追加する関数Hookのことを指す．
前回のエントリのコマンドを一通り試した人は<your_path>/DECAF/decaf/plugins/geteip以下にあるはずである．
まだ持っていない人は
$ git clone https://github.com/ntddk/geteip
でダウンロードすること．
このプラグインの主なファイルはplugin_cmds.hとgeteip.cである．
これからそれぞれの内容を見ていきたい．
なお，解説は現在の私の理解であるため，誤り等が含まれることがある．見つけたら遠慮なく指摘していただけるとありがたい．
plugin_cmds.h
プラグインに実装した機能はqemuのコマンドとして実行する．
このコマンド名はmon_cmd_tで設定する．具体的な設定は以下の通り．
{
.name = "geteip", // コマンド名
.args_type = "procname:s?", // 引数タイプ．今回は特定のプロセス名を引数に取る
.mhandler.cmd = do_monitor_proc, // コマンド実行時に実行する関数名
.params = "[procname]", // ？？？用途不明？？？
.help = "tracking EIP of [procname] as block"// コメント
},
このプラグインではplugin_cmds.hで構造体を定義し，geteip.cにて
static mon_cmd_t geteip_term_cmds[] = { #include "plugin_cmds.h" {NULL, NULL, }, };
とインクルードしている．当然のことながらgeteip.cの方に埋め込むこともできる．
コマンド名は自由に変えることができるが，変更したら*.cの名前やソースの関数名も合わせて変更しないと混乱する．
geteip.c
全部説明すると長いので，Hook関連の場所だけを抜粋して説明する．
// Hook用のハンドル static DECAF_Handle isdebuggerpresent_handle = DECAF_NULL_HANDLE; typedef struct { uint32_t call_stack[1]; //paramters and return address, 今回は引数がないのでreturn adddressが入る． DECAF_Handle hook_handle; } IsDebuggerPresent_hook_context_t; // 関数Hookには関数ごとにこの構造体を用意する． /* * BOOL IsDebuggerPresent(VOID); */ // IsDebuggerPresent終了時に呼び出される static void IsDebuggerPresent_ret(void *param) { IsDebuggerPresent_hook_context_t *ctx = (IsDebuggerPresent_hook_context_t *)param; hookapi_remove_hook(ctx->hook_handle); DECAF_printf("EIP = %08x, EAX = %d\n", cpu_single_env->eip, cpu_single_env->regs[R_EAX]); free(ctx); } // IsDebuggerPresent開始時に呼び出される static void IsDebuggerPresent_call(void *opaque) { DECAF_printf("IsDebuggerPresent "); IsDebuggerPresent_hook_context_t *ctx = (IsDebuggerPresent_hook_context_t*)malloc(sizeof(IsDebuggerPresent_hook_context_t)); if(!ctx) return; DECAF_read_mem(NULL, cpu_single_env->regs[R_ESP], 4, ctx->call_stack); ctx->hook_handle = hookapi_hook_return(ctx->call_stack[0], IsDebuggerPresent_ret, ctx, sizeof(*ctx)); } // 監視対象プロセス作成時に呼び出される static void geteip_loadmainmodule_callback(VMI_Callback_Params* params) { if(strcmp(params->cp.name,targetname) == 0) { DECAF_printf("Process %s you spcecified starts \n", params->cp.name); target_cr3 = params->cp.cr3; // Hookしたい関数を登録 isdebuggerpresent_handle = hookapi_hook_function_byname("kernel32.dll", "IsDebuggerPresent", 1, target_cr3, IsDebuggerPresent_call, NULL, 0); blockbegin_handle = DECAF_register_callback(DECAF_BLOCK_BEGIN_CB, &geteip_block_begin_callback, NULL); } }
プラグインをロードするとinit_pluginが呼び出される．geteip_initではVMI_register_callback関数で監視対象プロセス作成時にgeteip_loadmainmodule_callbackを呼び出すよう登録している．
実行
作成したプラグインはコンパイルしてから起動した仮想マシンにロードする．
コンパイル
$ pwd /home/<user>/DECAF/decaf/plugins/geteip $ ./configure --decaf-path=/home/<user>/DECAF/decaf $ make
geteip.soが作成されていれば成功．
ロード
(qemu)のプロンプトが出ている状態で
(qemu) load_plugin /home/<user>/DECAF/decaf/plugins/geteip/geteip.so (qemu) geteip blue.exe
のように使う．今回であればロード時にHello, World!のメッセージがでるはず．
注意点
Anti-Qemu trick回避
IsDebuggerPresent Hook
IsDebuggerPresentはデバッグ
* されている : 0以外
* されていない: 0
を返す関数．
今回だと，デバッグしていることを隠したいからIsDebuggerPresent終了時に戻り値を0に書き換えてやるとblue.exeはデバッグされていないと勘違いさせることができる．
geteipのプラグインは関数Hookまで書いてあるから，戻り値を書き換えるだけで良い．
関数終了時の処理を少しだけいじる．戻り値はqemuのEAXに入っている．
// IsDebuggerPresent終了時に呼び出される static void IsDebuggerPresent_ret(void *param) { IsDebuggerPresent_hook_context_t *ctx = (IsDebuggerPresent_hook_context_t *)param; hookapi_remove_hook(ctx->hook_handle); cpu_single_env->regs[R_EAX] = 0; // 追加 DECAF_printf("EIP = %08x, EAX = %d\n", cpu_single_env->eip, cpu_single_env->regs[R_EAX]); free(ctx); }
これでIsDebuggerPresentの戻り値は常に0となる．
ここからようやく課題スタート．
課題プログラム
一つ一つのLevelが回避できることを確認していきたい人は，これからは下に書いたコードをgeteip.cに書き加えていけば各Levelを回避していけるはず．
未検証なので，回避できた・ここが足りなかったなどを教えてもらえると嬉しい．
前回のエントリのコマンドを一通りやっていれば/home/<user>DECAF/VMsにblueというディレクトリがあるはず．
やっていない人は
$ git clone https://github.com/ntddk/blue.git
でダウンロードする．
blue/Release/blue.exeがプログラム本体で，blue/blue/blue.cppがソースコード．
構造は極めて簡単で，
if (IsDebuggerPresent() == FALSE && Blue() == 0 && Charlie() == 0 && Delta() == 0 && Echo() == 0) Flag();
の通り，各関数の戻り値を0になるようにする．一つでも回避できないと即停止．
Level1: Blue
static inline int Blue() { printf("\n[Level 1] Blue ..."); Sleep(360000); DWORD time1 = GetTickCount(); Sleep(500); if ((GetTickCount() - time1) < 450) Detected(); else return 0; }
仕組みはまずSleepで6分潜伏したあと2回GetTickCountを呼び出して，Sleepがちゃんと実行されているかを確認しているような感じ．
毎回6分も待つのは辛いので真面目に回避することにする．
やるべきはSleepの引数を1にして，2回のGetTickCountの戻り値の差を450以上にすること．
これらは以下のコードで実現できる．
// 関数Hook用の構造体を定義 typedef struct { uint32_t call_stack[2]; // return address and parameters ([0]: ret addr, [1]: time) DECAF_Handle hook_handle; } Sleep_hook_context_t; typedef struct { uint32_t call_stack[1]; // return address only -> VOID DECAF_Handle hook_handle; } GetTickCount_hook_context_t; // 構造体定義終わり /* * BOOL Sleep(DWORD dwMilliseconds); */ static void Sleep_ret(void *param) { // DECAF_printf("Sleep exit\n"); Sleep_hook_context_t *ctx = (Sleep_hook_context_t *)param; hookapi_remove_hook(ctx->hook_handle); free(ctx); } static void Sleep_call(void *opaque) { // DECAF_printf("Sleep entry\n"); Sleep_hook_context_t *ctx = (Sleep_hook_context_t*)malloc(sizeof(Sleep_hook_context_t)); if(!ctx) return; // bypass Sleep // Sleepの引数を ctx->call_stackに読み込み(call_stack[0]: ret addr, call_stack[1]: dwMilliseconds) DECAF_read_mem(NULL, cpu_single_env->regs[R_ESP], 2*4, ctx->call_stack); // 引数の書き換え．1ミリ秒だけ待機するようにした． ctx->call_stack[1] = 1; // call_stackをメモリに書き込む．これで変更が反映される． DECAF_write_mem(NULL, cpu_single_env->regs[R_ESP], 2*4, ctx->call_stack); ctx->hook_handle = hookapi_hook_return(ctx->call_stack[0], Sleep_ret, ctx, sizeof(*ctx)); } /* Sleep end */ /* * DWORD GetTickCount(VOID) */ static void GetTickCount_ret(void *param) { // GetTickCountは二回呼び出される．最初の呼び出しの時だけ戻り値を変更したい． // 静的変数 flag を使うことで実装した． static int flag = 0; // DECAF_printf("GetTickCount exit\n"); GetTickCount_hook_context_t *ctx = (GetTickCount_hook_context_t *)param; hookapi_remove_hook(ctx->hook_handle); // 最初の呼び出しでは戻り値は0，二回目は正しい値が返る． // 呼び出し間の差が450以上になれば良いので，最初(450), 2回目(900)とかやって遊ぶのも面白い．オーバフローには注意 if (!flag) { // ture is only first call cpu_single_env->regs[R_EAX] = 0; // return 0 flag = 1 } else { flag = 0; } // DECAF_printf("EIP = %08x, EAX = %d\n", cpu_single_env->eip, cpu_single_env->regs[R_EAX]); free(ctx); } static void GetTickCount_call(void *opaque) { // DECAF_printf("GetTickCount entry\n"); GetTickCount_hook_context_t *ctx = (GetTickCount_hook_context_t*)malloc(sizeof(GetTickCount_hook_context_t)); if(!ctx) return; DECAF_read_mem(NULL, cpu_single_env->regs[R_ESP], 4, ctx->call_stack); ctx->hook_handle = hookapi_hook_return(ctx->call_stack[0], GetTickCount_ret, ctx, sizeof(*ctx)); } /* GetTickCount end */ // 監視対象の関数を登録する．'[+]'の行を付け加えるだけ． static void red_loadmainmodule_callback(VMI_Callback_Params* params) { [+] sleep_handle = hookapi_hook_function_byname("kernel32.dll", "Sleep", 1, target_cr3, Sleep_call, NULL, 0); [+] gettickcount_handle = hookapi_hook_function_byname("kernel32.dll", "GetTickCount", 1, target_cr3, GetTickCount_call, NULL, 0); }
ctx->callstackには関数呼び出し時は[ret_addr, arg0, arg1, ...]となっていて，関数終了時にはret_addrなどは消える．
編集が終わったら，
$ pwd /home/<user>/DECAF/decaf/plugins/geteip $ make
(qemu) unload_plugins # 既にプラグインを挿入している場合 (qemu) load_plugin /home/<user>/DECAF/decaf/plugins/geteip/geteip.so (qemu) geteip blue.exe
ここまでやったあと，Windows上でblue.exeを動かしてみる．
Level2で検知されたらOK.
Level2: Charlie
コードは以下の通り．
static inline int Charlie() { printf("\n[Level 2] Charlie ..."); SYSTEM_INFO siSysInfo; GetSystemInfo(&siSysInfo); if (siSysInfo.dwNumberOfProcessors < 2) Detected(); else return 0; }
GetSystemInfo関数は引数の_SYSTEM_INFO構造体に各種値を入れる．構造体は9の変数を持っている．
typedef struct _SYSTEM_INFO { // sinf
call_stack[0]: union {
DWORD dwOemId;
struct {
WORD wProcessorArchitecture;
WORD wReserved;
};
};
call_stack[1]: DWORD dwPageSize;
call_stack[2]: LPVOID lpMinimumApplicationAddress;
call_stack[3]: LPVOID lpMaximumApplicationAddress;
call_stack[4]: DWORD dwActiveProcessorMask;
call_stack[5]: DWORD dwNumberOfProcessors; // プロセッサ数
call_stack[6]: DWORD dwProcessorType;
call_stack[7]: DWORD dwAllocationGranularity;
call_stack[8]_low: WORD wProcessorLevel;
call_stack[8]_high: WORD wProcessorRevision;
} SYSTEM_INFO;
_SYSTEM_INFO構造体は6番目の要素にdwNumberOfProcessorsというプロセッサ数を格納する変数があり，これが1だと仮想環境と判断し，停止する．
回避方法はシンプルで，こいつを2以上に書き換えてやれば良い．
実装は以下の通り．使う関数などはLevel1と同じ．
static DECAF_Handle getsysteminfo_handle = DECAF_NULL_HANDLE; typedef struct { uint32_t call_stack[10]; // return address and parameters DECAF_Handle hook_handle; } GetSystemInfo_hook_context_t; /* * VOID GetSystemInfo(LPSYSTEM_INFO lpSystemInfo); */ static void GetSystemInfo_ret(void *param) { // DECAF_printf("GetSystemInfo exit\n"); GetSystemInfo_hook_context_t *ctx = (GetSystemInfo_hook_context_t *)param; hookapi_remove_hook(ctx->hook_handle); // 構造体を読みだす． DECAF_read_mem(NULL, cpu_single_env->regs[R_ESP], 10*4, ctx->call_stack); // 変数の書き換え ctx->call_stack[5] = 0x2; // SYSTEM_INFO.dwNumberOfProcessors is 0x2 // 反映 DECAF_write_mem(NULL, cpu_single_env->regs[R_ESP], 10*4, ctx->call_stack); // write back to memory // DECAF_printf("EIP = %08x, EAX = %d\n", cpu_single_env->eip, cpu_single_env->regs[R_EAX]); } static void GetSystemInfo_call(void *opaque) { // DECAF_printf("GetSystemInfo entry\n"); GetSystemInfo_hook_context_t *ctx = (GetSystemInfo_hook_context_t*)malloc(sizeof(GetSystemInfo_hook_context_t)); if(!ctx) return; DECAF_read_mem(NULL, cpu_single_env->regs[R_ESP], 4, ctx->call_stack); ctx->hook_handle = hookapi_hook_return(ctx->call_stack[0], GetSystemInfo_ret, ctx, sizeof(*ctx)); } /* GetSystemInfo end */ static void red_loadmainmodule_callback(VMI_Callback_Params* params) { [+] getsysteminfo_handle = hookapi_hook_function_byname("kernel32.dll", "GetSystemInfo", 1, target_cr3, GetSystemInfo_call, NULL, 0); }
編集が終わったら，コンパイルする．
(qemu) unload_plugins # 既にプラグインを挿入している場合 (qemu) load_plugin /home/<user>/DECAF/decaf/plugins/geteip/geteip.so (qemu) geteip blue.exe
Level2が回避できたことを確認したらLevel3へ．
Level3: Delta
さて，ここまでは引数や戻り値をいじってやればよかったので，簡単だった．
Level3からはWinodwsについての知識が必要になってくるので複雑になってくる．
問題のコードは以下の通り．
static inline int Delta() { printf("\n[Level 3] Delta ..."); unsigned long NumberOfProcessors = 0; __asm { mov eax, fs:[0x30] mov eax, [eax + 0x64] mov NumberOfProcessors, eax } if (NumberOfProcessors & 0x1) Detected(); else return 0; }
やっていることはLevel2と同じくNumberOfProcessorsを確認している．
実はIsDebuggerPresentもGetSystemInfoもPEB(Process Environment Block)構造体というものの要素を参照する関数である．
だから問題としては関数がアセンブラになったと考えるとわかりやすいだろうか．
PEB構造体は各プロセスごとに作成される構造体で，ヒープやファイル，ロードしたDLLの内容などが入っている．
PEB構造体はTEB(Thread Environment Block)構造体という，スレッドごとに作成される構造体の先頭から0x30バイト先にその先頭アドレスが入っている．
絵で書くとこんな感じか
TEB構造体
| 0x0 |
| ... |
| ... |
| ... | PEB構造体
| 0x30(PEB) | -> | 0x0 |
| ... |
| ... |
| 0x64 | -> value of NumberOfProcessors
決してプラグインに上のアセンブラを混ぜ返してやればいいなんて考えないように．エミュレータ上のレジスタとプラグインに書いたレジスタは別物だと思う．やる人はあまりいないと思うが，やって時間を浪費したアホがここにいるので一応書いておく．
このトリックの対処としてはPEB構造体の値そのものを書き換えてやればよい．実装は以下の通り．
// bypass level3, 引数はデバッグ用 static void level3(int line_num) { uint32_t NumberOfProcessors = 0; uint32_t base = 0, peb_addr = 0, peb = 0; // TEB構造体のアドレスを取得．FSレジスタに格納されている base = cpu_single_env->segs[R_FS].base; // PEB構造体の入っているアドレスを計算 peb_addr = base + 0x30; // PEB構造体のアドレスを読み込む DECAF_read_mem(NULL, peb_addr, 4, &peb); // NumberOfProcessorsを読み込む DECAF_read_mem(NULL, peb+0x64, 4, &NumberOfProcessors); //DECAF_printf("FS(TEB): 0x%08x, peb_addr: 0x%08x, peb: 0x%08x\n", base, peb_addr, peb); // 変数を変更して反映 NumberOfProcessors = 0x2; DECAF_write_mem(NULL, peb+0x64, 4, &NumberOfProcessors); // write back to memory } // level3 end static void red_loadmainmodule_callback(VMI_Callback_Params* params) { [+] level3(__LINE__); // replace NumberOfProcessors }
コンパイルして回避できたことを確認したら終了．
PEBやらTEB構造体を初めて知ったが，奥が深い．
PEB構造体は探せば中身が出てくるが，実際はUndocumentedらしい．
Level4: Echo
最後の課題．
多分今できているプラグインを読み込ませて何回かblue.exeを実行するとLevel4が回避できる時と回避できない時があるはず．もしちゃんと検知してくれない時は何回か実行すると良い．
問題のコードは以下の通り．
static inline int Echo() { printf("\n[Level 4] Echo ..."); __try{__asm{cmpxchg8b fs:[0x1000]}} __except (1){Detected();} return 0; }
cmpxchg8b fs:[0x1000]は
if ([EDX:EAX] == fs:[0x1000]) fs:[0x1000] = [ECX:EBX]; else [EDX:EAX] = fs:[0x1000]; // [EDX:EAX]はEDXが上位32ビットでEAXが下位32ビットとする64ビット値
といった動作をする．この命令自体F00Fバグと呼ばれるバグの原因となった厄介な機械語らしい．
これがどうしてQemu検知できるかというと，read-onlyのページに書き込みした場合，本物のCPUならばPage Faultが起こる．Qemuの場合はPage Faultが起こらないらしい．どうやらQemuの実装上の欠陥をついた方法のようだ．ソースは
https://www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf
正直未だにこの検知の仕組みがよくわかっていない．整理できていない思考を書いておく．面倒な人は読み飛ばし推奨．真面目に読んだ人は意見が欲しい．
よくわからん！
- ソースの文章によると，メモリに書き込んでみて，Page Faultが起きなければ良いということなのだろう．しかし，Qemuだと例外が起こらないのだから，try文で検知できるのだろうか・・・?
[EDX:EAX]は特に書き換えられていない．つまり[EDX:EAX]はfs:[0x1000]と関係がないから，[EDX:EAX] = fs:[0x1000]の代入が起こるはず．これだとメモリがread-onlyだとかは関係がないんじゃなかろうか．- 加えて，このLevelは検知される時と検知されない時の原因はPEB構造体が
fs:[0x1000]に配置されるか否かであることがわかった．
条件としては
配置される : 検知されない
配置されない: 検知される
Olly DebugのQ&Aを見てみると，WindowsXPのSP1以前はfs:[0x1000]にPEB構造体が配置されることが約束されていたようだ．これがなにか関係があるのかとも思ったが，Qemu検知とは全く関係がない・・・はず．
Level4復帰
散々混乱した末に以下の結論に至った．
よくわからんが，PEB構造体は書き込み可である．fs:[0x1000]にPEB構造体が配置されていない時はread-onlyなのだろう(未検証・予想・適当)．
だから，fs:[0x1000]に格納されているアドレスを書き込み可能なアドレスにしてしまえばいいと考えた．
Windowsのプログラムで書き込み可能フラグが立っているアドレスの調べ方がわからなかったので，手っ取り早くスタックの先頭アドレス(ESP)に書き換えることにした．これでうまく行ってしまったので，これが答えの一つなのだろう．他にもっと冴えたやり方あるのかな．
cmpxchg8bが実行される時だけを検知して処理を行わないとプログラムがクラッシュする可能性がある．また，実行後はちゃんと元の値に戻さなければならない．
このあたりの検知は機械語を一つ実行するごとにHookしてcmpxchg8bかどうかを判定した．これにはDECAF_INSN_BEGIN_CBを使うことで実装することができる．
当然ながらこのやり方はとてつもなく重い．間違ってもこのHook中の処理にprintfとか挟んではいけない．やらかした奴が言うんだから間違いない．
説明が長くなったが，実装は以下の通り．
// level4 static uint32_t save_peb = 0; static uint32_t save_val[2] = {0, 0}; static uint32_t save_base = 0; static void red_insn_begin_callback(DECAF_Callback_Params* params) { // detect cmpxchg8b and replace fs:[0x1000] uint32_t cur_insn = 0, cmpxchg8b = 0x00c70f64, // opcode of 'cmpxchg8b: 0x640fc7 ->(fix endian) 0x00c70f64 base, peb_addr, tmp_addr; // 3Byte読み込んで，比較 DECAF_read_mem(NULL, cpu_single_env->eip, 3, &cur_insn); if (cur_insn == cmpxchg8b) { // catch cmpxchg8b base = cpu_single_env->segs[R_FS].base; DECAF_read_mem(NULL, base+0x30, 4, &save_peb); // get peb if (base > save_peb) { // peb is rear base DECAF_read_mem(NULL, cpu_single_env->regs[R_ESP], 8, save_val); /* DECAF_printf("FS(TEB): 0x%08x, peb: 0x%08x\n", base, save_peb); */ /* DECAF_printf("edx:eax %08x:%08x, ecx:ebx %08x:%08x\n", cpu_single_env->regs[R_EDX], cpu_single_env->regs[R_EAX], cpu_single_env->regs[R_ECX], cpu_single_env->regs[R_EBX]); */ save_base = base; cpu_single_env->segs[R_FS].base = cpu_single_env->regs[R_ESP]-0x1000; // fs = ESP - 0x1000 } } } static void red_insn_end_callback(DECAF_Callback_Params* params) { return; } // level4 end static void red_loadmainmodule_callback(VMI_Callback_Params* params) { [+] insnbegin_handle = DECAF_register_callback(DECAF_INSN_BEGIN_CB, &red_insn_begin_callback, NULL); // level4 [+] insnend_handle = DECAF_register_callback(DECAF_INSN_END_CB, &red_insn_end_callback, NULL); // level4 } static void red_cleanup(void) { [+] if (insnbegin_handle != DECAF_NULL_HANDLE) [+] { [+] DECAF_unregister_callback(DECAF_INSN_BEGIN_CB, insnbegin_handle); [+] insnbegin_handle = DECAF_NULL_HANDLE; [+] } [+] if (insnend_handle != DECAF_NULL_HANDLE) [+] { [+] DECAF_unregister_callback(DECAF_INSN_END_CB, insnend_handle); [+] insnend_handle = DECAF_NULL_HANDLE; [+] } }
上で偉そうなことを行ったが，実はこのコード，アドレスを書き換えたあと戻していなかったりする．戻さなくてもクラッシュしないプログラムだったので，面倒くさいからそのままにしておいた．良い子のみんなはちゃんと戻そう．
これで全てのトリックを回避できるはず．
回避するとフラグの文字列が出力される．洋書のタイトルのようだ．
最後に
説明したいことが多くて，必要以上に長くなってしまった．ここまで読み進めた人はお疲れ様でした.
全てのヒントはスライドの中に紛れ込んでいたりする．探してみるのもおもしろい．
スライドの情報のみだと説明が足りないので，DECAFの公式サイトやソースコードを読むのが一番役に立った．大規模なプログラムのソースを読み散らかすのは楽しい経験だったと思う．
マルウェアの仮想化回避はLevel2とLevel3のように同じやり方でも少し変えるだけで全く別のものになってしまう．いたちごっこな雰囲気を強く感じる演習だった．これはセキュリティベンダが苦労するわけだと思う．
セキュリティキャンプ全国ではこれを数時間でやらせることを考えると結構鬼畜。出たかったな・・・。
最後に、黒米さんと愛甲さん，楽しい時間をありがとうございました．
裏ワザ
- 仮想マシン起動時に
-smp 2,maxcpus=2をつけて割り当てるプロセッサを2つにするとLevel2,3は無条件でクリアできる．Level4は不安定だから場合によってはLevel1を回避しただけでフラグまでたどり着ける． - Level4とか面倒くさいから，該当するバイナリを
NOPに書き換えるのもあり?(未検証)
なんだこれ
QemuのありえないHz．CPUが溶けないなら欲しい性能．
参考
Win32 Thread Information Block - Wikipedia, the free encyclopedia
https://www.symantec.com/avcenter/reference/Virtual_Machine_Threats.pdf
セキュリティキャンプ講義「仮想化技術を用いたマルウェア解析」にチャレンジしてみた(準備編)
今年の八月中旬に行われたセキュリティキャンプ全国大会2015の解析トラック15・16-Dでの講義「仮想化技術を用いたマルウェア解析」にチャレンジして、一通りできた。
発表者の黒米さんの許可が戴けたのでその流れを書き残す。
発表で使われたスライドは黒米さんの技術ブログ"
一生あとで読んでろ
"に置いてある。
構成
プラグインを書くことよりも環境の準備に相当手間取ったので、準備編とプラグイン開発編の二段階で書いていく。
内容は以下の通り。
* 準備編
DECAFの導入と操作方法、注意点。
* プラグイン開発編
DECAF上で動かしているWindowsの仮想マシンで、仮想化検知を施されたプログラムblue.exeの検知を回避するプラグインを開発していく。
DECAFの準備
DECAFとは
DECAFは"Dynamic Executable Code Analysis Framework)の略で、QEMUにテイント解析機能を追加したTEMUの後継として作成されたバイナリ解析フレームワークのこと。詳しくはBitBlazeプロジェクトを検索。
インストール
インストールした環境は以下の通り。
* Ubuntu 14.04 LTS 64bit
他にはUbuntu 14.04 LTS 32bitとArch Linux 64bitでインストールを試みたが、コンパイルが上手くいかず断念した。
まず、適当なディレクトリに移動してから以下のコマンドを実行していく。
$ sudo apt-get update $ git clone https://github.com/sycurelab/DECAF $ cd DECAF/decaf $ pwd /home/<user>/DECAF/decaf $ sudo apt-get install qemu $ sudo apt-get install build-dep qemu $ sudo apt-get install binutils-dev $ sudo apt-get install libboost-all-dev $ ./configure # スライドの方にはテイント解析などをオンにするオプションが載っているが、今回はなくても問題なかった。 $ make
もしもpython関係のエラーが出たら、コマンドのpythonが3系にリンクが張られていないかを確認すること。DECAFのスクリプトは2系で書かれていて、例外処理関係でエラーが出る。
具体的にはconfig-host.makのPYTHON=pythonをPYTHON=python2.7とかに書き換える。
これ以外のエラーが出たら・・・頑張れ！
DECAF自体のインストールはmakeが上手くいけばおしまい。
次はWindowsの仮想マシンを用意する。
仮想マシンの準備
Developer Resources : Microsoft Edge Devで30日だけ動作するWindowsの仮想マシンを配布しているので、ダウンロードする。
トップページ下にある"Virtual Machine"をクリック。
Windowsタブで
* Virtual Machine => IE8 on XP
* Select Platform => VMWare
と設定し、"Download .zip"からダウンロード。
$ pwd /home/<user>/DECAF/decaf $ mkdir ../VMs $ mv $HOME/Downloads/IE8.XP.For.Windows.VMware.zip $HOME/DECAF/VMs $ cd ../VMs $ unzip IE8.XP.For.Windows.VMware.zip
VMWare用の仮想マシンからqemu用の仮想マシンを作成する．
作成には少々時間がかかる．容量も7GBほど食われた覚えがあるから注意．
$ qemu-img convert <name of VM>.vmdk -O qcow2 pre_ie8.qcow2 $ qemu-img convert -p -f qcow2 -O qcow2 -o compat=0.10 pre_ie8.qcow2 ie8.qcow2
qcowに変換しても動作するが，スナップショットが使えない．
作成が終わったら，下のコマンドで起動してみる．
$ $HOME/DECAF/decaf/i386-softmmu/qemu-system-i386 $HOME/DECAF/decaf/VMs/ie8.qcow2 -m 2048 -monitor stdio
これでWindowsXPが立ち上がることを確認する。-mオプションは割り当てるメモリの量を指定する．1GBでは動作が遅い。
また，今回は1つしかプロセッサを与えていないため，しばらくは処理が重いが時間を置くと落ち着く．
画面が引き延ばされるのを修正したいならCtrl+Alt+uを押す。
マウスが暴走するようなら
$ export SDL_VIDEO_X11_DGAMOUSE=0
Windowsが立ち上がることを確認したらシャットダウンする。
次に問題のプログラムをWindnowsにコピーする。
$ git clone https://github.com/ntddk/blue.git $ sudo modprobe nbd $ sudo qemu-nbd -c /dev/nbd0 ie8.qcow2 $ sudo /sbin/fdisk -l /dev/nbd0 $ sudo mount -o loop,offset=$((63*512)) /dev/nbd0 /mnt $ sudo cp -r blue /mnt/Documents and Settings/All Users/Desktop $ sudo umount /mnt $ sudo qemu-nbd -d /dev/nbd0 $ sudo rmmod nbd
これで起動したときのデスクトップにblueのフォルダが出るようになる。
また，プラグインもコンパイルしておく．
$ pwd /home/<user>/DECAF/VMs $ cd ../decaf/plugins $ git clone https://github.com/ntddk/geteip $ cd geteip $ ./configure --decaf-path=/home/<user>/DECAF/decaf $ make
このプラグインはIsDebuggerPresentをフックする．関数フックのテンプレートとして勉強になる．
今後の起動はDECAFの公式HPやスライドに載っている自動化スクリプトを使ってもできる．
下のスクリプトも同じ動作をするのでHaskell好きな人はどうぞ．
-- decaf_auto.hs import System.IO import System.Process -- createProcess import System.Posix.Directory -- changeWorkingDirectory import Control.Concurrent (forkIO, threadDelay) inputCmd p_in p_out cmd = do hPutStrLn p_in cmd threadDelay (1000 * 1000) -- Nonblocking forkIO $ putStrLn =<< hGetContents p_out rawInput msg = do putStr msg getLine main :: IO () main = do hSetBuffering stdout NoBuffering decaf_path <- rawInput "*** Enter the root directory of DECAF (i386-softmmu/qemu-system-i386 should be there): " image_path <- rawInput "*** Enter the image path: " changeWorkingDirectory decaf_path (Just p_stdin, Just p_stdout, _, _) <- createProcess (shell $ "i386-softmmu/qemu-system-i386 " ++ image_path ++ " -m 2048 -monitor stdio") { std_in = CreatePipe, std_out = CreatePipe } hSetBuffering p_stdin NoBuffering hSetBuffering p_stdout NoBuffering threadDelay (3 * 1000 * 1000) inputCmd p_stdin p_stdout "ps" inputCmd p_stdin p_stdout "help" return () -- E.O.F.
やっていることはqemu-system-i386のプロセスを作成し，そのプロセスの標準入力・標準出力に対しての操作を行っている．
しかしこのスクリプト(Python版も含めて)は使わないほうがいいと感じた．
これは実行すると書いてある動作以外をせず，qemuのプロンプトが出ないで入力・出力が閉じてしまう．
使うなら下のコマンドで普通に実行したほうがいい．
$ pwd /home/<user>/DECAF/VMs $ ../decaf/i386-softmmu/qemu-system-i386 ie8.qcow2 -m 2048 -monitor stdio
出力が一段落ついたあたりで一回Enterを押すと，(qemu)のプロンプトが出る．
プロンプトを表示させてプラグインを読みこませる．
(qemu) load_plugin ../decaf/plugins/geteip/geteip.so (qemu) geteip blue.exe
これでblue.exeを実行した時にgeteip.cの内容が実行される．blue.exeはblue/Release/blue.exeにある．
何もいじっていなければIsDebuggerPresentの実行時と実行後にそれぞれフックしたメッセージが出るだけのはず．
この辺はどうにも不安定で，いじっていなくてもIsDebuggerPresentを回避できたりした．
詳しいことはプラグイン開発編で書く．
最後に
ここまでがうまく行けば，準備は終わり．
誤字やうまく行かないところがあれば気軽に言ってくれると嬉しい．
ここまで長い記事を書いたことがないので，どこか間違いがありそうな気がする．
次は，blue.exeのソースを参考にプラグインを書いていく．
アセンブリ言語をコンパイル・実行してみる
GASとNASMで64bitプログラミングの基本をやってみた。
実行するのは基本中の基本である"hello, world"を出力するだけのプログラム。
環境
- gcc: version 5.2.0 (GCC)
- nasm: NASM version 2.11.08 compiled on Mar 24 2015
- Arch Linux x86_64: 4.2.5-1-ARCH
64bitアセンブラ基本
64bitのアセンブラにおいてはレジスタは以下のように使われる。
rax: システムコール番号
rdi: 第一引数
rsi: 第二引数
rdx: 第三引数
システムコール番号は/usr/include/asm/unistd_64.hに書いてある。
これを今回のwriteの場合に当てはめると
rax: 0x10 (write)
rdi: 1 (stdout)
rsi: pointer of strings ("hello, world!!!")
rdx: 16 (文字列長)
GAS
GASはGNU ASのことであり、GCCでコンパイルすることができる。デフォルトではAT&T記法なので今回はIntel記法に変更してからプログラミングする。 ソースは以下の通り。
/* hello.s 64bit */ .intel_syntax noprefix .globl _start _start: // write(1, "hello, world!!!\n", 16) xor rax, rax xor rdi, rdi xor rdx, rdx inc rax inc rdi mov rsi, 0x0a212121646c726f push rsi mov rsi, 0x77202c6f6c6c6568 push rsi mov rsi, rsp push 0x10 pop rdx syscall // exit(1) push 0x3c pop rax syscall
$ gcc -nostdlib hello.s -o hello_gas $ ./hello_gas hello, world!!!
NASM
NASMはNetwide Assemblerの略であり、nasmというコンパイラを使ってコンパイルする。
NASM自体は公式サイトからダウンロードするか各ディストリのレポジトリからインストールできる。Arch Linuxでは
$ pacman -S nasm
でインストールできる。
; hello.asm 64bit section .text global _start _start: xor rax, rax xor rdi, rdi xor rdx, rdx inc rax ; write inc rdi ; stdout mov rsi, 0x0a212121646c726f push rsi mov rsi, 0x77202c6f6c6c6568 push rsi mov rsi, rsp push 0x10 pop rdx syscall ; exit(1) push 0x3c pop rax syscall
$ nasm -f elf64 hello.asm && ld hello.o -o hello_nasm $ ./hello_nasm` hello, world!!!
両方ともこんな風にコンパイルされている。
xor rax, rax xor rdi, rdi xor rdx, rdx inc rax inc rdi movabs rsi, 0x0a212121646c726f push rsi movabs rsi, 0x77202c6f6c6c6568 push rsi push rsi mov rsi, rsp push 0x10 pop rdx syscall push 0x3c pop rax syscall
プログラムは一応NULLバイトをなくしてある。
syscallをsysenterと書いてデバッグしたのはいい思い出である。64bitではint 0x80とsysenterはサポートされていないようだ。
それぞれコメントアウトの仕方が違うのでそこは注意が必要である。
比較
GASの方はコメントの仕方がCライクであったり、pushの時に自動でBYTE変換してくれる、GCCで使えるなど、芸が細かい。
NASMの方はオブジェクトファイルが作りやすいから、CTFとかで使いやすい。
どちらを使うかは好みの問題だと思う。
LightDMの壁紙が変わらないときの対処
Arch Linuxをインストールする際に最初はDM(デスクトップマネージャ)にGDMを使っていたが、認証成功時に一瞬CUIっぽいのが出ていた。これが微妙だったからUbuntuやOpenSUSEで利用されている軽量DMのLightDMに変えた。
このとき認証画面の背景を変更するのに割と手間取ったためメモを残しておく。
環境
問題
ArchWikiには背景を変えたいときは/etc/lightdm/lightdm-gtk-greeter.confのbackgroundを編集すればよいと書いてある。
具体的には、
・単色にしたいとき
background=#000000
・画像を使いたいとき
background=/usr/share/pixmaps/<wallpaper>.jpg user-background = true
これではうまくいかなかった。調べてみると、OpenSUSEのフォーラムに答えがあった。
対処
画像があるディレクトリをroot所有にして、画像自体はパーミッションを644にすると上手くいった。
$ chown root <pict_dir>
$ chown root <wallpaper>.jpg
$ chmod 644 <wallpaper>.jpg
やっていること自体は画像を置くことが推奨されている/usr/share/pixmapsに近づけているだけだったりする。要はこれに合わせるか、このディレクトリに入れろってことのようだ。
もしこれでうまくいかないときはlightdm-gtk-greeter-settingsを使うと良い。
GUI画面で異常が起こっているかどうかを確認しながら作業することができる。
これは
$ pacman -S lightdm-gtk-greeter-settings
でインストールできる。
起動したら、Backgroundの右にあるmultihead setupを選び、そこでディスプレイと画像を指定する。
異常がある場合黄色い三角が出てくる。
参考
Ubuntuで認証画面を無限ループさせる方法と対処
最近DM(デスクトップマネージャー)やWM(ウィンドウマネージャー)をいじっていると、ある時突然認証画面でパスワードを入力してもすぐにまた認証画面が出る無限ループに陥った。割と楽しい現象だったので引き起こし方と対処を書き残す。
確認した環境
無限ループを正常に引き起こせたOSは以下の通り(これしか試していない)
・Ubuntu14.04 LTS 32/64bit
・LightDM・GNOMEを入れたArch Linux 64bit
無限ループの呪文
$ sudo startx && sudo reboot
以上。
パスワードの長い認証を抜けると、認証であった。
30回ほどパスしたが、終わらなかった。
対処
まずはシェルを起動する。
簡単な方法としては以下のものがある。
・sudoが使える別ユーザでログイン
・Ctrl+Alt+F1とかを押してCUIでログイン
sudoを使えるユーザでログインすることが重要。そして以下のファイルを削除する。
.ICEauthority : 複数のXクライアント同士で直接通信するときの認証に使われる。内部にランダムなCookieを保有していて、これが同じXクライアント同士が通信できる。 .Xauthority : Xサーバの認証に使うファイル。詳しくはxauthで調べる。
.ICEauthorityと.Xauthorityは同じように見えるが、前者はClient to Client, 後者はClient to Serverであることが大きな違い。
これで再起動すれば正常に動くようになる。消したファイルは再度作成される。
原因
認証ファイルを消したらうまくいったってことは、Xサーバの認証の失敗ってことでいいんだろうか。
GDMとLightDMの.Xauthorityファイルの使い方についてもっと詳しく調べたほうがよさそうだ。
正直全くわかっていない。わかったら追記する。
考察
実はもう一つの対処として、ArchのDMをGDMに変更しするというものもある。
これをした場合、sudo startxが自体が成功しなくなった。そして、認証もループが起こらなくなった(無限ループが起こっている状態で隠しファイルを消さずにDMを変更した。このままLightDMに戻すとまたループ)。
UbuntuはDMにLightDMを用いていることから考えると、今回のこの無限ループはLightDMに起因するものなのだろうか。
もしくは、LightDM内で使われているであろうxauthが原因である可能性が高いのではないかと思う。
どちらにせよ、UbuntuやDebianベースのXubuntuやLubunt、Kali Linuxのようなファミリーはすべて今回の現象が起こる可能性がある。実際に試してはいないので何とも言えないが。
もし試し方がいたら環境と結果を教えて頂けると非常にありがたい。
これの根本的な原因を追究できるようになりたい・・・。
参考
Ubuntu Xサーバー その3 - ログインしてもログイン画面に戻される時は - Ubuntu kledgeb
open - what is .ICEAuthority file in opensuse 11.2 - Server Fault
見たことあるCコーディングミス
知り合いが実際に書いて悩んでいたCコードを2種類書き残す。
その1
...
int i=0,
count[i];
...(snip)...
一見してやばいのはわかるはず。要素数0の配列を宣言していた。その場ではただひどいコードだとだけ思ったが、あとから気になってちょっと実験してみた。
実験コード
/* zero_array.c */
#include <stdio.h>
int main(void)
{
int a = 0,
b = 0,
c[a];
printf("a: %p\nb: %p\nc: %p\n", &a, &b, c);
}
/* E.O.F. */
実行結果
実行したところ、
a: 0xbf877850 b: 0xbf877854 c: 0xbf877840
となった。変数a, bは正しくスタックに積まれているようだ。cは確保されているのかどうかとても怪しいところ。領域は確保されていないがアクセスできるポインタみたいな印象であるが、詳細は不明。わかったら追記する。
当たり前ではあるが、上のソースでc[4]に任意の値を書くとaを書き換えることができる。ただのセキュリティホールにしか見えない。
2015/10/31追記
turn_upさんから指摘があった。要素数0の配列は構造体で
struct hoge {
int i;
int a[0];
}
とするとaはiの次のアドレスを指すようになる。上手く使うと便利なようだが、マイナーな上にGCC拡張だから、依存性が強い。C++では配列は1個以上の要素を持たないといけないで要素数0の宣言はできない。
その2 (考察間違い。追記要参照)
これも知り合いが書いてしまったコード。詳しく覚えていないが、こんな雰囲気だった。
while (1) {
if (hoge = 32) break;
else ...(snip)...
if文の条件で代入を行うとTrue扱いになってすぐループを抜けてしまっていた。
気になったのでいじっていたら、代入が失敗する場合を1種類だけ見つけた。
それは以下の場合である。
int/char a;
if (a = 0.11) printf("True\n");
else printf("False\n");
intやcharの変数に小数を代入しようとすると失敗するようだ。
2015/10/31追記
turn_upさんから指摘があって、改めて考えてみた。
冷静に考えてみると、分岐命令の中身は
if (i = 0) -> if (i) -> if (0)
の流れでFalseになっているんじゃないかと思って、アセンブラを見てみたら案の定
mov DWORD PTR [esp+0x1c], 0x0 cmp DWORD PTR [esp+0x1c], 0x0 je 0x80......
となっていた。だから、変数に0を代入した場合はすべてFalseになる。これはint/char/float/doubleの時で確認できた。
細かいことではあるが、先ほどのコードのようなシンプルな分岐では、iに0以外を代入したときは実行ファイルにcmpはなかった。自明すぎてコンパイラに消されてしまったようだ。-O0をつけても同じだった。
どこかで聞いたのは、分岐条件の記述は変数を後に書いたら良いとのことだった。
例えばif (NULL == ptr)やif (32 == hoge)のようにである。これならば間違えてしまったときはコンパイルエラーが出てすぐに気付くことができる。
参考ページ
GHCでコンパイルしたバイナリを小さくする方法
概要
HaskellはGHCでコンパイルしてバイナリを生成することができる。しかし、Cの時と比べて意味不明なレベルでバイナリが大きくなる。原因と対策を書いておく。
環境
- OS
$ uname -a Linux ubuntu 3.13.0-63-generic #103-Ubuntu i686
$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3
$ gcc --version gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 ...
ソース
-- hello.hs main = putStrLn "Hello, World!" -- E.O.F.
/* hello.c */
#include <stdio.h>
int main(void)
{
printf("Hello, World!\n");
return 0;
}
/* E.O.F. */
どちらも "Hello, World!"と出力するだけの簡単なプログラム。
コンパイル
サイズ
$ ll ?_hello 7332 c_hello 839047 h_hello
HaskellはCの100倍以上の大きさを持っている。
最初見たときは叫んだ。
原因
GHCはデフォルトでHaskell runtime(libHSrts.a)を静的リンクするようだ。
こいつが丸々バイナリに組み込まれてしまうのが問題みたいだった。
GCCは最初から動的リンクするイケメン。
対策
動的リンクに切り替えてやればよい。
UbuntuのHaskell platformには動的リンクが含まれていない。
だから最初に ghc-dynamic をインストールする。
$ apt-get install ghc-dynamic
それから以下を実行。
$ ghc -dynamic -o h_hello hello.hs` $ ll ?_hello 7332 c_hello 16397 h_hello
2倍程度まで小さくなった。 デバッグ情報を消去するともう少し小さくなる。参考までにデバッグ情報をなくしたCバイナリ(sc_hello)も載せておく。
$ strip -p --strip-unneeded --remove-section=.comment -o sh_hello h_hello $ ll *_hello 7332 c_hello 16397 h_hello 5448 sc_hello 9688 sh_hello
c_helloのほぼ同程度のサイズまで落とせた。
結論
Haskellのバイナリはリンクさえどうにかすればサイズは2倍程度にできることがわかった。
おまけ
このままCバイナリに負けたままでは悔しかったからもう少し頑張ってみた。
実行形式ファイルを実行可能な圧縮ファイルに変換するgzexeというコマンドがある。これは実行ファイルをgzipで圧縮し、圧縮したファイルの先頭に解凍するスクリプトを埋め込む。容量の小さいディスクにおいて有効なコマンドである。
$ gzexe h_hello h_hello: 74.2% $ ll *_hello 7332 c_hello 5061 h_hello <- 圧縮後 16397 h_hello~ <- 圧縮前
・・・ついにHaskellバイナリはCバイナリを越えた！
$ gzexe c_hello c_hello 68.7% $ ll *_hello 3132 c_hello <- 圧縮後 7332 c_hello~ 5061 h_hello <- 圧縮後 16397 h_hello~
という夢を見た。おしまい。
メモ
最初にPreludeの関数をputStrLn以外をhidingしてみたが、サイズ面では全く変化がなかった。
関数のロード関連はサイズに関係しないフラグなどがあるのだろうか。
参考リンク
haskell - Could not find module Prelude... dyn libraries for package base? - Stack Overflow
