ハードウェアによる仮想化支援機能を利用したハイパーバイザーIPS
Fourteenforty Research Institute, Inc.
株式会社 フォティーンフォティ技術研究所
http://www.fourteenforty.jp

シニアリサーチエンジニア
村上 純一

Fourteenforty Research Institute, Inc.

はじめに(1/2)• 近年、ルートキット技術の利用によりマルウェアのステルス化が進んでいる• 従来のAVプロダクトによる検出が困難• 3rd Partyによる「検出ツール」‒ GMER‒ Rootkit Revealer(Microsoft)‒ Rootkit Buster(TrendMicro)‒ McAfee Rootkit Detective2

Fourteenforty Research Institute, Inc.

はじめに(1/2)• 近年、ルートキット技術の利用によりマルウェアのステルス化が進んでいる• 従来のAVプロダクトによる検出が困難• 3rd Partyによる「検出ツール」‒ GMER‒ Rootkit Revealer(Microsoft)‒ Rootkit Buster(TrendMicro)‒ McAfee Rootkit Detective‒ Windbg 3

Fourteenforty Research Institute, Inc.

はじめに(2/2)• 仮想化技術を利用したIPSを開発‒ OSより低い「リング-1」相当の権限で動作• ルートキットの「検知」と「防止」を実現‒ 不正なメモリパッチングを検知・防止‒ （ゲスト）OSの活動をモニタリング

4Fourteenforty Research Institute, Inc.

アウトライン•

既存のルートキット技術•

仮想化技術の概要•

Viton, ハイパーバイザーIPS

5

Fourteenforty Research Institute, Inc.

int packet̲analysis(GDDCONFIG *gddc,unsigned char *packet,unsigned long length){
struct ip*ip̲header;/* IP header */struct tcphdr *tcp̲header;/* TCP header */char*tcp̲data;/* TCP data */struct in̲addr addr;/* IP address */charsourceIP[16]; /* Source IP address */char
destIP[16];/* Destination IP address */unsigned short sourcePort;/* Source Port */unsigned short destPort;/* Destination Port */unsigned long len̲data;/* Length of data part */unsigned long iph̲len;/* Length of IP header */unsigned long tcph̲len;/* Length of TCP header */unsigned long sequence;/* Expected sequence */int
portindex;/* Indexnumber of port list */int
direction;/* Packet direction */unsigned char logtype;/* Log type */CONN̲LIST*bcl,*ncl;/* Connection table list */CONN̲LIST*t;/* Temporary connection list */static chardatestr[512]; /* Buffer to store datetime */time̲ttimeval;struct tm*timep=NULL;
char*timesp=NULL;
char
*c;

Chapter 1

既存のルートキット技術/* Get pointer of IP header and check length of IP */if (length-SIZE̲OF̲ETHHDR < MINSIZE̲IP+MINSIZE̲TCP) return(0);ip̲header = (struct ip *)(packet+SIZE̲OF̲ETHHDR);
if (ip̲header->ip̲p!=IPPROTO̲TCP¦¦ ip̲header->ip̲v!=4) return(0);iph̲len= ((unsigned long)(ip̲header->ip̲hl))*4;
if (iph̲len<MINSIZE̲IP) return(0);if ((unsigned long)ntohs(ip̲header->ip̲len) < MINSIZE̲IP+MINSIZE̲TCP)
return(0);if ((unsigned long)ntohs(ip̲header->ip̲len) > length-SIZE̲OF̲ETHHDR){
return(0);}/* Get pointer of TCP header and check length of TCP */tcp̲header = (struct tcphdr *)((char *)ip̲header+iph̲len);tcph̲len= ((unsigned long)(tcp̲header->th̲off))*4;
tcp̲data= (char *)tcp̲header+tcph̲len;
if (tcph̲len<MINSIZE̲TCP) return(0);/* Get other parameter in TCP/IP header */if ((long)ntohs(ip̲header->ip̲len)-(long)iph̲len-(long)tcph̲len<0)
return(0);len̲data= (unsigned long)ntohs(ip̲header->ip̲len)-iph̲len-tcph̲len;sourcePort = ntohs(tcp̲header->th̲sport);
destPort= ntohs(tcp̲header->th̲dport);
memcpy(&addr,&(ip̲header->ip̲src),sizeof(struct in̲addr));strcpy(sourceIP,(char *)inet̲ntoa(addr));
memcpy(&addr,&(ip̲header->ip̲dst),sizeof(struct in̲addr));strcpy(destIP,(char *)inet̲ntoa(addr));if (!strcmp(sourceIP,destIP)) return(0);00001B70 FF 15 F0 11 00 01 E9 CC 03 00 00 E8 7C 1C 00 00
00001B80 33 F6 56 E8 B1 FC FF FF 85 C0 0F 84 B7 03 00 00
00001B90 56 6A 02 FF 35 6C 80 00 01 FF 35 D0 87 00 01 FF
00001BA0 15 CC 11 00 01 85 C0 75 1D 68 10 10 00 00 FF 35
00001BB0 50 80 00 01 FF 35 44 80 00 01 FF 35 D0 87 00 01
00001BC0 FF 15 04 12 00 01 FF 35 D0 87 00 01 FF 15 2C 1200001BD0 00 01 FF 35 D4 8B 00 01 FF 15 58 10 00 01 E9 6400001BE0 03 00 00 83 FE 1A 77 47 0F 84 59 03 00 00 83 FE
00001BF0 11 0F 85 16 01 00 00 33 F6 39 35 E8 87 00 01 74
00001C00 22 8B 3D 28 12 00 01 56 FF D7 56 FF D7 68 00 10
00001C10 00 00 FF 35 50 80 00 01 FF 35 88 80 00 01 E9 7D00001C20 02 00 00 6A 01 E8 0F FC FF FF E9 1A 03 00 00 8B
00001C30 7D 14 B8 11 01 00 00 3B F0 0F 87 8B 00 00 00 3B
00001C40 F0 0F 84 16 02 00 00 83 FE 1C 0F 85 BD 00 00 00
00001C50 33 F6 39 75 10 74 2F A1 EC 87 00 01 8B 0D F0 87
00001C60 00 01 3B C6 75 08 3B CE 0F 84 D9 02 00 00 8B 3D00001C70 14 12 00 01 51 50 68 B1 00 00 00 FF 35 D4 87 00
00001C80 01 E9 56 01 00 00 8B 3D 14 12 00 01 68 F0 87 00
00001C90 01 68 EC 87 00 01 68 B0 00 00 00 FF 35 D4 87 00
00001CA0 01 FF D7 A1 EC 87 00 01 8B 0D F0 87 00 01 3B C100001CB0 75 11 89 35 EC 87 00 01 89 35 F0 87 00 01 E9 8400001CC0 02 00 00 51 50 E9 07 01 00 00 8B CE B8 12 01 00
00001CD0 00 2B C8 0F 84 3C 02 00 00 83 E9 04 0F 84 29 02
00001CE0 00 00 49 0F 84 F9 01 00 00 81 E9 1C 01 00 00 0F
00001CF0 84 E0 01 00 00 81 E9 E6 00 00 00 0F 84 3D 01 00
00001D00 00 81 E9 E8 7C 00 00 0F 84 02 01 00 00 3B 35 5C
00001D10 88 00 01 0F 85 EE 00 00 00 8B 45 14 8B 48 0C 8B
00001D20 C1 8B D1 F7 D0 C1 EA 02 83 E0 01 83 E2 01 F6 C1......鯲...閖...
3
雎...・.┨...
Vj..5l....5ﾐ....
.ﾌ...・u.h.....5
P....5D....5ﾐ...
.......5ﾐ.....,.
...5ﾔ.....X...馘
......wG.Ш.....
.......3.95閾..t".=(...V.ﾗV.ﾗh..
...5P....5・..驀
...j...........急.ｸ....;..㈲...;...........・...
3.9u.t/｡・....
..;ﾆu.;ﾎ.・....=....QPhｱ....5ﾔ..
.餬....=....h.
.h・..hｰ....5ﾔ..
..ﾗ｡・......;ﾁ
u..5・...5..驗...QP.....勤ｸ...
.+ﾈ..<...・...).
..I.・...・.....
・...・......=..
.・閖........;5\....・...畿.稀.驚錦
ﾁ..・.・.

6

Fourteenforty Research Institute, Inc.

ルートキット技術の分類
ステルスマルウェア
ユーザーの同意なしに、システム・OSの挙動を変更し、情報の隠ぺいを行うソフトウェア（マルウェア）※Joanna Rukowska、"Introducing Stealth Malware Taxnomy"
http://invisiblethings.org/papers/malware-taxonomy.pdf

ステルスマルウェアがパッチングを行うリソースの性質に基づいてType 0からType IIIの4種類に分類

7

Fourteenforty Research Institute, Inc.

Type 0 (≠ステルスマルウェア)

プロセス

コード領域

データ領域

OS

コード領域

データ領域

ハードウェアType 0

システムレジスタ

8Fourteenforty Research Institute, Inc.

Type 0 (≠ステルスマルウェア)

9Fourteenforty Research Institute, Inc.

Type 0 (≠ステルスマルウェア)

exp1orer.exe

10Fourteenforty Research Institute, Inc.

Type I

プロセス

コード領域

データ領域

OS

コード領域

データ領域

ハードウェアType I

システムレジスタ

11Fourteenforty Research Institute, Inc.

Type I - Windowsにおけるフッキングポイント(1/3)

・・・MSR[176h]
IDTR
KiSystemService

SDT(ntoskrnl.exe)

Nt* APIsSSDT

Nt* APIs(User/GDI)

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

SSDT

12

Fourteenforty Research Institute, Inc.

Type I - Windowsにおけるフッキングポイント(2/3)
システムレジスタの値を改竄
・・・MSR[176h]
IDTR
KiSystemService

SDT(ntoskrnl.exe)

Nt* APIsSSDT

Nt* APIs(User/GDI)

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

SSDT

13

Fourteenforty Research Institute, Inc.

Type I - Windowsにおけるフッキングポイント(3/3)
静的な関数ポインタ、
アドレステーブルを改竄

・・・

MSR[176h]
IDTR
KiSystemService

SDT(ntoskrnl.exe)

Nt* APIsSSDT

Nt* APIs(User/GDI)

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

SSDT

14

Fourteenforty Research Institute, Inc.

Type I関数のコード領域にjmp命令を挿入
・・・

MSR[176h]
IDTR
KiSystemService

SDT(ntoskrnl.exe)

Nt* APIsSSDT

Nt* APIs(User/GDI)

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

SSDT

15

Fourteenforty Research Institute, Inc.

Type Iとその対策• 検出は容易• 多くの検出ツール、対策が存在する‒ 3rd partyの検出ツール‒ PatchGuard (Vista x64 Edition)

16

Fourteenforty Research Institute, Inc.

Type II

プロセス

コード領域

データ領域

OS

コード領域

データ領域

ハードウェアType II

システムレジスタ

17Fourteenforty Research Institute, Inc.

Type II• データ領域に含まれるデータを改ざん• DKOM（Direct Kernel Object Manipulation）
Jamie Butler, http://www.blackhat.com/presentations/win-usa-04/bhwin-04-butler.pdf• KOH（Kernel Object Hooking）
Greg Hoglund, http://www.rootkit.com/newsread.php?newsid=501

18

Fourteenforty Research Institute, Inc.

DKOM（Direct Kernel Object Manipulation）• データ領域に含まれるプロセスリスト、プロセストークン等のデータを改竄

OS

プロセスリストを取得する処理コード領域

Type II

データ領域

19

Fourteenforty Research Institute, Inc.

DKOM（Direct Kernel Object Manipulation）• データ領域に含まれるプロセスリスト、プロセストークン等のデータを改竄

OS

プロセスリストを取得する処理コード領域

Type II

データ領域

20

Fourteenforty Research Institute, Inc.

DKOM（Direct Kernel Object Manipulation）• 限定的な機能しか実装することができない‒ 実現可能な機能は、対象のデータを取り扱う処理の実装に依存する• プロセスエントリをプロセスリストから除外すると、‒ スケジューリングされない（実行されない）？
‒ スレッドベースのスケジューリング
‒ スケジューラの実装に依存

21

Fourteenforty Research Institute, Inc.

KOH(Kernel Object Hooking)• データ領域に含まれる関数ポインタを改竄• カーネル内には、IDT、SDT、SSDT以外にも無数の関数ポインタが存在する• KOHによるフッキングを検出するためには、カーネル空間に存在する全ての関数ポインタを把握する必要がある→ ルートキット開発側と検出側のイタチごっこ

22Fourteenforty Research Institute, Inc.

Type III

プロセス

コード領域

データ領域

OS

コード領域

データ領域

Type III

ハードウェアシステムレジスタ

Type III23

Fourteenforty Research Institute, Inc.

Type III(1/2)• システム（OS）の外部で動作する‒ 仮想化技術の悪用‒ ファームウェアルートキットやSMMルートキット• BluePill‒ ハードウェアの仮想化支援機能を悪用し、悪意のハイパーバイザーを
インストール‒ （ゲスト）OSのリソースは改ざんしない‒ 最新のBPは、Intel VTおよびAMD-vの両方をサポート

Joanna Rutkowska, Alexander Tereshkin, http://bluepillproject.org

24Fourteenforty Research Institute, Inc.

Type III(2/2)• Vitriol‒ Intel VTを悪用するType IIIルートキット
Dino Dai Zovi, Black Hat USA 2006

• VMM Rootkit Framework‒ Vitriol同様、Intel VTを悪用するType IIIルートキット‒ コンセプトコードのため非常にプリミティブな実装→VMMの動作、実装を学ぶために最適
Shawn Embleton,
http://www.rootkit.com/newsread.php?newsid=75825Fourteenforty Research Institute, Inc.

ケーススタディ: Storm Worm
• 2007年に出回り始めたP2Pボット• スパムメールに自身の実行ファイルを添付して送信• スパムメールのサブジェクトに実際に発生した事件を利用‒ "230 dead as storm batters Europe"‒ "Happy New Year 2008"‒ etc.

• 一部の亜種は、AV製品から逃れるためにルートキット機能を
備えている
26

Fourteenforty Research Institute, Inc.

Storm Worm - "Happy New Year 2008"
実行ファイル実行すると、
1. システムファイルを生成、カーネルにロード
2. ドライバによる悪意の動作••

ルートキット機能
SSDT、IRPフッキングを利用したファイル、レジストリ、接続情報の隠ぺい
コードインジェクション機能
悪意のコード（本体部分）をユーザーモードプロセスに注入

3. P2P通信を開始
27

Fourteenforty Research Institute, Inc.

ルートキット機能•••

以下の3つのNative APIをフック（SSDTフッキング）‒ NtQueryDirectoryFile, NtEnumerateKey, NtEnumerateValueKey
APIのSSDTにおけるインデックス番号は、NtBuildNumberによって異なる
2195(2k), 2600(XP) and 3790(2k3)の3つをサポート

IndexNumberTableOf
NtQueryDirectoryFile
NtQueryDirectoryFile

NtBuildNumber == 2600
NtBuildNumber == 2195
NtBuildNumber == 3790

SSDT

28

Fourteenforty Research Institute, Inc.

コードインジェクション機能
Executable

services.exe
malcodedriver(packed)

user land
1. CreateService()
2. StartService()drivermalcode(packed)kernel land
1. ZwQuerySystemInformation()
2. ZwOpenProcess()
3. ZwAllocateVirtualMemory()
4. (Copy the malcode)
5. (patch to thread object)
6. KeInitializeApc()
7. KeInsertQueueApc()

29

Fourteenforty Research Institute, Inc.

int packet̲analysis(GDDCONFIG *gddc,unsigned char *packet,unsigned long length){
struct ip*ip̲header;/* IP header */struct tcphdr *tcp̲header;/* TCP header */char*tcp̲data;/* TCP data */struct in̲addr addr;/* IP address */charsourceIP[16]; /* Source IP address */char
destIP[16];/* Destination IP address */unsigned short sourcePort;/* Source Port */unsigned short destPort;/* Destination Port */unsigned long len̲data;/* Length of data part */unsigned long iph̲len;/* Length of IP header */unsigned long tcph̲len;/* Length of TCP header */unsigned long sequence;/* Expected sequence */int
portindex;/* Indexnumber of port list */int
direction;/* Packet direction */unsigned char logtype;/* Log type */CONN̲LIST*bcl,*ncl;/* Connection table list */CONN̲LIST*t;/* Temporary connection list */static chardatestr[512]; /* Buffer to store datetime */time̲ttimeval;struct tm*timep=NULL;
char*timesp=NULL;
char
*c;

Chapter 2

仮想化技術の概要/* Get pointer of IP header and check length of IP */if (length-SIZE̲OF̲ETHHDR < MINSIZE̲IP+MINSIZE̲TCP) return(0);ip̲header = (struct ip *)(packet+SIZE̲OF̲ETHHDR);
if (ip̲header->ip̲p!=IPPROTO̲TCP¦¦ ip̲header->ip̲v!=4) return(0);iph̲len= ((unsigned long)(ip̲header->ip̲hl))*4;
if (iph̲len<MINSIZE̲IP) return(0);if ((unsigned long)ntohs(ip̲header->ip̲len) < MINSIZE̲IP+MINSIZE̲TCP)
return(0);if ((unsigned long)ntohs(ip̲header->ip̲len) > length-SIZE̲OF̲ETHHDR){
return(0);}/* Get pointer of TCP header and check length of TCP */tcp̲header = (struct tcphdr *)((char *)ip̲header+iph̲len);tcph̲len= ((unsigned long)(tcp̲header->th̲off))*4;
tcp̲data= (char *)tcp̲header+tcph̲len;
if (tcph̲len<MINSIZE̲TCP) return(0);/* Get other parameter in TCP/IP header */if ((long)ntohs(ip̲header->ip̲len)-(long)iph̲len-(long)tcph̲len<0)
return(0);len̲data= (unsigned long)ntohs(ip̲header->ip̲len)-iph̲len-tcph̲len;sourcePort = ntohs(tcp̲header->th̲sport);
destPort= ntohs(tcp̲header->th̲dport);
memcpy(&addr,&(ip̲header->ip̲src),sizeof(struct in̲addr));strcpy(sourceIP,(char *)inet̲ntoa(addr));
memcpy(&addr,&(ip̲header->ip̲dst),sizeof(struct in̲addr));strcpy(destIP,(char *)inet̲ntoa(addr));if (!strcmp(sourceIP,destIP)) return(0);00001B70 FF 15 F0 11 00 01 E9 CC 03 00 00 E8 7C 1C 00 00
00001B80 33 F6 56 E8 B1 FC FF FF 85 C0 0F 84 B7 03 00 00
00001B90 56 6A 02 FF 35 6C 80 00 01 FF 35 D0 87 00 01 FF
00001BA0 15 CC 11 00 01 85 C0 75 1D 68 10 10 00 00 FF 35
00001BB0 50 80 00 01 FF 35 44 80 00 01 FF 35 D0 87 00 01
00001BC0 FF 15 04 12 00 01 FF 35 D0 87 00 01 FF 15 2C 1200001BD0 00 01 FF 35 D4 8B 00 01 FF 15 58 10 00 01 E9 6400001BE0 03 00 00 83 FE 1A 77 47 0F 84 59 03 00 00 83 FE
00001BF0 11 0F 85 16 01 00 00 33 F6 39 35 E8 87 00 01 74
00001C00 22 8B 3D 28 12 00 01 56 FF D7 56 FF D7 68 00 10
00001C10 00 00 FF 35 50 80 00 01 FF 35 88 80 00 01 E9 7D00001C20 02 00 00 6A 01 E8 0F FC FF FF E9 1A 03 00 00 8B
00001C30 7D 14 B8 11 01 00 00 3B F0 0F 87 8B 00 00 00 3B
00001C40 F0 0F 84 16 02 00 00 83 FE 1C 0F 85 BD 00 00 00
00001C50 33 F6 39 75 10 74 2F A1 EC 87 00 01 8B 0D F0 87
00001C60 00 01 3B C6 75 08 3B CE 0F 84 D9 02 00 00 8B 3D00001C70 14 12 00 01 51 50 68 B1 00 00 00 FF 35 D4 87 00
00001C80 01 E9 56 01 00 00 8B 3D 14 12 00 01 68 F0 87 00
00001C90 01 68 EC 87 00 01 68 B0 00 00 00 FF 35 D4 87 00
00001CA0 01 FF D7 A1 EC 87 00 01 8B 0D F0 87 00 01 3B C100001CB0 75 11 89 35 EC 87 00 01 89 35 F0 87 00 01 E9 8400001CC0 02 00 00 51 50 E9 07 01 00 00 8B CE B8 12 01 00
00001CD0 00 2B C8 0F 84 3C 02 00 00 83 E9 04 0F 84 29 02
00001CE0 00 00 49 0F 84 F9 01 00 00 81 E9 1C 01 00 00 0F
00001CF0 84 E0 01 00 00 81 E9 E6 00 00 00 0F 84 3D 01 00
00001D00 00 81 E9 E8 7C 00 00 0F 84 02 01 00 00 3B 35 5C
00001D10 88 00 01 0F 85 EE 00 00 00 8B 45 14 8B 48 0C 8B
00001D20 C1 8B D1 F7 D0 C1 EA 02 83 E0 01 83 E2 01 F6 C1......鯲...閖...
3
雎...・.┨...
Vj..5l....5ﾐ....
.ﾌ...・u.h.....5
P....5D....5ﾐ...
.......5ﾐ.....,.
...5ﾔ.....X...馘
......wG.Ш.....
.......3.95閾..t".=(...V.ﾗV.ﾗh..
...5P....5・..驀
...j...........急.ｸ....;..㈲...;...........・...
3.9u.t/｡・....
..;ﾆu.;ﾎ.・....=....QPhｱ....5ﾔ..
.餬....=....h.
.h・..hｰ....5ﾔ..
..ﾗ｡・......;ﾁ
u..5・...5..驗...QP.....勤ｸ...
.+ﾈ..<...・...).
..I.・...・.....
・...・......=..
.・閖........;5\....・...畿.稀.驚錦
ﾁ..・.・.

30

Fourteenforty Research Institute, Inc.

仮想化の必要があるリソース• 仮想化技術を利用した場合、1つのVMM（仮想マシンモニタ）、
1つ以上のVM（仮想マシン）が動作する→ 従来OSが占有していたリソースを抽象化する必要がある‒ CPU• システムレジスタ、制御レジスタ
• 例外
‒ メモリ
• VMM、各VMごとの独立したメモリ空間‒ ハードウェア• 割り込み、I/Oアドレス空間、DMAアクセス、etc.
31

Fourteenforty Research Institute, Inc.

従来の仮想メモリの仕組み• 32bit環境では、‒ 実際に搭載している物理メモリの容量に限らずOSからは4GBの仮想メモリが見える‒ OS・アプリケーションは、物理アドレス（PA）を意識せず4GBの仮想アドレス(VA)にアクセスする‒ プロセッサが、物理アドレスと仮想アドレスのマッピングを自動的に行う

VA

PA
32

Fourteenforty Research Institute, Inc.

仮想アドレスから物理アドレスへの変換
VA : 0x802398c3
10000000 001000111001100 011000011

PA : 0x00f928c3
CR3

PD

PT

Page

33

Fourteenforty Research Institute, Inc.

仮想化技術を利用した場合のメモリ仮想化(1/2)••

各VMが独立したアドレス空間を持つ
各VMから見える物理アドレスを更に抽象化する必要がある‒ ゲスト仮想アドレス(Guest VA)、ゲスト物理アドレス(Guest PA)、
ホスト物理アドレス(Host PA)

Guest VA

Guest PA

Host PA34

Fourteenforty Research Institute, Inc.

仮想化技術を利用した場合のメモリ仮想化(2/2)
CR3
VA

PA
PT

CR3

Guest
PA

Host PA

Guest
VA
Guest PT

PT in VMM

35

Fourteenforty Research Institute, Inc.

VMMによるアドレス変換•

現在のプロセッサは、1段階のアドレス変換しかサポートしていない•

VMMは、Guest VA -> Guest PA -> Host PAの2段階のアドレス変換をソフトウェア的に行う必要がある→ Shadow Pagaing•

プロセッサによる2段階アドレス変換のサポート‒ Intel： EPT（Extended Page Table）‒ AMD： NPT（Nested Page Table）

36

Fourteenforty Research Institute, Inc.

Shadow Paging•

ゲストOSのページフォルト例外をインターセプトし、VMMが適時Shadow
Page Table(SPT)を更新

Guest
VA

Guest
PA

Guest
VMM

CR3
Host
PA

Guest
VA
Shadow Page Table

37

Fourteenforty Research Institute, Inc.

Intel VT• Intel VTはIntelによる仮想化技術の総称‒ VT-x‒ VT-d‒ VT-ix86/64向けの仮想化サポート
チップセットによるデバイスの仮想化サポート
Itaniumプロセッサ向けの仮想化サポート• 主な機能‒ VMXモードのサポート• VMX root-operations(ring0-3)• VMX non-root-operations(ring0-3)‒ VMCS（Virtual Machine Control Structure)‒ VMX命令セットのサポート
VMXON、VMXOFF、VMXLAUNCH、VMRESUME、VMCALL、etc.
38

Fourteenforty Research Institute, Inc.

Intel VTの動作メカニズム(Current) VMCS
ゲスト

GDTR IDTR

・・・

Guest State Area

GDTR IDTR

・・・

Host State Area

・・・

VM-execution control field

Excpt
IO
bitmap bitmap
VM-exit control
for MSR

VM-exit VM-entry

Event Injection

・・・

VM-exit control fields

・・・

VM-entry control fields

Exit
Exit
Reason Qualification ・・・

VM-exit information fields

発生したイベントを処理
VMM

39

Fourteenforty Research Institute, Inc.

主なVM̲EXITの発生理由• 特定の命令の実行‒ CPUID, INVD, INVLPG, RDTSC, RDPMC, HLT, etc.
‒ 全てのVMX命令• I/O命令‒ IN, OUT, etc.

• 例外（#DB、#BP、#PF、etc.）• 特定のレジスタへのアクセス‒ コントロールレジスタ‒ デバッグレジスタ‒ MSR（モデル固有レジスタ）

• etc
40

Fourteenforty Research Institute, Inc.

int packet̲analysis(GDDCONFIG *gddc,unsigned char *packet,unsigned long length){
struct ip*ip̲header;/* IP header */struct tcphdr *tcp̲header;/* TCP header */char*tcp̲data;/* TCP data */struct in̲addr addr;/* IP address */charsourceIP[16]; /* Source IP address */char
destIP[16];/* Destination IP address */unsigned short sourcePort;/* Source Port */unsigned short destPort;/* Destination Port */unsigned long len̲data;/* Length of data part */unsigned long iph̲len;/* Length of IP header */unsigned long tcph̲len;/* Length of TCP header */unsigned long sequence;/* Expected sequence */int
portindex;/* Indexnumber of port list */int
direction;/* Packet direction */unsigned char logtype;/* Log type */CONN̲LIST*bcl,*ncl;/* Connection table list */CONN̲LIST*t;/* Temporary connection list */static chardatestr[512]; /* Buffer to store datetime */time̲ttimeval;struct tm*timep=NULL;
char*timesp=NULL;
char
*c;

Chapter 3

Viton, ハイパーバイザーIPS/* Get pointer of IP header and check length of IP */if (length-SIZE̲OF̲ETHHDR < MINSIZE̲IP+MINSIZE̲TCP) return(0);ip̲header = (struct ip *)(packet+SIZE̲OF̲ETHHDR);
if (ip̲header->ip̲p!=IPPROTO̲TCP¦¦ ip̲header->ip̲v!=4) return(0);iph̲len= ((unsigned long)(ip̲header->ip̲hl))*4;
if (iph̲len<MINSIZE̲IP) return(0);if ((unsigned long)ntohs(ip̲header->ip̲len) < MINSIZE̲IP+MINSIZE̲TCP)
return(0);if ((unsigned long)ntohs(ip̲header->ip̲len) > length-SIZE̲OF̲ETHHDR){
return(0);}/* Get pointer of TCP header and check length of TCP */tcp̲header = (struct tcphdr *)((char *)ip̲header+iph̲len);tcph̲len= ((unsigned long)(tcp̲header->th̲off))*4;
tcp̲data= (char *)tcp̲header+tcph̲len;
if (tcph̲len<MINSIZE̲TCP) return(0);/* Get other parameter in TCP/IP header */if ((long)ntohs(ip̲header->ip̲len)-(long)iph̲len-(long)tcph̲len<0)
return(0);len̲data= (unsigned long)ntohs(ip̲header->ip̲len)-iph̲len-tcph̲len;sourcePort = ntohs(tcp̲header->th̲sport);
destPort= ntohs(tcp̲header->th̲dport);
memcpy(&addr,&(ip̲header->ip̲src),sizeof(struct in̲addr));strcpy(sourceIP,(char *)inet̲ntoa(addr));
memcpy(&addr,&(ip̲header->ip̲dst),sizeof(struct in̲addr));strcpy(destIP,(char *)inet̲ntoa(addr));if (!strcmp(sourceIP,destIP)) return(0);00001B70 FF 15 F0 11 00 01 E9 CC 03 00 00 E8 7C 1C 00 00
00001B80 33 F6 56 E8 B1 FC FF FF 85 C0 0F 84 B7 03 00 00
00001B90 56 6A 02 FF 35 6C 80 00 01 FF 35 D0 87 00 01 FF
00001BA0 15 CC 11 00 01 85 C0 75 1D 68 10 10 00 00 FF 35
00001BB0 50 80 00 01 FF 35 44 80 00 01 FF 35 D0 87 00 01
00001BC0 FF 15 04 12 00 01 FF 35 D0 87 00 01 FF 15 2C 1200001BD0 00 01 FF 35 D4 8B 00 01 FF 15 58 10 00 01 E9 6400001BE0 03 00 00 83 FE 1A 77 47 0F 84 59 03 00 00 83 FE
00001BF0 11 0F 85 16 01 00 00 33 F6 39 35 E8 87 00 01 74
00001C00 22 8B 3D 28 12 00 01 56 FF D7 56 FF D7 68 00 10
00001C10 00 00 FF 35 50 80 00 01 FF 35 88 80 00 01 E9 7D00001C20 02 00 00 6A 01 E8 0F FC FF FF E9 1A 03 00 00 8B
00001C30 7D 14 B8 11 01 00 00 3B F0 0F 87 8B 00 00 00 3B
00001C40 F0 0F 84 16 02 00 00 83 FE 1C 0F 85 BD 00 00 00
00001C50 33 F6 39 75 10 74 2F A1 EC 87 00 01 8B 0D F0 87
00001C60 00 01 3B C6 75 08 3B CE 0F 84 D9 02 00 00 8B 3D00001C70 14 12 00 01 51 50 68 B1 00 00 00 FF 35 D4 87 00
00001C80 01 E9 56 01 00 00 8B 3D 14 12 00 01 68 F0 87 00
00001C90 01 68 EC 87 00 01 68 B0 00 00 00 FF 35 D4 87 00
00001CA0 01 FF D7 A1 EC 87 00 01 8B 0D F0 87 00 01 3B C100001CB0 75 11 89 35 EC 87 00 01 89 35 F0 87 00 01 E9 8400001CC0 02 00 00 51 50 E9 07 01 00 00 8B CE B8 12 01 00
00001CD0 00 2B C8 0F 84 3C 02 00 00 83 E9 04 0F 84 29 02
00001CE0 00 00 49 0F 84 F9 01 00 00 81 E9 1C 01 00 00 0F
00001CF0 84 E0 01 00 00 81 E9 E6 00 00 00 0F 84 3D 01 00
00001D00 00 81 E9 E8 7C 00 00 0F 84 02 01 00 00 3B 35 5C
00001D10 88 00 01 0F 85 EE 00 00 00 8B 45 14 8B 48 0C 8B
00001D20 C1 8B D1 F7 D0 C1 EA 02 83 E0 01 83 E2 01 F6 C1......鯲...閖...
3
雎...・.┨...
Vj..5l....5ﾐ....
.ﾌ...・u.h.....5
P....5D....5ﾐ...
.......5ﾐ.....,.
...5ﾔ.....X...馘
......wG.Ш.....
.......3.95閾..t".=(...V.ﾗV.ﾗh..
...5P....5・..驀
...j...........急.ｸ....;..㈲...;...........・...
3.9u.t/｡・....
..;ﾆu.;ﾎ.・....=....QPhｱ....5ﾔ..
.餬....=....h.
.h・..hｰ....5ﾔ..
..ﾗ｡・......;ﾁ
u..5・...5..驗...QP.....勤ｸ...
.+ﾈ..<...・...).
..I.・...・.....
・...・......=..
.・閖........;5\....・...畿.稀.驚錦
ﾁ..・.・.

41

Fourteenforty Research Institute, Inc.

Viton
• OSの外部で動作するIPS• Proof of Concept、Windows XP SP2、SP3で動作確認• 主な機能 指定したメモリ領域に対するメモリパッチングを禁止 システムレジスタの変更を禁止 ゲストOSの活動をモニタリング

実装には、 BitVisor を利用

42

Fourteenforty Research Institute, Inc.

BitVisor• セキュアVMプロジェクトによって開発されている国産VMMソフ
トウェア
• 特徴
‒ Intel VTを利用した軽量な実装‒ Type I型のVMM（ハイパーバイザー型）‒ VMMにおける32bit・64bitモード対応‒ VMM、ゲストOSにおけるマルチコア・マルチプロセッサ対応‒ WindowsXP/Vista、Linuxを修正無しに実行可能‒ ゲストOSにおけるPAEのサポート‒ リアルモードエミュレーションのサポート‒ etc.
43

Fourteenforty Research Institute, Inc.

Bitvisorの動作メカニズム

BIOS
リアルモードエミュレーションを行い、BIOS実行直後に復帰する

NTLDR

GRUB

Bitvisor

VMX-modeに移行し、VMMを起動
Windows

44

Fourteenforty Research Institute, Inc.

Vitonが保護するリソース• 命令‒ ゲストOS上での全てのVMX命令を検出・防止• レジスタ‒ IDTRレジスタの監視‒ 主要なMSRの監視、変更防止‒ CR0.WPビットの監視、変更防止• メモリ‒ カーネルの全てコード領域
‒ IDT
‒ SDT
‒ SSDT

45

Fourteenforty Research Institute, Inc.

メモリ保護のメカニズム• 保護対象の仮想アドレスに対応するPTEのWRビットをクリア‒ CR0.WPが1の場合、ring0の処理でもメモリの書き換えが不可能

Page number

OS

PP
UW
R D A CW
P
SR
DT

Host
PA

Guest
VA
SPT

46

Fourteenforty Research Institute, Inc.

ゲストOSのメモリレイアウトの把握
0x00000000

Guest
IDTR

0x80000000

IDT
N pages
ntoskrnl.exe"MZ""PE\0\0".text...
.edata0xffffffff.edataセクションをパースすることで、カーネルAPIのアドレスを解決可能
47

Fourteenforty Research Institute, Inc.

ゲストOSの活動のモニタリング•

Vitonを利用した場合、Viton以外からのメモリパッチングを防止することができる•

VitonからゲストOSへのパッチングは可能‒

ゲストOSの任意の処理をフックし、活動を監視

1. フックコード用メモリ領域の確保
2. フックコードのセットアップ
3. 対象処理のフック

48

Fourteenforty Research Institute, Inc.

フックコード用メモリ領域の確保(1/3)
任意の処理
mov edi, edi
push ebp...

元の処理を保存

メモリ確保用コード
int3
push 0x1000
push 0x0
call ExAllocatePool
int 3

ゲスト

Viton

49

Fourteenforty Research Institute, Inc.

フックコード用メモリ領域の確保(2/3)
任意の処理
int3
push 0x1000
push 0x0
call ExAllocatePool
int 3

VM-exit

汎用レジスタの値を保存
EIPを1加算

VM-entry
VM-exit

ゲスト

ExAllocatePool APIの返り値をeaxレジスタから取得

Viton

50

Fourteenforty Research Institute, Inc.

フックコード用メモリ領域の確保(3/3)
任意の処理
mov edi, edi
push ebp...

VM-entry

ゲスト

元の処理を復元
保存しておいたEIP・ESPを復元

Viton

51

Fourteenforty Research Institute, Inc.

フックコードのセットアップ & 対象処理のフック
対象の処理
jmp detours_buf
xor eax, eax...

対象の関数が実行されると、
1. detours_bufにジャンプ
2. フックコードが実行される
3. "jmp detours_buf"で上書きした箇所の元の処理が実行される
4. 呼び出し元の上書きした次の処理へ
ジャンプ

detours_buf
フックコード上書きした元のコード
jmp caller_func
ゲスト

Viton

52

Fourteenforty Research Institute, Inc.

フックコードによる活動の監視• 下記のAPIをフックすることでゲストOSのリソースを把握可能‒ ZwCreateProcess/ZwTerminateProcess‒ ZwLoadDriver/ZwUnloadDriver• OS内の情報が改竄されたとしても、Vitonが正しい情報を把
握している

53

Fourteenforty Research Institute, Inc.

デモ

54

Fourteenforty Research Institute, Inc.

dbgsh (Bitvisor's debuging function)

ゲスト
VMCALL

VM-exit

ログバッファ

VM-entry

汎用レジスタ経由でログデータが送られる

VMM

55

Fourteenforty Research Institute, Inc.

Viton vs.
• Type I 「検知」および「防止」が可能• Type II DKOM：活動のモニタリングにより「検知」可能
 KOH：汎用的な対策を行うにはブレークスルーが必要• Type III
 「検知」および「防止」が可能

56

Fourteenforty Research Institute, Inc.

まとめ
• 仮想化技術を利用することで効果的なセキュリティ対策を実現することが可能• 完全ではない‒ 既存ソリューションを保護するための基盤‒ 既存のソリューションとの併用

57

Fourteenforty Research Institute, Inc.

Thank you!

Fourteenforty Research Institute, Inc.
http://www.fourteenforty.jp

シニアリサーチエンジニア
村上 純一<murakami@fourteenforty.jp>58