CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checker:悪性文書ファイル検知ツール~ファイルサイズからにじみ出る悪意
大坪 雄平
1
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
目次
2
1.はじめに2.バイナリエディタで見る
悪性文書ファイルの構造3.o-checkerの概要4.o-checkerの検知の仕組み5.デモンストレーション6.o-checkerの応用例7.おわりに
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
1.はじめに
3
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
標的型攻撃の増加①
4
1.はじめに
http://www.symantec.com/threatreport/topic.jsp?aid=industrial_espionage&id=malicious_code_trends
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
標的型攻撃の増加②
5
政府機関等への標的型メールに関する注意喚起の件数
※GSOC:Government Security Operation Coordination team政府機関情報セキュリティ横断監視・即応調整チーム
1.はじめに
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
標的型攻撃の増加③
6
20112007
5.4% → 33%
出典:経済産業省委託調査(2007年、2011年)
標的型と見られるサイバー攻撃を受けたことがある(企業)
1.はじめに
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
標的型攻撃の例
7
1.はじめに
機密情報
マルウェア付きメールを送信
添付ファイルを開く
マルウェアに感染
特定の企業や個人のネットワーク
攻撃者 受信者
機密情報の漏えい
①
②
③
④
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
標的型メール攻撃の添付ファイル
8標的型メール攻撃の添付ファイル拡張子の傾向(2013年上半期トレンドマイクロ調べ)http://is702.jp/special/1431/
実行ファイル形式:59%文書ファイル形式:41%
1.はじめに
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
2.バイナリエディタで見る悪性文書ファイルの構造
9
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
文書ファイル
exploit
shell code
RAT(実行ファイル)
表示用(ダミー)ファイル
実行ファイルが埋め込まれた悪性文書ファイルの構造
10
閲覧ソフトの脆弱性を突くコード
RAT・表示用ファイルのデコード出力実行・表示
様々な方式でエンコード文書ファイルの表示内容と関係しない部分
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性文書ファイルの具体例~バイナリエディタを中心に
11
Bitmap View Hex View
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:exploit(1/2)
12
31番のオブジェクトJavaScript本体(exploit)Flate圧縮されている
2.バイナリエディタで見る悪性文書ファイルの構造
29番のオブジェクトJavaScript実際の中身は31番のオブジェクト
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:exploit(2/2)
13
Flate圧縮されているデータを展開すると…
↓エスケープ処理をされたshellcode
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:shellcode
14
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:shellcode
15
デコーダ 40 Byte
印刷可能な文字に変換されたshellcode本体
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:実行ファイル(1/2)
16
2.バイナリエディタで見る悪性文書ファイルの構造
エンコードされた実行ファイル
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:実行ファイル(2/2)
17
デコードした実行ファイル
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性PDFファイル具体例:表示用(ダミー)ファイル
18
2.バイナリエディタで見る悪性文書ファイルの構造
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
3.O-CHECKERの概要
19
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
不正なコードを静的解析・動的解析し得られた特徴を検知に利用する
文書ファイル
exploit
shell code
RAT(実行ファイル)
表示用(ダミー)ファイル
従来の悪性文書ファイルの検知
20
不正なコード
3.o-checkerの概要
従来の手法
・ 不正なコードをエンコードすることにより静的解析から得られる特徴を容易に書換可能
・ 特定の条件でのみ動作するマルウェアは動的解析が難しい
課題
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
イタチごっこ
21
攻撃者が任意に記述できる部分(不正なデータの中身)を検知に利用すると…
イタチごっこ
3.o-checkerの概要
不正なコードを元にシグネチャを作成
防御側
シグネチャに引っかからないように不正なコードを作成
攻撃側
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
イタチごっこからの脱出
22
攻撃者が任意に記述できない部分(例えばファイルフォーマット)を検知に利用すると…
イタチごっこ
3.o-checkerの概要
ファイルフォーマットに着目した静的解析を元にシグネチャを作成
防御側
シグネチャに引っかからないように不正なコードを作成
攻撃側
シグネチャに引っかからないようにファイルフォーマットを変更
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
ファイルフォーマットから見る悪性文書ファイルの特徴
23
文書ファイルは画像、テキスト、補助的なデータなど様々なデータの集合体
閲覧ソフトが処理しないデータは文書ファイルの中に通常は入れない
閲覧ソフトが処理するデータか否か
理由
exploit ○ 閲覧ソフトの脆弱性を攻撃するため
shellcode ○ 通常はexploitの中に組み込み
実行ファイル × 閲覧ソフトが読み込むと文字化けや誤作動して攻撃の成功確率が下がる
表示用(ダミー)ファイル
× 閲覧ソフトが読み込むと文字化けや誤作動して攻撃の成功確率が下がる
3.o-checkerの概要
それぞれのデータには何かしら役目がある
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checkerの検知の仕組み(簡略版)
内部構造と表示内容が対応
表示内容 内部構造
内部構造と表示内容が対応しない
表示内容 内部構造
一般的な文書ファイル 悪性文書ファイル
内部構造を検査して検知
3.o-checkerの概要
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checkerの効果
25
・ 高速かつ高い検知率検知率 98.9% 平均実行時間 約0.3秒
・ メンテナンスフリー
更新頻度 備考
ウイルス対策ソフト 毎日 1日あたり20万個の新種マルウェア(2012年)※
o-checker ほぼなし 新しい文書ファイル形式が出れば更新
msanalysis.py入力
実行ファイルが埋込まれたファイル
pdfanalysis.py入力
検知
3.o-checkerの概要
※:http://www.kaspersky.com/about/news/virus/2012/2012_by_the_numbers_Kaspersky_Lab_now_detects_200000_new_malicious_programs_every_day
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
4.O-CHECKERの検知の仕組み
26
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checkerの検査項目
27
①EOFの後にデータがついていないか
②ファイルサイズが異常でないか
③FATで参照できない領域が追加されていないか
④ファイル末端がFree Sectorでないか
⑤使途不明のsectorがないか
⑥分類できないセクションがないか
⑦参照されないオブジェクトがないか
⑧偽装されたStreamがないか
Rich Text
CFB
o-checker
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
Rich Text形式のファイルの基本構造
28
{¥rtfHello!¥parThis is some {¥b bold} text.¥par}
RTFのデータはテキスト形式を用いており、プレーンテキストに装飾やレイアウトのための制御用の文字列を付加した形式となっている※
※:wikipediaより引用
図:Rich Text形式のファイルの例
RTFファイルであることを示すシグネチャ
最初の`{`に対応する`}`がファイルの最後(EOF)
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
①EOFの後にデータがついていないか
29
{¥rtfHello!¥parThis is some {¥b bold} text.¥par}MZ・ク
・ コ エ ヘ!クL!This program cannot be run in DOS mode.$ 猝t讀ォオ、ォオ、ォオュモ招ヲォオュモ楫喚オ、ォオ0ェオュモ卸・オュモ匏ウォ
Rich、ォオPE d・ ヤノ[J ・ "
表示に影響を与えないファイル末尾に実行ファイルを挿入
図:実行ファイルを埋め込まれたRich Text形式のファイルの例
EOFの後にデータが存在
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
CFB形式のファイル(doc、xls、ppt、 jtd/jtdc )
30
Root Storage
Storage 1 Storage 2
Storage 3
Stream A
Stream B Stream C
引用:[MS-CFB] – v20130118 Compound File Binary Format (http://msdn.microsoft.com/en-us/library/dd942138.aspx)
ファイルシステムでいうとStream → ファイルStorage → フォルダ
CFB:Compound File Binary複数のデータを階層構造で1つのファイルに格納できるMicrosoft社が作成したアーカイブ形式Micrsoft Word等で使用されている
doc,ppt,xls,jtd/jtdc※
4.o-checkerの検知の仕組み
※:Justsystem社が開発した日本語ワープロソフトで使用する拡張子
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
CFB(doc、xls、ppt、jtd/jtdc)のファイル構造
31
header
FAT0
Directory Entry
Stream A
Stream A
Free Sector
Stream B
1
2
3
4
5
Physical Structure
-2
-2
3
-2
-1
-2
Directory Entry
index
sector
4.o-checkerの検知の仕組み
Stream Name:a.txtSize:696 Index:2
Stream Name:b.txtSize:318 Index:5
Storage Name:rootSize:- Index:-
FAT(File Allocation Table)
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
CFB(doc、xls、ppt、jtd/jtdc)のファイル構造
32
header
FAT0
Directory Entry
Stream A
Stream A
Free Sector
Stream B
1
2
3
4
5
Physical Structure
512 Byte
(512 or 4096) x N Byte
FileSize = 512 + (512 or 4096) x N= 512 x M
正規のCFBファイルのファイルサイズは必ず512の倍数
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
②ファイルサイズが異常でないか
33
header
FAT0
Directory Entry
Stream A
Stream A
Free Sector
Stream B
1
2
3
4
5
Physical Structure
-2
-2
3
-2
-1
-2
FAT(File Allocation Table)
Directory Entry
malware6
7
ヘッダを除いたファイルサイズがsectorサイズ単位でない 512 で割ったら余りが出る
4.o-checkerの検知の仕組み
Stream Name:a.txtSize:696 Index:2
Stream Name:b.txtSize:318 Index:5
Storage Name:rootSize:- Index:-
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
③FATで参照できない領域が追加されていないか
34
header
FAT0
Directory Entry
Stream A
Stream A
Free Sector
Stream B
1
2
3
4
5
Physical Structure
-2
-2
3
-2
-1
-2
Directory Entry
malware6
7
FATで参照可能な領域にファイルが収まっていない
-1
FATで参照可能な領域:(FATセクタ数)×128×512 (Byte)
4.o-checkerの検知の仕組み
Stream Name:a.txtSize:696 Index:2
Stream Name:b.txtSize:318 Index:5
Storage Name:rootSize:- Index:-
FAT(File Allocation Table)
?
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
④ファイル末端がFree Sectorでないか
35
header
FAT0
Directory Entry
Stream A
Stream A
Free Sector
Stream B
1
2
3
4
5
Physical Structure
-2
-2
3
-2
-1
-2
Directory Entry
malware6-1
sectorサイズが512バイトの場合n = (ファイルサイズ-512)/512
n
4.o-checkerの検知の仕組み
Stream Name:a.txtSize:696 Index:2
Stream Name:b.txtSize:318 Index:5
Storage Name:rootSize:- Index:-
FAT(File Allocation Table)
ファイルの最後に対応するsector(n番目のsector)がFree Sector
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
⑤使途不明のsectorがないか
36
header
FAT0
Directory Entry
Stream A
Stream A
Free Sector
Stream B
1
2
3
4
5
Physical Structure
-2
-2
3
-2
-1
-2
Directory Entry
malware6
FAT(DI-FAT、miniFATを含む)、DE、Stream、Free Sectorに分類できないsectorがある
-2
4.o-checkerの検知の仕組み
Stream Name:a.txtSize:696 Index:2
Stream Name:b.txtSize:318 Index:5
Storage Name:rootSize:- Index:-
FAT(File Allocation Table)
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
PDFファイル
PDFの基本構造:ファイル構造
コメント(ヘッダ)
本体
相互参照テーブル
トレーラーコメント(EOF)
ページコンテンツやグラフィックスコンテンツ、多くの補助的な情報がオブジェクト一式としてエンコードされている
1 0 obj
2 0 obj
n 0 obj
ファイルの終端を示すマーカー
x 0 obj <</R2 /P-64 /V 2 /O (dfhjaklgk… …>>
PDFは大量のオブジェクト(整数、文字列、バイナリデータ等)の集合体
4種類のセクション
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
PDFの基本構造:オブジェクト型
38
基本的なオブジェクト①整数や実数②文字列③名前④ブーリアン値⑤nullオブジェクト
複合オブジェクト⑥配列⑦辞書
その他⑧Stream(バイナリデータを格納するためのもの)⑨間接参照
(PDF32000-1:2008 7.3)
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
PDFの基本構造:Streamのエンコード
39
PDF標準の機能としてStreamにフィルタをかけることができ、そのデコード処理を行う。主なフィルタは下表のとおり。
名称 概要
/ASCIIHexDecode 2桁の16進数で表現された文字列から1バイトのデータを復元
/ASCII85Decode !からzまでの印字可能文字を使用して表現された文字列からデータを復元
/LZWDecode TIFF画像形式で用いられているLZW圧縮されたデータを展開
/FlateDecode Zlibライブラリで用いられているFlate圧縮されたデータを展開
/RunLengthDecode バイト単位の単純なランレングス圧縮されたデータを展開
/CCITTFaxDecode ファックス機器で使用されているエンコーディング形式のデータを展開
/JBIG2Decode JBIG2圧縮されたデータを展開
/DCTDecode JPEGによる不可逆圧縮されたデータを展開
/JPXDecode JPEG2000による不可逆圧縮されたデータを展開
4.o-checkerの検知の仕組み
(PDF32000-1:2008 7.4)
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
PDFの基本構造:ドキュメント構造
40
トレーラ
ドキュメント情報辞書
ドキュメントカタログ
ドキュメントアウトライン
ページリスト
ページ1 ページ2
ページ1のコンテンツ
ページ1のリソース
ページ2のコンテンツ
ページ2のリソース
:オブジェクト
図:2ページからなる一般的なPDFファイルのドキュメント構造
:参照リンク
トレーラ辞書オブジェクトからリンクをたどっていくとすべてのオブジェクトを参照することができる
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
PDFの基本構造:ドキュメントの暗号化
41
トレーラ
ドキュメント情報辞書
ドキュメントカタログ
ドキュメントアウトライン
ページリスト
ページ1 ページ2
ページ1のコンテンツ
ページ1のリソース
ページ2のコンテンツ
ページ2のリソース
:オブジェクト
図:暗号化されたPDFファイル
:参照リンク
基本的に文字列及びStreamのみが暗号化復号しなくてもドキュメント構造にアクセスできる(ObjStmに格納されているオブジェクトは除く)
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
PDFの基本構造:ObjStm(オブジェクトストリーム)
42
PDF1.5以降で、複数のオブジェクトを単一のStreamに格納しそのStream全体を圧縮することでPDFファイルをさらにコンパクトなものにするというObjStmというものが導入されている( PDF32000-1:2008 7.5.7)
1つにまとめて
圧縮 (暗号化PDF)暗号化
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
⑥分類できないセクションがないか
43
PDFファイル
コメント(ヘッダ)
本体
相互参照テーブル
トレーラーコメント(EOF)
実行ファイル
ファイルの先頭から順番に読み込みどのセクションに該当するか分類しようとすると分類できない部分がある
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
⑦参照されないオブジェクトがないか
44
トレーラ
ドキュメント情報辞書
ドキュメントカタログ
ドキュメントアウトライン
ページリスト
ページ1 ページ2
ページ1のコンテンツ
ページ1のリソース
ページ2のコンテンツ
ページ2のリソース
:オブジェクト
:参照リンク
実行ファイル
図:実行ファイルが埋め込まれたPDFファイルのドキュメント構造
ドキュメント構造を無視して実行ファイルが埋め込まれるとどこからも参照されていないオブジェクトとなることが多い
実行ファイル :実行ファイルが埋め込まれたオブジェクト
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
実行ファイル
⑧偽装されたStreamがないか
45
フィルタ偽装
Stream末端に追加
正規のStream EOD
データの終了を示す情報
デコードに使用されるデータ(通常どおりデコード可能)
デコードに使用されないデータ
FlateDecode、DCTDecodeおよびJBIG2Decodeの場合
エントロピー
プレーンテキスト 小
FlateDecode 大
実行ファイル 大
エントロピーの値が近いフィルタを使用しているように偽装(デコードしようとすると失敗する)
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
悪性文書ファイル 通常の文書ファイル
ファイル形式
拡張子 検体数平均容量(KB)
検体数平均容量(KB)
Rich Text rtf 98 266.5 199 516.2
doc 36 252.2 1,195 106.1
CFB xls 49 180.4 298 191.7
jtd/jtdc 17 268.5 - -
PDF pdf 164 351.2 9,109 101.7
合計 364 291.8 10,801 322.7
実験
46
2009年から2012年までに標的型メール攻撃に使用された文書ファイル※1
マルウェアダンプサイトcontagioでclean(マルウェアではない)とされた文書ファイル※2
※1:docに拡張子が偽装されたRich Textはrtfでカウント※2:http://contagiodump.blogspot.jp/2013/03/16800-clean-and-11960-malicious-files.html
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checkerの検査項目と検知率
47
①EOFの後にデータがついていないか
②ファイルサイズが異常でないか
③FATで参照できない領域が追加されていないか
④ファイル末端がFree Sectorでないか
⑤使途不明のsectorがないか
⑥分類できないセクションがないか
⑦参照されないオブジェクトがないか
⑧偽装されたStreamがないか
Rich Text
CFB
o-checker 99.0%
77.5%
90.2%
97.1%
96.1%
49.4%
43.9%
63.4%
99.0%
98.0%
99.4%
4.o-checkerの検知の仕組み
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
5.デモンストレーション
48
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checkerのログ
49
C:¥tmp>pdfanalysis.py a.pdf
00000000-00000008:comment,00000009-0000000F:comment,00000010-00000110:obj 25 0 old(not used)00000111-00000197:obj 26 0 old(not used)
:00003622-000036B0:trailer000036B1-000036C2:startxref 00003617000036C3-000036C9:comment,000036CA-0000E9E2:unknown0000E9E3-0000E9E9:comment,0000E9EA-0000EAEA:obj 25 0 ObjStm [7, 8, 13]
:0001209D-000120A3:comment,000120A4-000120A7:unknownFFFFFFFF-FFFFFFFF:obj 7 0 xref from NoneFFFFFFFF-FFFFFFFF:obj 8 0 xref from None
:
offset address 分類結果
Dummy Document
ObjStm
5.デモンストレーション
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
判定オプション
50
C:¥tmp>pdfanalysis.py a.pdf -j
00000000-00000008:comment,00000009-0000000F:comment,00000010-00000110:obj 25 0 old(not used)00000111-00000197:obj 26 0 old(not used)
::
0001209D-000120A3:comment,FFFFFFFF-FFFFFFFF:obj 7 0 xref from NoneFFFFFFFF-FFFFFFFF:obj 8 0 xref from None
:Malicious!
-j判定オプションログの最後に
Malicious!Suspicious!None!
の3段階表示
5.デモンストレーション
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
51
DEMO 1
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
6.O-CHECKERの応用例
52
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
NIDSとo-checker
53
LANケーブル
NIDS
o-checker
パケットキャプチャ
メール復元
通知
既存のシステムをほとんど変更することなくo-checkerを導入可能
6.o-checkerの応用例
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
NIDS
NIDSとo-checkerの課題
54
LANケーブル
o-checker
パケットキャプチャ
メール復元
通知
メールの復元に失敗~2%
壊れた文書ファイル~2%
フォルス・ポジティブup ~2%
ネットワークフォレンジック製品の仕様または性能に応じて誤検知が発生
6.o-checkerの応用例
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
NIDS
NIDSと改良型o-checker
55
LANケーブル
newo-checker
パケットキャプチャ
メール復元
通知
メールの復元に失敗~2%
壊れた文書ファイル~2%
フォルス・ポジティブup ~0%
ファイルフォーマットに着目した構造解析で壊れた文書ファイルを除外
6.o-checkerの応用例
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
o-checker
Android端末へのo-checkerの適用その1
56
メールサーバ
Manual delete
Manual check
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
57
DEMO 2
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
E-mailer
o-checker
Android端末へのo-checkerの適用その2
58
メールサーバ
Auto delete
Auto check
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
7.おわりに
59
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
まとめ
60
• 従来の検知法には限界がある• 実行ファイルを埋め込んだ文書ファイル
に対しファイルフォーマットに着目した構造解析は有効
• o-checkerは高速に高確率で悪性文書ファイルを検知するため様々な応用が考えられる
7.おわりに
CODE BLUE Feb.17 (Mon) - 18 (Tue), 2014 Tokyo, Japan
61
ありがとうございました