System Service 監視による Windows 用 IDS

全体ミーティング 6月6日
島本 大輔(M2)
2006年6月6日(火)
本日の発表内容
• 自分の研究内容と進捗
– System Service 監視による Windows 用
異常検知システム
全体ミーティング 2006年6月6日(火)
2
現在のセキュリティ対策
• ウィルス対策、スパイウェア対策
– パターン定義ファイルとファイルをパターン
マッチ
• ファイアウォール
– ポートやパケットの種類などを予め設定する
• 侵入検知システム
– ルールを予め設定する
• 既に存在している攻撃への対策
• 新種の攻撃には弱い
全体ミーティング 2006年6月6日(火)
3
別のアプローチ
• プログラムの振る舞い(ビヘイビア)を
監視する手法
– 主に UNIX 系 OS で研究が発展
– システムコールを対象として監視した
Forrest らの異常検知システムが有名
全体ミーティング 2006年6月6日(火)
4
Forrest らのシステムの動作図
プログラムの
システムコールフロー
異常検知システム
:
close
部分列を取り出す
open
read
close
open
read
read
write
学習データにあるか
チェック
学習データ
read
True
write
close
異常ではないので、
そのまま制御を戻す
:
全体ミーティング 2006年6月6日(火)
5
Windows での研究
• ビヘイビアを監視する研究は少数
– ptrace のような機構が存在しない
– 内部に関するドキュメントが少ない
– 内部の改変が難しい
UNIX 系 OS における研究を
Windows にも適用できないか
全体ミーティング 2006年6月6日(火)
6
目標
ビヘイビアを利用した
Windows 版異常検知システムを
開発する
全体ミーティング 2006年6月6日(火)
7
研究内容
• 異常検知システムを Windows 上で開発
– Forrest らと同様にシステムコールの
N-gram を利用
• プログラムのビヘイビアを詳しく調査
– 実用的なプログラムを対象に調査
• UNIX 系 OS との比較
全体ミーティング 2006年6月6日(火)
8
System Service
• Windowsの根本的な機能を提供
– Windows 版システムコール
– ファイル、レジストリ、プロセス、スレッド
タイマー、mutex、GDI
• 数が非常に多い
– 286個(Windows 2000)
– 991個(
〃
XP SP1)
※Linux のシステムコールは 300 ぐらい
全体ミーティング 2006年6月6日(火)
9
NtReadFile の例
Win32
プログラム
ReadFile
Win32
サブシステム
ユーザ
モード
カーネル
モード
全体ミーティング 2006年6月6日(火)
POSIX
プログラム
Read
POSIX
サブシステム
OS/2
プログラム
Read?
OS/2
サブシステム
NtReadFile
Windows
Kernel
10
System Service の動作図
ユーザ
モード
カーネル
モード
ユーザモード
プログラム
SSDT
XXXXXX
NtReadFile
:
アドレスを引く
全体ミーティング 2006年6月6日(火)
System Service の
処理
11
システムの特徴
• デバイスドライバと GUI の2つからなる
– デバイスドライバ
System Service の監視
– GUI
デバイスドライバの制御とログの保存
• すべての ユーザモード Windows
プログラムを監視可能
– カーネルモードのプログラムは対象外
全体ミーティング 2006年6月6日(火)
12
システムの動作図
ユーザ
モード
我々のシステム
GUI
ユーザ
プログラム
GUI
制御や
ログのやりとり
カーネル
モード
デバイス
ドライバ
全体ミーティング 2006年6月6日(火)
監視
コード
System Service の
処理
13
System Service の監視方法
• 2通りの手法が存在
1. SSDT Patching
2. Interrupt Hooking
全体ミーティング 2006年6月6日(火)
14
SSDT Patching
• System Service のアドレステーブル
(System Service Descriptor Table)
を書き換え
• System call table の書き換えと同様
• 監視する System Service を個別に
指定可能
• レジストリの監視や rootkit などにも
使われている
全体ミーティング 2006年6月6日(火)
15
SSDT Patching の動作図
ユーザ
モード
ユーザモード
プログラム
SSDT Patching
アドレスを書換
SSDT
XXXXXX
NtReadFile
監視コード
:
アドレスを引く
カーネル
モード
全体ミーティング 2006年6月6日(火)
X
System Service の
処理
16
Interrupt Interception
• Kernel mode へ遷移する瞬間
(Interrupt)に intercept
– Windows 2000以前ではソフトウェア
割り込み(int 2e)
– Windows XP以降は sysenter 命令
全体ミーティング 2006年6月6日(火)
17
System Service の動作図
ユーザ
モード
ユーザモード
プログラム
Interrupt Interception
jump 先を変更
SSDT
XXXXXX
NtReadFile
:
アドレスを引く
カーネル
モード
全体ミーティング 2006年6月6日(火)
監視コード
アドレスを引く
System Service の
処理
18
System Service の監視
• Interrupt Interception を採用
– Win XP なので、sysenter の jump 先を
変更
– メリット
• コード量、メモリ使用量を抑えられる
• 実装が容易
• 1箇所で監視可能
全体ミーティング 2006年6月6日(火)
19
System Service
Interception
System Service のコード
アドレスを引く
XXXXXX
NtOpenFile
NtDeleteFil
e
SSDT Patching
アドレスを書換
:
Kernel
Interrupt Interception
Mode
遷移した後のjump先を変更
User
User Mode
Mode
アプリケーション
全体ミーティング 2006年6月6日(火)
20
実装内容
• デバイスドライバ部分
– Interception コードの挿入・取り外しを担当
– Kernel mode で動作
• GUI プログラム
– デバイスドライバの操作を担当
– User mode で動作
全体ミーティング 2006年6月6日(火)
21
デバイスドライバ部分
• 基本的に C 言語で記述
– sysenter の jump 先の変更は
インラインアセンブリ
• 監視コードもデバイスドライバの中に存在
– Kernel内なので、コードのアドレスはどこでも
同じ
全体ミーティング 2006年6月6日(火)
22
sysenter の jump 先を
変更するコード
void Intercept() {
__asm {
push eax
push ecx
push edx
mov ecx, 176h
rdmsr
mov old_eip_h, edx
mov old_eip_l, eax
cli
mov ecx, 176h
全体ミーティング 2006年6月6日(火)
}
}
xor edx, edx
mov eax, TakeCallLog
wrmsr
pop edx
pop ecx
pop eax
sti
return;
23
GUI プログラム
• デバイスドライバの操作
– 挿入、削除
• デバイスドライバとの通信
– ログをデバイスドライバから読み出し、出力
– Intercept する System Service の変更を
デバイスドライバに伝達
全体ミーティング 2006年6月6日(火)
24
実験
1. オーバヘッド
2. 異常検知手法の有効性
– N-gram と Branching Factor
– False Positive
– Linux との比較
実験環境
 CPU:Intel PentiumM 1.3 GHz
 メモリ:512MB
 OS:Windows XP SP1
全体ミーティング 2006年6月6日(火)
25
実験1:オーバヘッド
• マイクロベンチマーク
– NtTestAlert() を1億回呼び出し、その時間
を計測
• 実用的な例
– Explorer.exe にて、ファイルの検索に必要
な
時間を計測
全体ミーティング 2006年6月6日(火)
26
実験1:結果
マイクロベンチマーク
要した時間
本システムなし
60.9秒
本システム動作時
69.4秒
Explorer.exe による検索実験
1回目
2回目
3回目
4回目
本システムなし
1分27秒
13秒
13秒
13秒
本システム動作時
1分39秒
19秒
14秒
13秒
全体ミーティング 2006年6月6日(火)
27
実験1の考察
• オーバヘッドが約13%となっており、より
複雑な検知手法を適用する余裕がある
– スタックやメモリの状態、System Service
の引数を利用する
– 有限オートマトンを利用する、など
全体ミーティング 2006年6月6日(火)
28
実験2:N-gram と Branching
Factor
• 実用的なプログラムで実験
– Firefox 1.5
– OpenOffice.org Impress
• 上記プログラムを1時間ほど実行し、ログ
を収集、オフラインで解析
– プログラムの生成する N-gram の要素数を
カウント
– 上と同じデータより平均 branching Factor
を求めた
全体ミーティング 2006年6月6日(火)
29
N-gram
• ある連続した値の、長さ N の
部分列集合
– 例:システムコール列
{open, read, read, write, close}
の長さ(N=)3 の 3-gram は
{open, read, read}
{read, read, write}
{read, write, close}
の3種類になる。
全体ミーティング 2006年6月6日(火)
30
Branching Factor = 分岐数
• ある列の一定の長さの部分列に対して、
次に発生する可能性のある値の種類数
例:
A, B, C, A, B, D, A, B, C の
部分列 A, B の branching factor は 2(C と D)。
これが、N=3 のときの branching factor。
• 一般的には、列の集合からすべての部分列に
関して、この値を求め、その平均を利用する
全体ミーティング 2006年6月6日(火)
31
実験2:N-gram と Branching
Factor
• Linux において同様の実験を実施
– Strace を使用して、システムコールの記録を
取得
– Windows と同様に N-gram の要素数と
平均 branching factor を求めた
実験環境
 CPU: AMD Athlon 1.2 GHz
 メモリ:256 MB
 OS:Debian Linux 3.1(カーネル 2.4.27)
全体ミーティング 2006年6月6日(火)
32
実験2の結果
• Firefox(Windows 版)の例
80000
N-gram の要素数
70000
60000
7-gram
6-gram
5-gram
4-gram
3-gram
2-gram
50000
40000
30000
20000
10000
0
0
500
1000
1500
万
呼び出された System Service の総数
全体ミーティング 2006年6月6日(火)
33
実験2 N-gram の結果
Impress
Firefox
80000
60000
7-gram
6-gram
5-gram
4-gram
3-gram
2-gram
50000
40000
30000
20000
10000
0
0
500
1000
1500
万
N-gram の要素数
Windows
N-gram の要素数
70000
50000
45000
40000
35000
30000
25000
20000
15000
10000
5000
0
7-gram
6-gram
5-gram
4-gram
3-gram
2-gram
0
500
1000
万
呼び出された System Service の総数
呼び出された System Service の総数
20000
14000
18000
N-gram の要素数
Linux
7-gram
6-gram
5-gram
4-gram
3-gram
2-gram
14000
12000
10000
8000
6000
4000
N-gram の要素数
12000
16000
7-gram
6-gram
5-gram
4-gram
3-gram
2-gram
10000
8000
6000
4000
2000
2000
0
0
20
40
60
0
80
万
0
20
40
60
80
万
呼び出されたシステムコールの総数
呼び出されたシステムコールの総数
全体ミーティング 2006年6月6日(火)
34
実験2 Branching Factor の結果
Windows
N
2
3
4
5
6
7
Firefox
10.25
3.10
2.13
1.79
1.59
1.45
Impress
10.86
2.93
1.92
1.57
1.43
1.34
5
6
7
Linux
N
2
3
4
Firefox
7.81
2.92
2.13
1.84
1.65
1.51
Impress
8.40
3.07
2.00
1.66
1.51
1.41
全体ミーティング 2006年6月6日(火)
35
実験2 の考察
• N-gram の要素数は時間とともに増え続ける
– 従来の研究では収束する結果が出ていた
– 単純に N-gram の要素数を利用するのは GUI の
ような複雑なプログラムでは不十分
• Branching factor は、どちらの OS も N=3
において、3 前後の値
– 少ないメモリ使用量で異常検知ができる可能性
– OS に依存しない性質の可能性
全体ミーティング 2006年6月6日(火)
36
実験3:False Positive
• 実験方法
1. 実験2 で得たデータを学習データとする
2. 新たに、それぞれのプログラムを実行し、再度収
集
3. 新しいデータを学習データと比較
4. 学習データに含まれないものが false positive
となる
全体ミーティング 2006年6月6日(火)
37
False Positive
• 誤って異常と判定された正常な動作や
データ
• 少ないほど検知の精度が高いことになる
全体ミーティング 2006年6月6日(火)
38
実験3 結果
実験データ内の False Positive の割合
N
1
Firefox
0.40%
Impress
2
3
4
5
6
7
4.99% 11.20% 17.45% 23.36% 28.68% 33.31%
18.57% 33.89% 37.59% 40.26% 41.97% 43.06% 44.06%
• Nが小さい場合で既に false positive の割
合が大きい
– 学習できていない N-gram の要素が多数存在
全体ミーティング 2006年6月6日(火)
39
研究のまとめ
• Windows 向け異常検知システムを開発した
– プログラムの振る舞い(System Service)を
利用した異常検知手法を実装
• 性能や有効性を測る実験を行った
– より複雑な手法を適用できる可能性
• 異なる OS 間における比較した
– OS に依存しない検出手法の可能性
全体ミーティング 2006年6月6日(火)
40
今後の予定
• 他のプログラムで実験(特にサーバなど)
– PostgreSQL、Apache、VNC など
• 他のアルゴリズムの実装
– System Service の引数を利用する
– 有限オートマトンやデータマイニングを用いる
全体ミーティング 2006年6月6日(火)
41