全体ミーティング 6月6日 島本 大輔（M2） 2006年6月6日（火）

本日の発表内容 自分の研究内容と進捗 System Service 監視による Windows 用 異常検知システム

現在のセキュリティ対策 ウィルス対策、スパイウェア対策 ファイアウォール 侵入検知システム パターン定義ファイルとファイルをパターン マッチ ポートやパケットの種類などを予め設定する 侵入検知システム ルールを予め設定する （TODO：最近のセキュリティ対策ソフトについて調査 既に存在している攻撃への対策 新種の攻撃には弱い

別のアプローチ プログラムの振る舞い（ビヘイビア）を 監視する手法 主に UNIX 系 OS で研究が発展 システムコールを対象として監視した Forrest らの異常検知システムが有名

Forrest らのシステムの動作図 異常検知システム プログラムの システムコールフロー : close 学習データ open read write 学習データ 学習データにあるか チェック 部分列を取り出す close open read write True 異常ではないので、 そのまま制御を戻す

Windows での研究 ビヘイビアを監視する研究は少数 ptrace のような機構が存在しない 内部に関するドキュメントが少ない 内部の改変が難しい UNIX 系 OS における研究を Windows にも適用できないか

ビヘイビアを利用した Windows 版異常検知システムを 開発する 目標 ビヘイビアを利用した Windows 版異常検知システムを 開発する

研究内容 異常検知システムを Windows 上で開発 プログラムのビヘイビアを詳しく調査 UNIX 系 OS との比較 Forrest らと同様にシステムコールの N-gram を利用 プログラムのビヘイビアを詳しく調査 実用的なプログラムを対象に調査 UNIX 系 OS との比較

System Service Windowsの根本的な機能を提供 数が非常に多い Windows 版システムコール ファイル、レジストリ、プロセス、スレッド タイマー、mutex、GDI 数が非常に多い 286個（Windows 2000） 991個（ 〃 XP SP1） ※Linux のシステムコールは 300 ぐらい

NtReadFile の例 Win32 プログラム POSIX プログラム OS/2 プログラム Win32 サブシステム POSIX ユーザ モード NtReadFile カーネル モード Windows Kernel

System Service の動作図 ユーザモード プログラム System Service の 処理 SSDT ユーザ モード カーネル モード SSDT NtReadFile XXXXXX : アドレスを引く System Service の 処理

システムの特徴 デバイスドライバと GUI の2つからなる すべての ユーザモード Windows プログラムを監視可能 デバイスドライバ System Service の監視 GUI 　デバイスドライバの制御とログの保存 すべての ユーザモード Windows プログラムを監視可能 カーネルモードのプログラムは対象外

システムの動作図 我々のシステム GUI ユーザ プログラム GUI デバイス ドライバ 監視 コード ユーザ モード GUI ユーザ プログラム GUI 制御や ログのやりとり カーネル モード デバイス ドライバ 監視 コード System Service の 処理

System Service の監視方法 2通りの手法が存在 SSDT Patching Interrupt Hooking

SSDT Patching System Service のアドレステーブル （System Service Descriptor Table）を書き換え System call table の書き換えと同様 監視する System Service を個別に 指定可能 レジストリの監視や rootkit などにも 使われている System call tableの利用方法を調査

X SSDT Patching の動作図 ユーザモード プログラム System Service の 処理 ユーザ モード ユーザモード プログラム SSDT Patching アドレスを書換 監視コード SSDT NtReadFile XXXXXX : アドレスを引く System Service の 処理 X カーネル モード

Interrupt Interception Kernel mode へ遷移する瞬間 （Interrupt）に intercept Windows 2000以前ではソフトウェア 割り込み（int 2e） Windows XP以降は sysenter 命令 Kernel 2.6で合ってる？

System Service の動作図 ユーザモード プログラム System Service の 処理 ユーザ モード ユーザモード プログラム Interrupt Interception jump 先を変更 監視コード SSDT NtReadFile XXXXXX : アドレスを引く アドレスを引く System Service の 処理 カーネル モード

System Service の監視 Interrupt Interception を採用 Win XP なので、sysenter の jump 先を 変更 メリット コード量、メモリ使用量を抑えられる 実装が容易 1箇所で監視可能

System Service Interception アドレスを引く NtOpenFile XXXXXX NtDeleteFile : SSDT Patching アドレスを書換 Kernel Mode Interrupt Interception 遷移した後のjump先を変更 User Mode User Mode アプリケーション

実装内容 デバイスドライバ部分 GUI プログラム Interception コードの挿入・取り外しを担当 Kernel mode で動作 デバイスドライバの操作を担当 User mode で動作

デバイスドライバ部分 基本的に C 言語で記述 監視コードもデバイスドライバの中に存在 sysenter の jump 先の変更は インラインアセンブリ 監視コードもデバイスドライバの中に存在 Kernel内なので、コードのアドレスはどこでも 同じ

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 xor edx, edx mov eax, TakeCallLog wrmsr pop edx pop ecx pop eax sti } return;

GUI プログラム デバイスドライバの操作 デバイスドライバとの通信 挿入、削除 ログをデバイスドライバから読み出し、出力 Intercept する System Service の変更を デバイスドライバに伝達

実験 オーバヘッド 異常検知手法の有効性 N-gram と Branching Factor False Positive Linux との比較 実験環境 CPU：Intel PentiumM 1.3 GHz メモリ：512MB OS：Windows XP SP1

実験1：オーバヘッド マイクロベンチマーク 実用的な例 NtTestAlert() を1億回呼び出し、その時間を計測 Explorer.exe にて、ファイルの検索に必要な 時間を計測

実験1：結果 マイクロベンチマーク Explorer.exe による検索実験 要した時間 本システムなし 60.9秒 本システム動作時 69.4秒 Explorer.exe による検索実験 1回目 2回目 3回目 4回目 本システムなし 1分27秒 13秒 本システム動作時 1分39秒 19秒 14秒

実験1の考察 オーバヘッドが約13%となっており、より複雑な検知手法を適用する余裕がある スタックやメモリの状態、System Service の引数を利用する 有限オートマトンを利用する、など

実験2：N-gram と Branching Factor 実用的なプログラムで実験 Firefox 1.5 OpenOffice.org Impress 上記プログラムを1時間ほど実行し、ログ を収集、オフラインで解析 プログラムの生成する N-gram の要素数を カウント 上と同じデータより平均 branching Factor を求めた

N-gram ある連続した値の、長さ Ｎ の 部分列集合 例：システムコール列 {open, read, read, write, close} の長さ（Ｎ=）3 の 3-gram は {open, read, read} {read, read, write} {read, write, close} の3種類になる。

Branching Factor = 分岐数 ある列の一定の長さの部分列に対して、 次に発生する可能性のある値の種類数 例： A, B, C, A, B, D, A, B, C の 部分列 A, B の branching factor は 2（C と D）。 これが、N=3 のときの branching factor。 一般的には、列の集合からすべての部分列に 関して、この値を求め、その平均を利用する

実験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）

実験2の結果 Firefox（Windows 版）の例

実験2 N-gram の結果 Firefox Impress Windows Linux

実験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 Linux N 2 3 4 5 6 7 Firefox 7.81 2.92 2.13 1.84 1.65 1.51 Impress 8.40 3.07 2.00 1.66 1.41

実験2 の考察 N-gram の要素数は時間とともに増え続ける 従来の研究では収束する結果が出ていた 単純に N-gram の要素数を利用するのは GUI の ような複雑なプログラムでは不十分 Branching factor は、どちらの OS も N=3 において、3 前後の値 少ないメモリ使用量で異常検知ができる可能性 OS に依存しない性質の可能性

実験3：False Positive 実験方法 実験2 で得たデータを学習データとする 新たに、それぞれのプログラムを実行し、再度収集 新しいデータを学習データと比較 学習データに含まれないものが false positive となる

False Positive 誤って異常と判定された正常な動作やデータ 少ないほど検知の精度が高いことになる

実験データ内の False Positive の割合 実験3 結果 実験データ内の False Positive の割合 N 1 2 3 4 5 6 7 Firefox 0.40% 4.99% 11.20% 17.45% 23.36% 28.68% 33.31% Impress 18.57% 33.89% 37.59% 40.26% 41.97% 43.06% 44.06% Nが小さい場合で既に false positive の割合が大きい 学習できていない N-gram の要素が多数存在

研究のまとめ Windows 向け異常検知システムを開発した 性能や有効性を測る実験を行った 異なる OS 間における比較した プログラムの振る舞い（System Service）を 利用した異常検知手法を実装 性能や有効性を測る実験を行った より複雑な手法を適用できる可能性 異なる OS 間における比較した OS に依存しない検出手法の可能性

今後の予定 他のプログラムで実験（特にサーバなど） 他のアルゴリズムの実装 PostgreSQL、Apache、VNC など System Service の引数を利用する 有限オートマトンやデータマイニングを用いる