全体ミーティング 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
• ある連続した値の、長さ Ｎ の
部分列集合
– 例：システムコール列
{open, read, read, write, close}
の長さ（Ｎ=）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
© Copyright 2024 ExpyDoc
