計算機言語 システム論 発表

1. 計算機言語システム論発表 修士1年　電子情報学専攻 田浦研究室 弘中　健

2. 紹介する論文 • Discoverer: Automatic Protocol Reverse Engineering from Network Traces • Weidong Cui, JayanthkumarKannan, Helen J. Wang • 16th USENIX Security Symposium

3. 背景(1) • Application-level Protocolの仕様を特定したい • 分かり切っているもの：TCP, HTTP • セキュリティ的にも大切 • 仕様を元に、inputを生成してpenetration test • ネットワークにどのようなパケットが流れているか断定したい • Firewall system, IDSなどで解析をする時に仕様が必要

4. 背景(2) • 分からないプロトコル仕様の特定？ • TCP, HTTPなどは分かり切っている • Applicationごとに勝手にいろいろある • 公でないものがほとんど • 例：SAMBA • MicrosoftのSMBプロトコルを12年かけて追跡 • 例：messenger clientソフト • Multiple-protocol対応にするためには。。。

5. 問題 • プロトコルの仕様を突き止める上での問題 • アプリケーションのソースは手に入らない • ネットワークトレースの解析が必要 • バイト列だけでは特定できない • Contentが違えば、メッセージプロトコルが同じでも、byte列は変わる • 今までの手法： • マニュアル作業 • 自動的にネットワークトレースを解析する手法が必要 • ヒントが少ない：バイト列の流れる方向程度 • プロトコルは多種多様 • メッセージの内容は文脈依存

6. 問題定義 • 通信の「プロトコル」とは • 通信両端の有限オートマトン • 例えば、session idなしでsessionの管理 • 通信を流れるメッセージの「フォーマット」 • メッセージのフィールドの構文・意味 • 同じformatでもByte列が変わる • Contentsが違えば変わる

7. 本論文の貢献 • ネットワークトレースを用いた汎用的なプロトコルreverse engineering • プロトコルの全メッセージのフォーマットを推論する • バイト列をトークン列に識別し、クラスタリングを行う • 一つのクラスタが一つのメッセージフォーマットに対応 • Type-based sequence alignment algorithmでover-clusteringを避ける • 状態遷移マシンの推論はfuture work • HTTP, RPC, SMBのネットワークトレースを用いて評価する • Correctness: ~90% • 導かれたフォーマットは一つのフォーマットに対応するか • Conciseness: ~5 • 幾つの導かれたフォーマットが一つのフォーマットに対応しているか • Coverage: • トレース内のメッセージのどれだけが導かれたフォーマット達で説明されるか

8. 概要 • Tokenization/簡単なクラスタリング • バイト列をメッセージに区切る • メッセージをトークン列にする • 各トークンはBinary/textの二種類 • メッセージのトークン列パターンを用いて簡単なクラスタリング • 再帰的クラスタリング • クラスタでフォーマットを推論 • 擬似的にメッセージをパースする • Format Distinguisherというフォーマットを決定づけるようなトークンを基に再帰的にクラスタリングし、繰り返す • マージング • 分かれすぎたクラスタを合わせる • Type-based sequence alignment algorithm

9. 概要図

10. Tokenization • 1つのメッセージを複数のtokenに分割する • 恐らく、「メッセージ」は一方向に一度に流れるbyte列 • Asynchronous protocolはまだ対応していない • Text/binaryの”token class”に振り分けられる • Text class • 各byteをASCII文字と照らし合わせる • ある閾値以上の長さ(binary tokenをtexttokenと間違えない) • Spaceがあれば区切る • Binary class • Text class tokenに挟まれたそれ以外のbyte • 1 byte = 1 token (conservative decision) • この時点での誤検出は大丈夫(後述) ASCII文字 B T T T B B B B space 短すぎ

11. Token Pattern • Token Pattern ::= (direction, tok_class0, tok_class1, …., tok_classN) • e.g.: (Cli_2_serv, B, B, T, T, B) • 同じtoken patternのものを一つのcluster • Byte-patternだと、可変フィールドなどで狂う • 同じpatternでもまだ違うmsg. formatもある

12. Recursive clusteringするには • より細かくclusteringするには、より詳細なsemanticsに関する情報が必要 • 最終的：1 cluster ⇒ 1 msg. format • Msg. format • Token pattern をより詳細にしたもの • Msg. format ::= (token specification)* • Token specification • Token semantics • Token properties

13. Token SpecificationInference • Token property • Token Class ( B or T ) • 既に出来ている • Constant or variable • Cluster内で同じtokenを比較する • Token Semantics • Length field, offset field token • 候補 • At most 4 consecutive binary token (4 byte: integerに値する) • Text token in dec. or hex. • msg間で値の差を取る、それがmsg長の差に該当すればOK • クラスタ内ですべてのmsgで成立すれば、採用 • Cookie fieldなど • なしのtokenが殆ど 10 OK 100 110

14. Msg. Format Comparison • この時点では • クラスタごとに一つのtoken patternがある • クラスタ内でSpecification inferenceで複数のmsg. formatが生まれる • それぞれのmsg. formatにフィットするmsg. sub clusterがある • 次に、二つのmsg. formatが同じかを判定する • Format Comparison • 二つのformatのtoken semanticsを順に比較 • Semanticsがないtokenに関しては値を比較 • 定数　matches 変数 • 定数の値が変数が取る領域に重なる場合 • 変数 matches 変数 • 二つの変数が取る領域に重なりがある場合

15. Format Distinguisher • Applicationがmsg.を読む時、そのtoken以後のformatを既定するtoken • どのようにパースすればいいかを教える • 例えば、明示的なmsg. type field • E.g.: HTTP → ‘OK’ ‘GET’ ‘CONTINUE’ • TokenがFDである要件 • 取る値の種類が閾知以下 • 出来るsub-clusterサイズに下限 • Sub-cluster: • Msg. format with same value for target FD • Sub-clusterが違っても、同じclusterである

16. Emulation • 一般に、msg. formatは複数のFDを持つ • 実際のアプリケーションのように、msg. formatの左から順に走査し、FDを見つけていく • 判定にはクラスタ内msg.達を使う • FDが見つかったら、クラスタ内で再帰的にclusteringをする

17. FDを使ったrecursive clustering 1. FDの値でsubclusterに分ける CLUSTER Smaller Msg. set size FD val: A val: B 2. Subcluster内でFormat inference New format 3.Format comparisonでmerge CLUSTER CLUSTER

18. Merging • いままでを繰り返すと、over-clusteringが起きてしまう • 何百、何千のclusterが一つの実formatに対応 • 何らかの方法でclusterをmergeする必要がある • Type-based sequence alignmentを採用 • ⇔ conventional sequence alignment • 出来たclusterを全対全で比較する

19. Sequence Alignment • 遺伝子配列のmatchingなどに使われる • 考慮すること： • 完全なmatchingは必ずしもない(進化) • Point mutation • ABCD → AACD • Gaps(挿入、削除) • ABCD → ABCAD, AB_D • アルゴリズムに必要なこと • 1要素が空白へのマッチ • 1要素が複数要素にマッチ • 例：最小編集距離 • msgのクラスタリングには使えない • 1要素が変数だったり、可変長だったりする

20. Type-based Sequence Alignment (1) • Seq. Alignmentは複数Formatのmatchingに • Tokenが空白にマッチ • Tokenが複数tokenにマッチ • マッチングには依然のFormat Matchingを使う • ただし、Binary-Binary, Text-Textしか許さない

21. Type-based Sequence Alignment (2) • Seq. Alignmentの特徴を受け継ぐ • Gap: • Text tokenはGapにマッチしてもよい • Point Mutation: • N個連続したBinary Token(合計Nbyte)は長さN以上のText Tokenにマッチしてよい • 制約 • Gapの数は最大２まで • 最大1tokenのmismatchまで許す B T T T T B T T T B T T T T B T T T

22. 例題 • EtherealによるSMBプロトコルの”Tree Connect AndX Request” msg.

23. 回答 • Discovererによるこのmsg. のinference

24. 評価での設定 • Max. message Prefix: 2048 • 初めの2048しか読まない • Min. length of text token: 3bytes • 2byteのASCII文字列はbinaryにされる • Min. msg. cluster size: 20 • Max. distinct values for FD: 10

25. 評価(1) • Several million messagesのtrace 入力 • Honeyfarmのサイト • “busy enterprise” • HTTP, CIFS/SMB, and RPC プロトコルのmsg. • CIFS/SMB, RPCのmsg境界検出にはetherealを使った

26. 評価(2) • Discovererの結果と、etherealを使って得られた「実msg. format」と比較 • Ethereal:すでにformatが分かっているmsg.達に対するnetwork protocol analyzer • Correctness • クラスタ内には1つしか実formatがない • Conciseness • 一つの実formatをいくつのクラスタで表現しているか • Coverage • Msg. coverage • 導かれたformatで説明できるmsg.の割合 • 実format coverage • 説明できるmsgが従う実formatの割合

27. HTTP • HTTPヘッダーでは複数のParamter : Valueペアがある • “set semantics”：含まれているparameterの集合で1つのformat。順番は自由 • まだ対応していない • 一つの集合でもParameter:valueペアの順番が違うごとに別のformatだと思うことにした • 実format数が2696にも膨れ上がった

28. HTTP: msg. distribution • Long Tail • Most msg. in few msg. formats ⇒Low format coverage • Cause:Min-size limit for clustering (20 msgs), unable to identify formats beyond #1000 • Should improve for larger data set size

29. HTTP:Cumulative Dist. Function • Most clusters represent 1 true format • Good correctness • Error reason • Cannot detect difference between “Connection” and “Proxy-Connection” because same values follow • Ethereal does not recognize “Proxy-Connection” and get two True formats

30. HTTP • Merge phase • 4465 ⇒ 3926clusters • Covered true formats: 865 • Conciseness ratio: ～5 • Coverage • Msg. coverage • 99.8 % • Format coverage • 865/2696 • Due to long tail distribution of msg.

31. RPC • Inferred 33 formats for 18true formats • Merge Phase: • 83 ⇒ 33 formats • An example where merging does well • Gives no reason why

32. CIFS/SMB: Cum. Dist. Function • Only 57% of inferred formats correspond to single true format • Due to Ethereal parse error: split 1 true format into 2 ⇒improved to 90% The remaining 10% 2 True formats in question: difference of last field “Stub data (XX bytes)” • Different XX value, Discoverer thinks it’s just a variable field

33. Current Limitations(1) • 根本的な制限：Traceを使用することから出る • Trace依存性 • Traceにないformatは検出できない • Traceで1つしか値を取らないものは定数と思う • Semanticsは事前に定義 • Traceから新しいsemanticsを生み出すことは出来ない

34. Current Limitations(2) • DesignDecisionによる制約、まだ改善の予知があるもの • Semanticsがまだ限られている • Set semantics • “AとBを含むものは一つのformat” • 今は順番が違えばformatも違う • あるfieldが配列だった場合、 • 配列内でのoffsetを定義する • 配列の長さ • 非同期プロトコルへは非対応 • Msg.の区切りが分からない • 一連のmsg.のセッションへは非対応 • Msg.を独立に見ている • 状態遷移オートマトンの推論はやっていない • Future Work • プログラムの解析を織り交ぜる

35. 関連研究 • マニュアル作業 • SAMBA project, messenger clients • Protocol Informatics Project • Byte区切りでsequence alignment • 同じbyte sequenceは検出出来るがformatは無理 • RolePlayer, ScriptGen • Byte sequence alignmentだが、ヒューリスティックを使ってアドレス、cookieなどを検出し、調整する • Application-level replayが目的 • プロトコルのmsg. formatを全部特定したいという目的ではない • Maet al. • Trace内で一連のmsg.がなすsessionをプロトコル別に振り分ける • Byte offsetの分布、マルコフモデルなどを駆使する • プロトコルは識別出来ればいい、msg.のformatの特定はしない • Grammar Inference • 言語のサンプルをもとに、文法を特定する • 理論的に解けない • 正規表現でも無理

36. まとめ • Network Traceを使った自動的なmsg. format inference • 再帰的なclustering,type-based sequence alignmentを用いた • 3つのプロトコルに関して、精度の高いinferenceが出来た • CIFS/SMB, RPC, HTTP • 今後 • プロトコル状態遷移マシーンのinference • プログラム解析も行っていく