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

紹介する論文• Discoverer: Automatic Protocol Reverse

Engineering from Network Traces– Weidong Cui, Jayanthkumar Kannan, Helen J.

Wang– 16th USENIX Security Symposium

背景 (1)

• Application-level Protocolの仕様を特定したい–分かり切っているもの： TCP, HTTP

• セキュリティ的にも大切–仕様を元に、 inputを生成して penetration test–ネットワークにどのようなパケットが流れているか断定したい• Firewall system, IDSなどで解析をする時に仕様が必要

背景 (2)

• 分からないプロトコル仕様の特定？– TCP, HTTPなどは分かり切っている– Applicationごとに勝手にいろいろある• 公でないものがほとんど

• 例： SAMBA– Microsoftの SMBプロトコルを 12年かけて追跡

• 例： messenger clientソフト– Multiple-protocol対応にするためには。。。

問題• プロトコルの仕様を突き止める上での問題

– アプリケーションのソースは手に入らない• ネットワークトレースの解析が必要

– バイト列だけでは特定できない• Contentが違えば、メッセージプロトコルが同じでも、 byte列は変わる

• 今までの手法：– マニュアル作業

• 自動的にネットワークトレースを解析する手法が必要– ヒントが少ない：バイト列の流れる方向程度– プロトコルは多種多様– メッセージの内容は文脈依存

問題定義• 通信の「プロトコル」とは–通信両端の有限オートマトン• 例えば、 session idなしで sessionの管理

–通信を流れるメッセージの「フォーマット」• メッセージのフィールドの構文・意味• 同じ formatでも Byte列が変わる

– Contentsが違えば変わる

本論文の貢献• ネットワークトレースを用いた汎用的なプロトコル reverse engineering• プロトコルの全メッセージのフォーマットを推論する

– バイト列をトークン列に識別し、クラスタリングを行う– 一つのクラスタが一つのメッセージフォーマットに対応– Type-based sequence alignment algorithmでover-clusteringを避ける

• 状態遷移マシンの推論は future work

• HTTP, RPC, SMBのネットワークトレースを用いて評価する– Correctness: ~90%

• 導かれたフォーマットは一つのフォーマットに対応するか– Conciseness: ~5

• 幾つの導かれたフォーマットが一つのフォーマットに対応しているか– Coverage:

• トレース内のメッセージのどれだけが導かれたフォーマット達で説明されるか

概要• Tokenization/簡単なクラスタリング

– バイト列をメッセージに区切る– メッセージをトークン列にする

• 各トークンは Binary/textの二種類– メッセージのトークン列パターンを用いて簡単なクラスタリング

• 再帰的クラスタリング– クラスタでフォーマットを推論– 擬似的にメッセージをパースする

• Format Distinguisherというフォーマットを決定づけるようなトークンを基に再帰的にクラスタリングし、繰り返す• マージング

– 分かれすぎたクラスタを合わせる– Type-based sequence alignment algorithm

概要図

Tokenization• 1つのメッセージを複数の tokenに分割する

– 恐らく、「メッセージ」は一方向に一度に流れる byte列– Asynchronous protocolはまだ対応していない

• Text/binaryの” token class”に振り分けられる– Text class

• 各byteをASCII文字と照らし合わせる• ある閾値以上の長さ　 (binary tokenを text tokenと間違えない )• Spaceがあれば区切る

– Binary class• Text class tokenに挟まれたそれ以外の byte• 1 byte = 1 token (conservative decision)

• この時点での誤検出は大丈夫 (後述 )　

B T T BT

ASCII文字

space 短すぎB B B

• 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もある

Token Pattern

Recursive clusteringするには• より細かく clusteringするには、より詳細な semanticsに関する情報が必要– 最終的： 1 cluster 1 msg. format⇒

• Msg. format– Token pattern をより詳細にしたもの

• Msg. format ::= (token specification)*– Token specification• Token semantics• Token properties

Token Specification Inference• 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が殆ど

100110

10

OK

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 変数– 二つの変数が取る領域に重なりがある場合

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である

Emulation

• 一般に、 msg. formatは複数の FDを持つ• 実際のアプリケーションのように、 msg.

formatの左から順に走査し、 FDを見つけていく– 判定にはクラスタ内msg.達を使う

• FDが見つかったら、クラスタ内で再帰的に clusteringをする

FDを使った recursive clustering

2. Subcluster内で Format inference

SmallerMsg. set

sizeval: Bval: A

1. FDの値でsubclusterに分けるFDCLUSTER

CLUSTER CLUSTER

New format

3. Format comparisonで

merge

Merging

• いままでを繰り返すと、 over-clusteringが起きてしまう– 何百、何千の clusterが一つの実 formatに対応– 何らかの方法で clusterをmergeする必要がある

• Type-based sequence alignmentを採用– ⇔ conventional sequence alignment–出来た clusterを全対全で比較する

Sequence Alignment• 遺伝子配列のmatchingなどに使われる• 考慮すること：

– 完全なmatchingは必ずしもない ( 進化 )• Point mutation

– ABCD → AACD• Gaps( 挿入、削除 )

– ABCD → ABCAD, AB_D

• アルゴリズムに必要なこと– 1要素が空白へのマッチ– 1要素が複数要素にマッチ– 例：最小編集距離

• msgのクラスタリングには使えない– 1要素が変数だったり、可変長だったりする

Type-based Sequence Alignment (1)

• Seq. Alignmentは複数 Formatのmatchingに– Tokenが空白にマッチ– Tokenが複数 tokenにマッチ

• マッチングには依然の Format Matchingを使う–ただし、 Binary-Binary, Text-Textしか許さない

• Seq. Alignmentの特徴を受け継ぐ– Gap:

• Text tokenはGapにマッチしてもよい

– Point Mutation:• N 個連続した Binary Token(合計Nbyte)は長さN以上の Text Tokenにマッチしてよい

• 制約– Gapの数は最大２まで– 最大 1tokenのmismatchまで許す

Type-based Sequence Alignment (2)

B T T T

B T T T

T

B T T T T

B T T T

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

Request” msg.

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

評価での設定• 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

評価 (1)

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

評価 (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の割合

HTTP

• HTTP ヘッダーでは複数の Paramter : Valueペアがある– “set semantics”：含まれている parameterの集合で 1つの format。順番は自由• まだ対応していない

• 一つの集合でも Parameter:value ペアの順番が違うごとに別の formatだと思うことにした– 実 format数が 2696にも膨れ上がった

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

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

HTTP

• Merge phase– 4465 3926⇒ 　 clusters– Covered true formats: 865– Conciseness ratio: ～ 5

• Coverage– Msg. coverage

• 99.8 %– Format coverage

• 865/2696• Due to long tail distribution of msg.

RPC

• Inferred 33 formats for 18　 true formats

• Merge Phase:– 83 33 formats⇒

• An example where merging does well– Gives no reason why

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

Current Limitations(1)

• 根本的な制限： Traceを使用することから出る– Trace依存性• Traceにない formatは検出できない• Traceで 1つしか値を取らないものは定数と思う

– Semanticsは事前に定義• Traceから新しい semanticsを生み出すことは出来ない

Current Limitations(2)• Design Decisionによる制約、まだ改善の予知があるもの

– Semanticsがまだ限られている• Set semantics

– “AとBを含むものは一つの format”– 今は順番が違えば formatも違う

• ある fieldが配列だった場合、– 配列内でのoffsetを定義する– 配列の長さ

– 非同期プロトコルへは非対応• Msg.の区切りが分からない

– 一連のmsg.のセッションへは非対応• Msg.を独立に見ている

– 状態遷移オートマトンの推論はやっていない• Future Work

– プログラムの解析を織り交ぜる

関連研究• マニュアル作業

– SAMBA project, messenger clients• Protocol Informatics Project

– Byte区切りで sequence alignment– 同じbyte sequenceは検出出来るが formatは無理

• RolePlayer, ScriptGen– Byte sequence alignmentだが、ヒューリスティックを使ってアドレス、cookieなどを検出し、調整する– Application-level replayが目的

• プロトコルのmsg. formatを全部特定したいという目的ではない• Ma et al.

– Trace内で一連のmsg.がなす sessionをプロトコル別に振り分ける• Byte offsetの分布、マルコフモデルなどを駆使する

– プロトコルは識別出来ればいい、msg.の formatの特定はしない• Grammar Inference

– 言語のサンプルをもとに、文法を特定する– 理論的に解けない

• 正規表現でも無理

まとめ• Network Traceを使った自動的なmsg. format

inference• 再帰的な clustering, type-based sequence alignmentを用いた• 3つのプロトコルに関して、精度の高い inferenceが出来た– CIFS/SMB, RPC, HTTP

• 今後– プロトコル状態遷移マシーンの inference– プログラム解析も行っていく