ハードウェアによる仮想化支援機能を利用したハイパーバイザーIPS
利用したイ
イザ 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 longlen̲data;/* Length of data part */unsigned longiph̲len;/* Length of IP header */unsigned longtcph̲len;/* Length of TCP header */unsigned longsequence;/* Expected sequence */int
portindex;/* Indexnumber of port list */int
direction;/* Packet direction */unsigned charlogtype;/* 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
00001B80
00001B90
00001BA0
00001BB000001BC000001BD000001BE000001BF000001C00
00001C1000001C20
00001C30
00001C40
00001C50
00001C60
00001C70
00001C80
00001C90
00001CA000001CB000001CC000001CD000001CE000001CF000001D00
00001D1000001D20

FF 15 F0 11 00 01 E9 CC 03 00 00 E8 7C 1C 00 00
33 F6 56 E8 B1 FC FF FF 85 C0 0F 84 B7 03 00 00
56 6A 02 FF 35 6C 80 00 01 FF 35 D0 87 00 01 FF
15 CC 11 00 01 85 C0 75 1D 68 10 10 00 00 FF 35
50 80 00 01 FF 35 44 80 00 01 FF 35 D0 87 00 01
FF 15 04 12 00 01 FF 35 D0 87 00 01 FF 15 2C 12
00 01 FF 35 D4 8B 00 01 FF 15 58 10 00 01 E9 64
03 00 00 83 FE 1A 77 47 0F 84 59 03 00 00 83 FE
11 0F 85 16 01 00 00 33 F6 39 35 E8 87 00 01 74
22 8B 3D 28 12 00 01 56 FF D7 56 FF D7 68 00 10
00 00 FF 35 50 80 00 01 FF 35 88 80 00 01 E9 7D
02 00 00 6A 01 E8 0F FC FF FF E9 1A 03 00 00 8B
7D 14 B8 11 01 00 00 3B F0 0F 87 8B 00 00 00 3B
F0 0F 84 16 02 00 00 83 FE 1C 0F 85 BD 00 00 00
33 F6 39 75 10 74 2F A1 EC 87 00 01 8B 0D F0 87
00 01 3B C6 75 08 3B CE 0F 84 D9 02 00 00 8B 3D
14 12 00 01 51 50 68 B1 00 00 00 FF 35 D4 87 00
01 E9 56 01 00 00 8B 3D 14 12 00 01 68 F0 87 00
01 68 EC 87 00 01 68 B0 00 00 00 FF 35 D4 87 00
01 FF D7 A1 EC 87 00 01 8B 0D F0 87 00 01 3B C1
75 11 89 35 EC 87 00 01 89 35 F0 87 00 01 E9 84
02 00 00 51 50 E9 07 01 00 00 8B CE B8 12 01 00
00 2B C8 0F 84 3C 02 00 00 83 E9 04 0F 84 29 02
00 00 49 0F 84 F9 01 00 00 81 E9 1C 01 00 00 0F
84 E0 01 00 00 81 E9 E6 00 00 00 0F 84 3D 01 00
00 81 E9 E8 7C 00 00 0F 84 02 01 00 00 3B 35 5C
88 00 01 0F 85 EE 00 00 00 8B 45 14 8B 48 0C 8B
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の挙動を変更しOSの挙動を変更し、情報の隠ぺい
情報の隠ぺいを行うソフトウェア（マルウェア）※Joanna Rukowska
Rukowska、"Introducing
Introducing Stealth Malware Taxnomy"
Taxnomyhttp://invisiblethings.org/papers/malware-taxonomy.pdf

ステルスマルウェアがパッチングを行うリソースの性質に基づいてType
yp 0からType
yp 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

コ ド領域
コード領域

デ タ領域
データ領域

ハードウェアT
Type
I

システムレジスタ

11Fourteenforty Research Institute, Inc.

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

・・・MSR[176h]
IDTR

SDT(ntoskrnl.exe)

Nt* APIs

SSDT

KiSystemService

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

Nt* API
APIs(User/GDI)

SSDT

12

Fourteenforty Research Institute, Inc.

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

SDT(ntoskrnl.exe)

Nt* APIs

SSDT

KiSystemService

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

Nt* API
APIs(User/GDI)

SSDT

13

Fourteenforty Research Institute, Inc.

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

MSR[176h]
IDTR

SDT(ntoskrnl.exe)

Nt* APIs

SSDT

KiSystemService

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

Nt* API
APIs(User/GDI)

SSDT

14

Fourteenforty Research Institute, Inc.

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

MSR[176h]
IDTR

SDT(ntoskrnl.exe)

Nt* APIs

SSDT

KiSystemService

IDT

other
interrupt
handlers

・・・
SDT Shadow(win32k.sys)

Nt* API
APIs(User/GDI)

SSDT

15

Fourteenforty Research Institute, Inc.

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

Fourteenforty Research Institute, Inc.

Type II

プロセス

コード領域

データ領域

OS

コ ド領域
コード領域

デ タ領域
データ領域

ハードウェアT
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
p• 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

プロセスリストを取得する処理

コード領域

T
Type
II

データ領域

19

Fourteenforty Research Institute, Inc.

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

OS

プロセスリストを取得する処理

コード領域

T
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ルートキット
フ
ムウ アル トキ トや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
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によって異なる
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()
2.
St tS i ()kernel land
drivermalcode(packed)

1. ZwQuerySystemInformation()
2. ZwOpenProcess()
3 ZwAllocateVirtualMemory()3.
4. (Copy the malcode)
5. (patch to thread object)
6 KeInitializeApc()
6.
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 longlen̲data;/* Length of data part */unsigned longiph̲len;/* Length of IP header */unsigned longtcph̲len;/* Length of TCP header */unsigned longsequence;/* Expected sequence */int
portindex;/* Indexnumber of port list */int
direction;/* Packet direction */unsigned charlogtype;/* 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
00001B80
00001B90
00001BA0
00001BB000001BC000001BD000001BE000001BF000001C00
00001C1000001C20
00001C30
00001C40
00001C50
00001C60
00001C70
00001C80
00001C90
00001CA000001CB000001CC000001CD000001CE000001CF000001D00
00001D1000001D20

FF 15 F0 11 00 01 E9 CC 03 00 00 E8 7C 1C 00 00
33 F6 56 E8 B1 FC FF FF 85 C0 0F 84 B7 03 00 00
56 6A 02 FF 35 6C 80 00 01 FF 35 D0 87 00 01 FF
15 CC 11 00 01 85 C0 75 1D 68 10 10 00 00 FF 35
50 80 00 01 FF 35 44 80 00 01 FF 35 D0 87 00 01
FF 15 04 12 00 01 FF 35 D0 87 00 01 FF 15 2C 12
00 01 FF 35 D4 8B 00 01 FF 15 58 10 00 01 E9 64
03 00 00 83 FE 1A 77 47 0F 84 59 03 00 00 83 FE
11 0F 85 16 01 00 00 33 F6 39 35 E8 87 00 01 74
22 8B 3D 28 12 00 01 56 FF D7 56 FF D7 68 00 10
00 00 FF 35 50 80 00 01 FF 35 88 80 00 01 E9 7D
02 00 00 6A 01 E8 0F FC FF FF E9 1A 03 00 00 8B
7D 14 B8 11 01 00 00 3B F0 0F 87 8B 00 00 00 3B
F0 0F 84 16 02 00 00 83 FE 1C 0F 85 BD 00 00 00
33 F6 39 75 10 74 2F A1 EC 87 00 01 8B 0D F0 87
00 01 3B C6 75 08 3B CE 0F 84 D9 02 00 00 8B 3D
14 12 00 01 51 50 68 B1 00 00 00 FF 35 D4 87 00
01 E9 56 01 00 00 8B 3D 14 12 00 01 68 F0 87 00
01 68 EC 87 00 01 68 B0 00 00 00 FF 35 D4 87 00
01 FF D7 A1 EC 87 00 01 8B 0D F0 87 00 01 3B C1
75 11 89 35 EC 87 00 01 89 35 F0 87 00 01 E9 84
02 00 00 51 50 E9 07 01 00 00 8B CE B8 12 01 00
00 2B C8 0F 84 3C 02 00 00 83 E9 04 0F 84 29 02
00 00 49 0F 84 F9 01 00 00 81 E9 1C 01 00 00 0F
84 E0 01 00 00 81 E9 E6 00 00 00 0F 84 3D 01 00
00 81 E9 E8 7C 00 00 0F 84 02 01 00 00 3B 35 5C
88 00 01 0F 85 EE 00 00 00 8B 45 14 8B 48 0C 8B
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.
割り込み 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
10000000001000111001100011000011

PA : 0x00f928c3
CR3

PD

PT

Page

33

Fourteenforty Research Institute, Inc.

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

各VMが独立したアドレス空間を持つ
各VMから見える物理アドレスを更に抽象化する必要がある– ゲスト仮想アドレス(Guest VA)
VA)、ゲスト物理アドレス(Guest
ゲスト物理アドレス(Guest PA)
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
VMMは
Guest VA ->> Guest PA ->> Host PAの2段階のアドレス変換をソフトウェア的に行う必要がある→ Shadow Pagaing•

プロセッサによる2段階アドレス変換のサポート– Intel：I l EPT（Extended
EPT（E
d dP
Page T
Table）bl ）– 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-dVT 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
VMXON、VMXOFF、VMXLAUNCH、VMRESUME、VMCALL、etc.
38

Fourteenforty Research Institute, Inc.

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

VM-exit VM-entry

GDTR IDTR

・・・

Guest State Area

GDTR IDTR

・・・

Host State Area

Excpt
IO
bitmap bitmap
VM-exit control
for MSR

・・・

VM-execution control field

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,
IN OUT
OUT, etc.
t• 例外（#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 longlen̲data;/* Length of data part */unsigned longiph̲len;/* Length of IP header */unsigned longtcph̲len;/* Length of TCP header */unsigned longsequence;/* Expected sequence */int
portindex;/* Indexnumber of port list */int
direction;/* Packet direction */unsigned charlogtype;/* 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 ハイパ
Viton,
ハイパーバイザーIPS
バイザ 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
00001B80
00001B90
00001BA0
00001BB000001BC000001BD000001BE000001BF000001C00
00001C1000001C20
00001C30
00001C40
00001C50
00001C60
00001C70
00001C80
00001C90
00001CA000001CB000001CC000001CD000001CE000001CF000001D00
00001D1000001D20

FF 15 F0 11 00 01 E9 CC 03 00 00 E8 7C 1C 00 00
33 F6 56 E8 B1 FC FF FF 85 C0 0F 84 B7 03 00 00
56 6A 02 FF 35 6C 80 00 01 FF 35 D0 87 00 01 FF
15 CC 11 00 01 85 C0 75 1D 68 10 10 00 00 FF 35
50 80 00 01 FF 35 44 80 00 01 FF 35 D0 87 00 01
FF 15 04 12 00 01 FF 35 D0 87 00 01 FF 15 2C 12
00 01 FF 35 D4 8B 00 01 FF 15 58 10 00 01 E9 64
03 00 00 83 FE 1A 77 47 0F 84 59 03 00 00 83 FE
11 0F 85 16 01 00 00 33 F6 39 35 E8 87 00 01 74
22 8B 3D 28 12 00 01 56 FF D7 56 FF D7 68 00 10
00 00 FF 35 50 80 00 01 FF 35 88 80 00 01 E9 7D
02 00 00 6A 01 E8 0F FC FF FF E9 1A 03 00 00 8B
7D 14 B8 11 01 00 00 3B F0 0F 87 8B 00 00 00 3B
F0 0F 84 16 02 00 00 83 FE 1C 0F 85 BD 00 00 00
33 F6 39 75 10 74 2F A1 EC 87 00 01 8B 0D F0 87
00 01 3B C6 75 08 3B CE 0F 84 D9 02 00 00 8B 3D
14 12 00 01 51 50 68 B1 00 00 00 FF 35 D4 87 00
01 E9 56 01 00 00 8B 3D 14 12 00 01 68 F0 87 00
01 68 EC 87 00 01 68 B0 00 00 00 FF 35 D4 87 00
01 FF D7 A1 EC 87 00 01 8B 0D F0 87 00 01 3B C1
75 11 89 35 EC 87 00 01 89 35 F0 87 00 01 E9 84
02 00 00 51 50 E9 07 01 00 00 8B CE B8 12 01 00
00 2B C8 0F 84 3C 02 00 00 83 E9 04 0F 84 29 02
00 00 49 0F 84 F9 01 00 00 81 E9 1C 01 00 00 0F
84 E0 01 00 00 81 E9 E6 00 00 00 0F 84 3D 01 00
00 81 E9 E8 7C 00 00 0F 84 02 01 00 00 3B 35 5C
88 00 01 0F 85 EE 00 00 00 8B 45 14 8B 48 0C 8B
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における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の監視、変更防止
主要なMSRの監視 変更防止
– CR0.WPビットの監視、変更防止• メモリ– カーネルの全てコード領域
– IDT
– SDT
– SSDT

45

Fourteenforty Research Institute, Inc.

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

OS

PPUW
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"
MZ

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

Fourteenforty Research Institute, Inc.

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

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

VitonからゲストOSへのパッチングは可能– ゲストOSの任意の処理をフックし、活動を監視ゲ
任意 処理をク 活動を監視1. フックコード用メモリ領域の確保
2 フックコ2.
フックコードのセットアップ
ドのセットアップ
3. 対象処理のフック

48

Fourteenforty Research Institute, Inc.

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

元の処理を保存

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

Vit
Viton

49

Fourteenforty Research Institute, Inc.

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

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

VM-entry

VM-exit

ゲスト

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

Vit
Viton

50

Fourteenforty Research Institute, Inc.

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

VM-entry

ゲスト

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

Vit
Viton

51

Fourteenforty Research Institute, Inc.

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

対象の関数が実行されると、

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

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

Vit
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)

ゲスト
VMCALLVM-entry
VM-exit

ログバッファ
グバ

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

VMM

55

Fourteenforty Research Institute, Inc.

Viton vs.
• Type I「検知」および「防止」が可能• Type II
DKOM：活動のモニタリングにより「検知」可能
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