(57)【要約】  ネットワークフロー内のエクスプロイトコードを検出する方法および装置を開示する。ネットワークデータパケットは、フローモニタによってインターセプトされ、フローモニタは、インターセプトされたデータパケットからデータフローを生成する。コンテンツフィルタは、データフローから正規のプログラムをフィルタリングし、フィルタリングされていない部分は、実行コードを検出するコードレコグナイザに提供される。フィルタリングされていないデータフロー部分の中に組み込まれている実行コードは、ネットワークフロー内のエクスプロイトである疑いがあるものとして識別される。実行コードレコグナイザは、データフローのフィルタリングされていない部分に対してコンバージェント・バイナリ・ディスアセンブリを行うことによって、実行コードを認識する。次いで、実行コードレコグナイザは、実行コードを検出するために、制御フローグラフを作成して、制御フロー分析とデータフロー分析と制約強化とを行う。検出した実行コードをエクスプロイト候補として識別することに加えて、その後、検出した実行コードは、エクスプロイトを検出する際に他のシステムによって使用されるように、エクスプロイト候補のシグネチャを生成するために利用することもできる。
2008519374.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークトラヒックをモニタリングする方法であって、
ネットワークデータパケットをインターセプトするステップと、
前記インターセプトしたデータパケットからデータフローを生成するステップと、
前記データフローの少なくとも一部分をフィルタリングするステップと、
前記データフローのフィルタリングされていない部分の中の実行コードを検出するステップと
を備えることを特徴とする方法。
【請求項２】
前記フィルタリングは、予め定められたルールのセットに基づくことを特徴とする請求項１に記載の方法。
【請求項３】
前記フィルタリングするステップは、
前記データフローから正規のプログラムコードをフィルタリングするステップ
を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記正規のプログラムコードが悪意のあるコードを含むか否かを判定するステップ
をさらに備えることを特徴とする請求項３に記載の方法。
【請求項５】
前記検出した実行コードをエクスプロイト候補として識別するステップ
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項６】
前記実行コードを検出するステップは、
前記データフローの前記フィルタリングされていない部分に対してコンバージェント・バイナリ・ディスアセンブリを行うステップ
を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記実行コードを検出するステップは、
制御フローグラフを作成するステップと、
前記制御フローグラフを用いて制御フロー分析を行うステップと
をさらに含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記実行コードを検出するステップは、
データフロー分析を行うステップと、
制約強化を行うステップと
をさらに含むことを特徴とする請求項７に記載の方法。
【請求項９】
前記検出した実行コードからコードシグネチャを生成するステップ
をさらに備えることを特徴とする請求項１に記載の方法。
【請求項１０】
ネットワークトラヒックをモニタリングするシステムであって、
インターセプトされたネットワークデータパケットを受信するネットワークインターフェースと、
前記インターセプトされたネットワークデータパケットからデータフローを生成するフローモニタと、
前記データフローの少なくとも一部分をフィルタリングするコンテンツフィルタと、
前記データフローのフィルタリングされていない部分の中の実行コードを検出する実行コードレコグナイザと
を備えたことを特徴とするシステム。
【請求項１１】
前記コンテンツフィルタは、フィルタリングルールのセットを格納することを特徴とする請求項１０に記載のシステム。
【請求項１２】
前記コンテンツフィルタは、前記データフローから正規のプログラムコードをフィルタリングすることを特徴とする請求項１０に記載のシステム。
【請求項１３】
前記正規のプログラムコードが悪意のあるコードを含むか否かを判定する悪意プログラムアナライザ
をさらに備えたことを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記実行コードレコグナイザは、コンバージェント・バイナリ・ディスアセンブリを行うことを特徴とする請求項１０に記載のシステム。
【請求項１５】
ネットワークトラヒックをモニタリングするシステムであって、
ネットワークデータパケットをインターセプトする手段と、
前記インターセプトしたデータパケットからデータフローを生成する手段と、
前記データフローの少なくとも一部分をフィルタリングする手段と、
前記データフローのフィルタリングされていない部分の中の実行コードを検出する手段と
を備えたことを特徴とするシステム。
【請求項１６】
前記フィルタリングする手段は、予め定められたルールのセットを含むことを特徴とする請求項１５に記載のシステム。
【請求項１７】
前記フィルタリングする手段は、
前記データフローから正規のプログラムコードをフィルタリングする手段
を含むことを特徴とする請求項１５に記載のシステム。
【請求項１８】
前記正規のプログラムコードが悪意のあるコードを含むか否かを判定する手段
をさらに備えたことを特徴とする請求項１７に記載のシステム。
【請求項１９】
前記検出した実行コードをエクスプロイト候補として識別する手段
をさらに備えたことを特徴とする請求項１５に記載のシステム。
【請求項２０】
前記実行コードを検出する手段は、
前記データフローの前記フィルタリングされていない部分に対してコンバージェント・バイナリ・ディスアセンブリを行う手段
を含むことを特徴とする請求項１５に記載のシステム。
【請求項２１】
前記実行コードを検出する手段は、
制御フローグラフを作成する手段と、
前記制御フローグラフを用いて制御フロー分析を行う手段と
をさらに含むことを特徴とする請求項２０に記載のシステム。
【請求項２２】
前記実行コードを検出する手段は、
データフロー分析を行う手段と、
制約強化を行う手段と
をさらに含むことを特徴とする請求項２１に記載のシステム。
【請求項２３】
前記検出した実行コードからコードシグネチャを生成する手段
をさらに備えたことを特徴とする請求項１５に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータシステムのエクスプロイト（exploit）を検出することに関し、より詳細には、ネットワークフロー内のエクスプロイトコードを検出することに関する。
【背景技術】
【０００２】
（政府のライセンス所有権）
本発明は、米軍空軍研究所によって与えられたＦＡ８７５０−０４−Ｃ−０２４９の下、政府からの支援を受けて得られた。政府は、本発明に対する一定の権利を有する。
【０００３】
（関連出願）
本願は、２００４年１１月４日に出願された米国仮出願番号第６０／６２４９９６号の利益を主張する。米国仮出願番号第６０／６２４９９６号は、参照することにより本明細書に組み込まれる。
【０００４】
ネットワークコンピュータおよびコンピュータシステムに伴う重大な問題の１つとして、外部から攻撃を受けやすいことがあげられる。攻撃のタイプの１つは、ネットワークコンピュータ上で実行されているネットワークサービスにおける脆弱性の悪用である。コンピュータ上で実行されているネットワークサービスは、ネットワークポートに関連付けられており、このポートは、他のネットワークコンピュータとの接続のため、開かれたままであることがある。開いているネットワークポートを悪用するエクスプロイトコードの１つのタイプは、ワームと呼ばれる。ワームは自己増殖するエクスプロイトコードであり、一旦特定のホストコンピュータに定着すると、別のコンピュータを感染させるために、そのホストコンピュータを使用することがある。こうしたワームは、ネットワークコンピュータに重大な問題を与える。
【０００５】
コンピュータの脆弱性の源は、コンピュータを攻撃に対して無防備にする、ソフトウェアのバグまで遡れる場合がある。ソフトウェアの複雑性のため、ソフトウェアのリリースより前に全てのバグを検出して除去することはできず、従って、コンピュータを攻撃に対して脆弱なままにしておくことになる。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
コンピュータ攻撃に対抗する既知の技術がいくつか存在する。１つの手法は、エクスプロイトコードが実行され始めたときに、ワームまたは他のエクスプロイトコードのコンピュータ上での実行を検出することである。この手法は通常、何らかのエクスプロイトコードが実行を試みたとき、そのエクスプロイトコードを検出して有害なコードが実行されることを防ぐように、何らかのタイプのソフトウェアモニタが常にホストコンピュータ上で実行されていることを必要とする。別の手法として侵入検出があるが、これにも、ネットワークポートへの好ましくない侵入を検出する、何らかのタイプのモニタリングソフトウェアがホストシステム上に必要である。これらの技術の両方に共通する問題は、貴重な処理リソースや他のコンピュータリソースを不必要に使用することであり、それによって、ホストコンピュータシステムに望ましくないオーバヘッドが課されることである。
【０００７】
コンピュータ攻撃に対抗する別の手法は、ネットワークフロー内の悪意のあるエクスプロイトコードを検出することを含む。この技術に従うと、悪意のあるエクスプロイトコードを検出するために、データトラヒックが、ネットワーク自体の中で分析される。この手法の利点は、この手法が未然の防止策であり、エクスプロイトコードがホストコンピュータに到達する前に対策をとることができることである。
【０００８】
１つのタイプのネットワークフロー分析は、パターンマッチングを含むが、このパターンマッチングでは、システムが、ネットワークデータパケット内で、シグネチャと呼ばれる既知のパターンを検出しようと試みる。シグネチャに基づく検出システムは、実装すること、および、うまく機能させることが比較的容易である一方、そのセキュリティ保証（security guarantee）は、シグネチャレポジトリ（signature repository）の強固さの程度に留まる。そのようなシステムを回避するには、エクスプロイトコードが、シグネチャレポジトリ内にある全てのパターンを避けるだけでよい。このような回避は、エクスプロイトコードまたはコードシーケンスを変更すること（メタモーフィズム（metamorphism）と呼ばれる）や、エクスプロイトコードを暗号化すること（ポリモーフィズム（polymorphism）と呼ばれる）や、新たな未知の脆弱性を発見してその新たに発見された脆弱性の弱点を突くのに必要なエクスプロイトコードを作成すること（ゼロデイエクスプロイト（zero-day exploit）と呼ばれる）によって、実現することができる。原則として、シグネチャは長くしなければならないが、それは、通常のデータがエクスプロイトコードのシグネチャと偶然一致したときに発生し得る誤検出（false positive）を低減できるくらいに特有であるようにしておくためである。また、シグネチャマッチングプロセスは、演算処理面およびストレージ面で重い負担になり得るので、スケーラビリティを達成するために、シグネチャの数は少なくしておかなければならない。これらの２つの目的は、メタモーフィズムおよびポリモーフィズムによって著しく妨害され、シグネチャに基づく検出システムに重大な問題をもたらす。
【０００９】
シグネチャに基づく技術に加えて、他のネットワークフロー分析技術も利用できる。これらの技術の多くは、典型的なエクスプロイトコードが一般に３つの異なるコンポーネント、すなわち、１）リターンアドレスブロック、２）ＮＯＯＰスレッド、および、３）ペイロードから構成されているという事実に基づいている。この構造を有するエクスプロイトコードは、一般に、ホストコンピュータ内のバッファオーバフローの脆弱性を悪用するエクスプロイトのクラスを利用する。一般に、そして当該技術分野ではよく知られているように、バッファオーバフロー状態を引き起こすことによって、攻撃者は、しばしば、特定のリターンアドレスブロックにて、強制的にコードの実行をコンピュータに開始させることができる。一連のＮＯＯＰ（ノーオペレーション）命令（ＮＯＯＰスレッド）によって、結局、ペイロード内のエクスプロイトコードが実行され、その結果、ホストコンピュータは感染する。いくつかのフロー分析技術は、この既知の構造を利用して、ネットワークフローを分析し、これらの様々なコンポーネントを検出する。例えば、いくつかの先行技術は、ＮＯＯＰスレッドに着目して、ネットワークフロー内でＮＯＯＰスレッドを検出しようと試みている。例えば、２００３年１０月１６日から１８日までスイスのチューリッヒで開催された「第５回侵入検出における最近の進歩（ＲＡＩＤ：Recent Advances in Intrusion Detection）に関する国際シンポジウム」のプロシーディングの２７４ページ〜２９１ページに記載のＴ．ＴｏｔｈおよびＣ．Ｋｒｕｇｅｌによる「Accurate Buffer Overflow Detection Via Abstract Payload Execution」には、ネットワークデータをディスアセンブルして、分岐命令または無効命令によって囲まれた実行命令のシーケンスを検出する手法が記述されている。この記述では、そのようなシーケンスが長くなれば長くなるほど、ＮＯＯＰスレッドの証拠である可能性がより高いとされている。しかしながら、この検出手法の１つの問題は、通常のコードの間に分岐命令を散りばめ、その結果シーケンスを短くすることによって、この手法を無効化することができることである。
【００１０】
典型的なエクスプロイトコードの構造に基づく別の技術は、２００４年５月に韓国のソウルで開催された「第９回ＩＥＥＥ／ＩＦＩＰネットワーク運用および管理シンポジウム（ＮＯＭＳ２００４：Network Operation and Management Symposium）」のＡ．Ｐａｓｕｐｕｌａｔｉ、Ｊ．Ｃｏｉｔ、Ｋ．Ｌｅｖｉｔｔ、Ｓ．Ｗｕ、Ｓ．Ｌｉ、Ｒ．Ｋｕｏ、およびＫ．Ｆａｎによる「Buttercup: On Network-Based Detection of Polymorphic Buffer Overflow Vulnerabilities」に記述されている。この論文には、リターンアドレスコンポーネントを候補バッファアドレス（candidate buffer addresses）と照合することによって、リターンアドレスコンポーネントを検出する手法が記述されている。この手法の１つの問題は、リターンアドレスコンポーネントが非常に小さい場合もあるということであり、従って、シグネチャとして使用されたときに、リターンアドレスコンポーネントが十分なほどに特有ではないため、誤検出が多すぎる結果となる場合があるということである。加えて、ソフトウェアのわずかな変更でさえ、メモリ内のバッファアドレスを変更する可能性が高く、それによって、シグネチャリストの頻繁な更新と、多量の管理オーバヘッドとが必要になる。
【００１１】
典型的なエクスプロイトコードの構造に基づくさらに別の技術が、２００４年９月１５日から１７日までフランスで開催された「第７回侵入検出における最近の進歩（ＲＡＩＤ）に関する国際シンポジウム」のプロシーディングの２０３ページ〜２２２ページに記載のＫ．ＷａｎｇおよびＳ．Ｊ．Ｓｔｏｌｆｏによる「Anomalous Payload-Based Network Intrusion Detection」に記述されている。この記述では、まず通常のネットワークフロートラヒックを用いて準備し（train）、続いて、いくつかのバイトレベルの統計的手法を用いてエクスプロイトコードを検出することによって機能する、ペイロードに基づく異常検出システムが提案されている。この手法の１つの問題は、エクスプロイトコードが統計的に通常のトラヒックを模倣するような方法でエクスプロイトコードを実装することによって、検出を回避することができることである。
【課題を解決するための手段】
【００１２】
本発明は、ネットワークフロー内のエクスプロイトコードを検出する方法および装置を提供する。
【００１３】
一実施形態において、ネットワークデータパケットは、フローモニタによってインターセプトされ、フローモニタは、インターセプトされたデータパケットからデータフローを生成する。コンテンツフィルタは、データフローの少なくとも一部分をフィルタリングし、フィルタリングされていない部分は、コードレコグナイザ（code recognizer）に提供される。コードレコグナイザは、データフローのフィルタリングされていない部分の中の実行コードを検出する。コンテンツフィルタは、データフロー内の正規のプログラムをフィルタリングし、コードレコグナイザに提供されるフィルタリングされていない部分には実行コードが組み込まれていないと想定されるようにする。フィルタリングされていないデータフロー部分の中に組み込まれている実行コードは、ネットワークフロー内のエクスプロイトである疑いがある。従って、データフローのフィルタリングされていない部分の中の実行コードを認識することによって、本発明に従うエクスプロイトディテクタ（exploit detector）は、ネットワークフロー内のエクスプロイトコード候補（potential exploit code）を識別することができる。
【００１４】
一実施形態において、実行コードレコグナイザ（executable code recognizer）は、データフローのフィルタリングされていない部分に対してコンバージェント・バイナリ・ディスアセンブリ（convergent binary disassembly）を行うことによって、実行コードを認識する。次いで、実行コードレコグナイザは、実行コードを検出するために、制御フローグラフを作成して、制御フロー分析とデータフロー分析と制約強化（constraint enforcement）とを行う。検出した実行コードをエクスプロイト候補として識別することに加えて、その後、検出した実行コードは、エクスプロイトを検出する際に他のシステムによって使用されるように、エクスプロイト候補のシグネチャを生成するために利用することもできる。
【発明を実施するための最良の形態】
【００１５】
本発明の上記の利点およびその他の利点は、以下の詳細な説明と添付の図面とを参照すれば、当業者には明らかであろう。
【００１６】
図１は、本発明の一実施形態による、ネットワークフロー内のエクスプロイトコードを検出するためのシステムを示している。図１は、フローモニタ１０４、コンテンツフィルタ１０６、コードレコグナイザ１０８、および悪意プログラムアナライザ（malicious program analyzer）１１０を備えたエクスプロイトディテクタ１０２を示している。また、図１は、３つのホストコンピュータ１１２、１１４、１１６にそれぞれ関連付けられた３つのネットワークフロー１１８、１２０、１２２を示している。エクスプロイトコードがネットワークフロー内にどのように組み込まれるかを例示するために、フロー１２２はワームコード１２４を含むものとして示されている。図１は、ホストへの着信フローとして３つのネットワークフローを示しているが、当業者であれば、本発明は、着信フローだけでなく発信フローも分析するのに使用できることが容易に理解されよう。ここでは、簡潔にするために、着信フローだけを示している。
【００１７】
図１は、本発明の一実施形態によるエクスプロイトディテクタ１０２の高レベルの機能ブロック図を示していることに留意されたい。エクスプロイトディテクタ１０２のコンポーネントは機能ブロックとして示されており、そのコンポーネントの各々が処理の一部分を実行する。エクスプロイトディテクタ１０２は、適切にプログラムされたコンピュータを用いて実装することができる。そのようなコンピュータは、当該技術分野では周知であり、例えば、周知のコンピュータプロセッサ、メモリユニット、ストレージデバイス、コンピュータソフトウェア、および、その他のコンポーネント群を用いて実装することができる。そのようなコンピュータの高レベルのブロック図を図２に示す。コンピュータ２０２はプロセッサ２０４を含んでおり、プロセッサ２０４は、コンピュータ２０２の全般的な動作を定義するコンピュータプログラム命令を実行することによって、コンピュータ２０２のそのような動作を制御する。コンピュータプログラム命令は、ストレージデバイス２１２（例えば、磁気ディスク）に格納することができ、コンピュータプログラム命令の実行が望まれるときに、メモリ２１０にロードすることができる。このようにして、コンピュータ２０２によって実行されるステップは、メモリ２１０および／またはストレージ２１２に格納されたコンピュータプログラム命令によって定義され、プロセッサ２０４によって実行されることになる。また、コンピュータ２０２は、ネットワークを介して他のデバイスと通信するための、１つまたは複数のネットワークインターフェース２０６を含んでいる。コンピュータ２０２は、入出力デバイス２０８も含んでおり、入出力デバイス２０８は、ユーザがコンピュータ２０２との対話を可能にするデバイス（例えば、ディスプレイ、キーボード、マウス、スピーカ、ボタンなど）を表している。当業者であれば、実際のコンピュータの実装には他のコンポーネント群も含まれること、および、図２は、例示の目的上、そのようなコンピュータのコンポーネント群の一部を高レベルで表していることが理解されよう。図１を参照すると、機能ブロックの各々は、例えば、必要に応じてプロセッサ２０４によって実行される様々なソフトウェアモジュールにより実装することができる。様々な実施形態において、エクスプロイトディテクタ１０２の各種の機能は、ハードウェア、ソフトウェア、およびハードウェアとソフトウェアとの様々な組合せによって実行することができる。
【００１８】
図１に戻ると、フローモニタ１０４は、ネットワークフロー１１２、１１４、１１６からのデータパケットをインターセプトし、ネットワークフロー内にある様々なデータフローを再構成する。本明細書で用いられるネットワークフローという用語は、特定のタイプのデータやエンドポイント間の特定の接続を指すものではなく、様々なネットワークデバイス間を流れる全てのネットワークトラヒックに対応する。データフローという用語は、２つのエンドポイント間の特定の接続に関連付けられたデータパケットに対応する。ネットワークフローは、一方向でもよいし、双方向でもよく、どちらの方向も、悪意のある実行コード（例えば、ワーム）を含む可能性がある。一実施形態において、フローモニタ１０４は、ｔｃｐｆｌｏｗを用いて実装することができる。ｔｃｐｆｌｏｗは、既知のソフトウェアユーティリティであり、ネットワークフローを捕捉して、そのネットワークパケットを実際のデータフローに対応するように再構成するものである。伝送制御プロトコル（ＴＣＰ）データフローは、非常に容易に再構成することができる。というのは、ＴＣＰプロトコルは、データ配信を保証し、また、パケットが送信された順序と同じ順序で配信されることを保証するからである。ユーザ・データグラム・プロトコル（ＵＤＰ）データフローは、それほど容易に再構成することができない。というのは、ＵＤＰは、コネクションレスプロトコルであり、信頼できる通信を保証しないからである。順序がばらばらな状態でＵＤＰパケットが到達すると、（以下で説明するように、）データフローを分析しても、組み込まれた悪意のあるエクスプロイトコードをまったく識別することができない。しかしながら、ＵＤＰパケットがエクスプロイトコードの作成者の意図と違う順序で到達した場合には、ホストコンピュータへの感染がうまくいく可能性が低いため、これは重大な問題ではない。フローモニタ１０４によって再構成されたデータフローは、さらなる処理のため、コンテンツフィルタ１０６に送信される。
【００１９】
以下で詳述するように、コードレコグナイザ１０８は、ネットワークフロー内の実行コードを認識することによって、エクスプロイトコード候補を識別する。しかしながら、一部のネットワークフローは、（以下で説明するように、）コードレコグナイザ１０８のテストに通る正規のプログラムを含む場合があり、従って、エクスプロイトコード候補の誤検出をもたらす場合がある。従って、プログラムのようなコード（program-like code）と正規のプログラムとの区別を追加して行うことが必要となる。コンテンツフィルタ１０６は、コンテンツがコードレコグナイザ１０８に到達する前に、コンテンツをフィルタリングする。一実施形態において、コンテンツフィルタ１０６は、正規のプログラムであると識別され得るプログラムコードをフィルタリングする。従って、どのサービスおよびどの関連データフローが実行コードを含んでいるか否かを特定することが必要となる。この情報は、３−タプル（ｐ，ｒ，ｖ）として表される。ここで、ｐは、サービスの標準ポート番号であり、ｒは、データのみ（ｄと表示される）の場合と、データおよび実行ファイル（ｄｘと表示される）の場合とがあり得るネットワークフローコンテンツのタイプであり、ｖは、着信（ｉと表示される）または発信（ｏと表示される）のどちらかであるフローの方向である。例えば、（ｆｔｐ，ｄ，ｉ）は、ｆｔｐポートを介する、データのみのコンテンツタイプを有する着信フローを表している。さらに詳細なルールが、ホストごとに基づいて規定されてもよい。しかしながら、数百台ものホストを有する大規模な組織では、このようなタプルの数は、非常に多くの数になり得る。それではシステム管理者に大きな負担を与えてしまうため、詳細なルールは望ましくない。ルールが規定されない場合、ほとんどのネットワークフローはデータのみを伝送するので、利便性の目的上、デフォルトでは、データのみのネットワークフローコンテンツが想定される。
【００２０】
図３において、コンテンツフィルタのフィルタリング機能について例示する。図３は、２つのタイプのデータフローを受信しているコンテンツフィルタ３０２を示している。データのみのフロー３０４と、データおよび実行ファイルのフロー３０６とが示されている。３−タプル・ルールにより、フロー３０６のようなデータおよび実行ファイルのフローであるデータフローが特定された場合、コンテンツフィルタ３０２は、そのフローが正規のプログラムを含んでいるか否かを判定しなければならない。フローが正規のプログラムを含んでいる場合、正規のプログラムコンテンツ３０８は、フィルタリングされ、（以下で詳述する）悪意プログラムアナライザに提供される。コンテンツが正規のプログラムでない場合、コンテンツ３１０は、さらなる分析のために、コードレコグナイザに送信される。３−タプル・ルールにより、フロー３０４のようなデータのみのフローが特定された場合、フローは、正規のプログラムを含まないと想定されるので、さらなる分析のために、コードレコグナイザに送信される。
【００２１】
正規のプログラムコンテンツ３０８に関して、一実施形態においては、コンテンツフィルタ１０６は、Ｌｉｎｕｘ（登録商標；以降同じ）およびＭｉｃｒｏｓｏｆｔ（登録商標；以降同じ）  Ｗｉｎｄｏｗｓ（登録商標；以降同じ）の実行プログラムを正規のプログラムコンテンツとして識別するように構成されている。通常、フロー内でプログラムが発生することはまれであり、一般には、プログラムの発生は、インターネットからのサードパーティソフトウェアのダウンロードに起因するものと考えられる（ただし、ピア・ツー・ピアのファイル共有ネットワークでは、プログラムの発生がもっと多くなり得るであろう）。ＬｉｎｕｘプラットフォームおよびＷｉｎｄｏｗｓプラットフォーム向けのプログラムは一般に、標準の実行フォーマットに従う。Ｌｉｎｕｘプログラムは一般に、１９９５年に公開された、ＴＩＳ（Tool Interface Standard）、ＥＬＦ（Executable and Linking Format）仕様、バージョン１．２に記述されている、周知のＥＬＦに従う。Ｗｉｎｄｏｗｓプログラムは一般に、１９９９年に公開された、Ｍｉｃｒｏｓｏｆｔ  Ｐｏｒｔａｂｌｅ  Ｅｘｅｃｕｔａｂｌｅ  ａｎｄ  Ｃｏｍｍｏｎ  Ｏｂｊｅｃｔ  Ｆｉｌｅ  Ｆｏｒｍａｔ仕様、改訂版６．０に記述されている、周知のＰＥ（Portable Executable）フォーマットに従う。
【００２２】
Ｌｉｎｕｘ  ＥＬＦ実行ファイルを検出するプロセスについては、本明細書において以下で説明する。Ｗｉｎｄｏｗｓ  ＰＥ実行ファイルを検出するプロセスも同様であり、当業者であれば、本明細書の説明から、容易に実装することができるであろう。コンテンツフィルタ１０６は、「ＥＬＦ」という文字群、または、同等なものとして、連続バイト４５４Ｃ４６（１６進数）を探すために、フローモニタ１０４から受信したネットワークフローをスキャンする。このバイトシーケンスは通常、正当なＥＬＦ実行ファイルの開始の印となるものである。次に、コンテンツフィルタ１０６は、正規のプログラムの以下のような指標を探す。
【００２３】
正規のプログラムの指標の１つは、ＥＬＦヘッダである。ＥＬＦヘッダは、プログラム全体のレイアウトを記述する情報を含むが、コンテンツフィルタ１０６の目的からすると、所定のフィールドしか必要ではない。一実施形態において、次のフィールドがチェックされる。１）ｅ＿ｉｄｅｎｔフィールドは正規のマシン独立型の情報（legitimate machine independent information）を含まなければならない、２）ｅ＿ｍａｃｈｉｎｅフィールドはＥＭ＿３８６を含まなければならない、３）ｅ＿ｖｅｒｓｉｏｎフィールドは正規のバージョンを含まなければならない。ヘッダに関して、Ｗｉｎｄｏｗｓ  ＰＥヘッダのフォーマットは、ＥＬＦヘッダに非常に類似しており、Ｗｉｎｄｏｗｓヘッダに対して同様のチェックを実行することができることに留意されたい。Ｗｉｎｄｏｗｓ  ＰＥ実行ファイルは、レガシーなＤＯＳ（登録商標）ヘッダで始まる。このＤＯＳヘッダは、注目すべき２つのフィールド、すなわち、ｅ＿ｍａｇｉｃとｅ＿ｌｆａｎｅｗとを含んでいる。ｅ＿ｍａｇｉｃは、文字群「ＭＺ」、または、同等のものとして、バイト５Ａ４Ｄ（１６進数）でなければならず、ｅ＿ｌｆａｎｅｗは、ＰＥヘッダのオフセットである。正規のプログラムを識別するには、一般にＥＬＦヘッダの分析で十分であるが、以下のチェックを行うことによって、さらに確認することができる。
【００２４】
別の正規のプログラムの指標として、ダイナミック・セグメントがある。ＥＬＦヘッダを用いることにより、プログラムヘッダのオフセットとダイナミック・セグメントのオフセットとが判定される。ダイナミック・セグメントが存在する場合、実行ファイルは、ダイナミック・リンケージを用いることになり、セグメントは、ｌｉｂｃ．ｓｏ．６のような正規の外部共用ライブラリの名前を含まなければならない。ダイナミック・セグメント・フィールド内に正規の外部共用ライブラリの名前があれば、それは正規のプログラムのさらなる証拠である。
【００２５】
その他の正規のプログラムの指標は、シンボルテーブルおよびストリングテーブルである。この場合も、ＥＬＦヘッダを用いることにより、シンボルテーブルおよびストリングテーブルのオフセットが判定される。正規のプログラムにおいては、ストリングテーブルは、印刷可能な（printable）文字群のみを含む。また、正規のプログラム内のシンボルテーブルのエントリは、ストリングテーブルへの有効なオフセットを示す。
【００２６】
通常のネットワークデータが正規のプログラムの上述した証拠を全て含むということは、非常に可能性が低い。従って、全ての指標が満たされた場合には、正規の実行プログラムが発見されたと判定することは合理的である。上述した証拠の様々な組合せおよび他の証拠が、具体的な実施形態に応じて使用されてもよいことは言うまでもない。再度図３を参照すると、正規のプログラムコンテンツがコンテンツフィルタ３０２によって発見された場合、その正規のプログラムコンテンツは、悪意プログラムアナライザ１１０に送信される。以上、本明細書で、正規のＬｉｎｕｘプログラムおよびＷｉｎｄｏｗｓプログラムを識別するためのデータフローの具体的な分析について述べてきた。当業者であれば、データフロー内の正規のプログラムを識別するために、上記以外にも様々なテストを実施できることが理解されよう。
【００２７】
プログラムがたとえ正規のＷｉｎｄｏｗｓプログラムまたはＬｉｎｕｘプログラムであっても、そのプログラムが悪意なものであるか否かを判定するために、そのプログラムを分析するよう、そのプログラムが悪意プログラムアナライザ１１０に提供されてもよい。例えば、悪意プログラムアナライザ１１０は、当該技術分野では周知のウィルス対策ソフトウェアとすることができる。悪意プログラムアナライザ１１０の使用は任意であり、様々なタイプのそのようなプログラムは、当該技術分野では周知であるので、そのような悪意プログラムアナライザ１１０の詳細については本明細書では説明しないが、そのような悪意プログラムアナライザ１１０は、エクスプロイトディテクタ１０２と併せて使用することができる。
【００２８】
図３に示すように、データおよび実行ファイルのフロー３０６内に含まれるコンテンツであって、正規のプログラム３０８としてフィルタリングされないコンテンツは、コンテンツ３１０としてコードレコグナイザに送信される。データのみのフロー３０４内に含まれるコンテンツもまた、コードレコグナイザに送信される。この時点では、実行コードを含んでいてコードレコグナイザに送信されるいかなるコンテンツもエクスプロイトコード候補であり、そういうものとして識別される必要がある。このようにして、コンテンツはコードレコグナイザ１０８に送信され、コードレコグナイザ１０８は、以下のように、受信したコンテンツを分析して、その受信したコンテンツが実行コードセグメントを含むか否かを判定する。
【００２９】
バイナリプログラムの静的分析は通常、ディスアセンブリで始まり、続いてデータフロー分析および制御フロー分析が行われる。一般に、静的分析の実効性は、実行ストリーム（execution stream）がいかに正確に再構成されるか（すなわち、ディスアセンブルされるか）に大きく依存する。しかしながら、コードレコグナイザ１０８は、ネットワークフローが実行コードフラグメントを含んでいるかどうか分からないため、また、ネットワークフローが実行コードフラグメントを含んでいると分かったとしても、このようなコードフラグメントがデータストリーム内のどこにあるのか分からないため、ディスアセンブリは重大な問題であるということが分かる。次に、コンバージェント・バイナリ・ディスアセンブリと呼ばれる有効なディスアセンブリ技術について説明する。これは、静的分析を高速化するのに有効である。
【００３０】
Ｉｎｔｅｌ（登録商標；以降同じ）プロセッサに基づくコードのバイナリ・ディスアセンブリの特性として、わずかな命令の損失はあるものの、同一の命令ストリームに収束する（converge）傾向があるということがあげられる。バイトストリームが本質的にはデータであるにもかかわらず、また、ディスアセンブリが行われるときには別々のオフセットにて始まるにもかかわらず、収束（convergence）が生じるように見えるので、これは注目すべきことである。図４Ａに示すバイトストリームについてみると、このバイトストリームは、ランダムなプリアンブルから構成され、その後にＮＯＰ（０ｘ９０）命令であるＮＯＯＰスレッドが続く。バイトストリームは、オフセット０、１、２、および３を開始点としてディスアセンブルされ、そのディスアセンブリの出力が、図４Ｂ、図４Ｃ、図４Ｄ、および図４Ｅにそれぞれ示されている。これらの図は、データストリームをＩｎｔｅｌバイナリコードとして解釈する３つの側面を示している。第１に、ほとんど全てのデータバイトは、正当なＩｎｔｅｌ命令にディスアセンブルされる。第２に、全てのディスアセンブリストリームは、オフセットおよび先行する不要なデータに関わらず、急速にＮＯＯＰスレッドに収束する。第３に、ＮＯＯＰスレッドからの若干の命令が失われるが、それにも関わらず、収束が生じる。
【００３１】
収束現象は、Ｉｎｔｅｌの命令セットの性質によって説明することができる。Ｉｎｔｅｌは、複雑な命令セットのコンピュータアーキテクチャを使用しているため、その命令セットは非常に密度が高い。ディスアセンブルを開始する所与の開始バイトとして可能な２５６個の値のうち、１つだけ（０ｘＦ１）が不正なものである。急速な収束についての別の関連する側面は、Ｉｎｔｅｌが可変長の命令セットを使用していることである。図５は、ＩＡ−３２アーキテクチャ向けの一般的な命令フォーマットの概要を示している。実際の復号された命令の長さは、１〜３バイトの長さであり得るオプコードだけでなく、適用可能であれば、プレフィックス、ＭｏｄＲ／ＭバイトおよびＳＩＢバイトによって与えられる指示にも依存する。また、全ての開始バイトがディスアセンブリの成功をもたらすわけではなく、そのような場合、それらは、図４Ｃおよび図４Ｄのオフセット０ｘ０００００００６にて示されるように、データバイトとして復号されることに留意されたい。
【００３２】
収束現象のより正式な数学的分析を以下に示す。バイトストリームに対して、実際のエクスプロイトコードが、何らかのオフセットｘ＝０，１，２，．．．にて組み込まれていると仮定する。理想的には、命令ストリームを復元するためのバイナリ・ディスアセンブリは、ｘにて始まるか、または、少なくともｘにて一致する必要がある。しかしながら、出願人らはｘを知らないので、バイトストリーム内の最初のバイトから開始する。出願人らは、ｘの後どれくらいでディスアセンブリがエクスプロイトコードの実際の命令ストリームと一致するのかを知ることに関心がある。
【００３３】
この疑問に答えるために、ディスアセンブリのプロセスを、バイトストリーム全体にわたるランダムウォークとしてモデル化する。このプロセスのモデルでは、各バイトが状態スペースにおける１個の状態に対応する。ディスアセンブリは、厳密に前方に進むランダムウォークであって、各ステップのサイズは、所与のバイトにて復号された命令の長さによって与えられる。２つのランダムウォークが存在し、一方は出願人らのディスアセンブリに対応し、他方は実際の命令ストリームに対応する。両方のランダムウォークが同時に進む必要はないし、両方のランダムウォークが一致するポイントに到達するのに同数のステップを取る必要もないことに留意されたい。
【００３４】
数学的用語に翻訳すると、Ｌ＝｛１，．．．．．，Ｎ｝は、確率｛ｐ1，．．．．．，ｐN｝で生じる、考えられ得るステップのサイズまたは命令の長さの集合とする。第１のウォークについては、ステップのサイズを
【００３５】
【数１】
2008519374.tif 000003
【００３６】
とし、
【００３７】
【数２】
2008519374.tif 000004
【００３８】
と定義する。
【００３９】
同様に、第２のウォークについては、ステップのサイズを
【００４０】
【数３】
2008519374.tif 000005
【００４１】
とし、
【００４２】
【数４】
2008519374.tif 000006
【００４３】
とする。
【００４４】
出願人らは、ランダムウォーク｛Ｚk｝と、
【００４５】
【数５】
2008519374.tif 000007
【００４６】
とが交差する確率を発見することに関心があり、もし交差するのであるならば、どのバイト位置で交差するかということに関心がある。
【００４７】
これを行う１つの方法は、次のように定義される「ギャップ（gap）」を詳しく調べることである。ここで、Ｇ0＝０、
【００４８】
【数６】
2008519374.tif 000008
【００４９】
とする。
【００５０】
【数７】
2008519374.tif 000009
【００５１】
ならば、Ｇ1＝０となり、この場合、両ウォークは１ステップ後に交差する。Ｇ1＞０の場合、一般性を失うことなく、
【００５２】
【数８】
2008519374.tif 000010
【００５３】
と仮定する。出願人らのアプリケーションの観点からすると、｛Ｚk｝は出願人らのディスアセンブリに対応するウォークであり、
【００５４】
【数９】
2008519374.tif 000011
【００５５】
は実際の命令ストリームである。
【００５６】
【数１０】
2008519374.tif 000012
【００５７】
であり、
【００５８】
【数１１】
2008519374.tif 000013
【００５９】
であると定義する。一般に、Ｚと、
【００６０】
【数１２】
2008519374.tif 000014
【００６１】
とは、各「ギャップ」変数Ｇnの定義において、「先行部（leader）」と「遅行部（laggard）」との役割を交代する。｛Ｇn｝はマルコフ連鎖を形成する。マルコフ連鎖を単純化できない場合、ランダムウォークは正の確率（positive probability）で交差し、実際、第１回目では、ギャップのサイズは０である。ここで、
Ｔ＝ｉｎｆ｛ｎ＞０：Ｇn＝０｝
を両方のウォークが交差する最初の時間であるとする。この交差が生じるプログラムブロック内のバイト位置は、以下の式により与えられる。
【００６２】
【数１３】
2008519374.tif 000015
【００６３】
一般に、出願人らには、プログラムブロック内の出願人らの開始位置であるＺ1は分からない。というのは、出願人らは、プログラムのエントリポイントを知らないからである。従って、出願人らは、一致が生じるディスアセンブリ開始ポイント後のバイト位置の数を表す量である、
【００６４】
【数１４】
2008519374.tif 000016
【００６５】
について、大いに関心がある。分配（partition）と多項分布とを用いて、
ｉ，ｊ∈｛０，１，．．．，Ｎ−１｝の各々について、
推移確率の行列ｐn（ｉ，ｊ）＝Ｐ（Ｇn+1＝ｊ｜Ｇn＝ｉ）を計算することができる。実際、ｐn（ｉ，ｊ）＝ｐ（ｉ，ｊ）は、ｎに依存しない、すなわち、マルコフ連鎖は一様である。この行列によって、例えば、２つのランダムウォークが、ディスアセンブリの開始後、ｎの位置で交差する確率を計算することができる。
【００６６】
上記の計算に必要な命令の長さの確率｛ｐ1，．．．，ｐN｝は、ネットワークフローのバイトコンテンツに依存する。命令の長さの確率は、実証的分析の間に選択された同じネットワークフロー（ＨＴＴＰ、ＳＳＨ、ＸＩＩ、ＣＩＦＳ）に対するディスアセンブリと統計的計算とによって得られた。図７において、ディスアセンブリ開始後、ｎバイトを過ぎて交差（一致）が生じる確率
【００６７】
【数１５】
2008519374.tif 000017
【００６８】
を、ｎ＝０，．．．，９９についてプロットした。
【００６９】
この確率は急に低下することが明らかであり、実際、ディスアセンブリ開始後、それぞれ２１番目（ＨＴＴＰ）、１６番目（ＳＳＨ）、１５番目（ＸＩＩ）、および１６番目（ＣＩＦＳ）のバイトの位置、または、それらより前の位置で、ディスアセンブリ「ウォーク」と「プログラムウォーク」とが、確率０．９５で交差する。平均すると、両ウォークは、それぞれわずか６．３バイト（ＨＴＴＰ）、４．５バイト（ＳＳＨ）、３．２バイト（ＸＩＩ）、および４．３バイト（ＣＩＦＳ）後に交差することになる。
【００７０】
セキュリティの観点から、静的分析は、プログラムコードの脆弱性と、それに関連したソフトウェアのバグとを発見するのに使用されることが多い。静的分析はまた、所与のプログラムが悪意のあるコードを含んでいるか否かを判定するためにも使用される。しかしながら、コード難読化技術およびエイリアシングの論証不能性のため、合理的な期限内に正確な静的分析を行うのは、非常に難しい問題である。一方では、表面的な静的分析は効率的であるが対象範囲が狭くなることがあり、他方では、高精度を追求すると、通常、非常に処理時間がかかる結果になりやすい。一般論として、出願人らの手法は、ネットワークフローに対して静的分析を用いるのであり、オンラインネットワークベースの実装を実現するためには、効率性が重要な設計目標となる。通常であれば、これは精度の悪さをもたらすことがあるが、出願人らの手法は、除外プロセスを工夫するためだけに静的分析を用いるのであり、この手法は、エクスプロイトコードが、エクスプロイトコードのサイズと制御フローとの点で、いくつかの制約を受けるという前提に基づいている。これらの制約は、その後、バイトストリームがデータであるか、または、プログラムのようなコードであるかを判定するのに役立つように用いられる。
【００７１】
復元され得る情報量に応じて、静的分析の観点から、エクスプロイトコードには２つの大きなカテゴリがある。第１のカテゴリは、既知のエクスプロイト、ゼロデイエクスプロイト、およびメタモーフィック（metamorphic）エクスプロイトなどの、露出されて送信されるタイプのエクスプロイトコードを含む。第２のカテゴリは、露出は最小限に抑えられるが、それでも制御フローの何らかの兆候を含むエクスプロイトコードを含む。ポリモーフィック（polymorphic）コードは、この第２のカテゴリに属する。この基本的な違いのため、出願人らは、ポリモーフィックエクスプロイトに対して、基本的な方法はやはり静的分析に基づいてはいるが、除去プロセスをいくらか異なる手法で行う。ポリモーフィズムおよびメタモーフィズムの両方が使用されている場合には、前者の方が主要な（dominant）難読化であることに留意されたい。次に、バイナリ・ディスアセンブリから始まる、出願人らの手法の詳細に移る。
【００７２】
ここで、コードレコグナイザ１０８の機能の詳細について、図８と関連させて説明する。図８は、コードレコグナイザ１０８によって実行されるステップの、高レベルのフローチャートを示している。第１ステップ８０２は、上述したように、データフローコンテンツのコンバージェント・バイナリ・ディスアセンブリである。しかしながら、収束に完全に頼ることには注意が必要である。第１に、この技術には損失が多い。ＮＯＯＰスレッドに関する命令の損失は、それほど深刻ではないが、エクスプロイトコード内にある命令の損失は、深刻なものとなり得る。コードからできるだけ多くの分岐命令を復元することが望ましいが、これは多量の処理オーバヘッドを要する。従って、効率性か、または精度のどちらを重視するかに応じて、２つのディスアセンブリの方法を使用することができる。第１の方法は効率的であり、その方法は、追加の処理を何もせずに、最初のバイトから始めてバイナリ・ディスアセンブリを実行することである。上述した収束特性によって、分岐命令を含む少なくとも過半数の命令が復元されることが確実になる。しかしながら、この方法はデータインジェクション（data injection）に対する抵抗性は低い。データインジェクションとは、正当な命令の間にランダムなデータを意図的に挿入することによって、正確な命令ディスアセンブリを回避するのに用いられる手法である。第２の方法は精度を重視する。この方法を用いることにより、分岐命令に対応するオプコードを探すために、ネットワークフローがスキャンされ、これらの命令が最初に復元される。次いで、結果として生じるより小さなブロックに対して、完全なディスアセンブリが実行される。その結果、いかなる分岐命令も失われない。この方法は比較的時間がかかる。その原因は、ネットワークフローに対する追加のパスだけでなく、識別される可能性のある基本ブロックの数にもある。結果として生じるオーバヘッドは、ネットワークフローコンテンツによっては、かなりの量になり得る。例えば、ＨＴＴＰトラヒックなどのＡＳＣＩＩテキストを伝送するネットワークフローに関しては、多量のオーバヘッドが予想され得る。というのは、条件分岐命令にも、例えば「ｔ」および「ｕ」のような印刷可能な文字がいくつかあり、バイナリ・ディスアセンブリは、それらをそれぞれ、「等しければ分岐（ｊｅ：jump on equal）」および「等しくなければ分岐（ｊｎｅ：jump on not equal）」と解釈するからである。ディスアセンブリ技術の選択は、具体的な実装に依存することになる。
【００７３】
バイナリ・ディスアセンブリの後、コードレコグナイザ１０８は、制御フロー分析およびデータフロー分析を行う。まず、ステップ８０４において、コードレコグナイザ１０８は、制御フローグラフ（ＣＦＧ：Control flow graph）を作成する。基本ブロックは、ブロックの先頭（block leader）を介して識別されるが、それによれば、最初の命令はブロックの先頭であり、分岐命令のターゲットはブロックの先頭であり、そして、分岐命令に続く命令もまたブロックの先頭である。基本ブロックは、本質的に命令のシーケンスであり、制御フローは、最初の命令にて入り、最後の命令を介して出て行くようになっている。各ブロックの先頭についてみると、その基本ブロックは、そのブロックの先頭と次のブロックの先頭までの全てのステートメントとから構成されるが、次のブロックの先頭は含まれない。各基本ブロックは、３つの状態のうちの１つと関連付けられる。ブロックの終わりにある分岐命令が有効な分岐ターゲットを有する場合には、基本ブロックは有効な状態と関連付けられる。ブロックの終わりにある分岐ターゲットが無効な分岐ターゲットを有する場合には、基本ブロックは無効な状態と関連付けられる。ブロックの終わりにある分岐ターゲットが未知である場合には、基本ブロックは未知の状態と関連付けられる。この情報は、ＣＦＧの余分な部分を除去するのに役立つ。ＣＦＧにおける各頂点（node）は基本ブロックであり、向きが付けられた辺（edge）は各々、見込まれる制御フローを示す。制御述語情報（control predicate information）（すなわち、条件分岐の出力辺における真または偽）は無視される。しかしながら、無効とタグ付けされた各基本ブロックについては、そのブロックは、いかなる実行パスにおいても出現できないので、全ての入力辺および出力辺が除去される。また、いかなるブロックについても、出力辺が１つしかなく、かつ、その出力辺が無効なブロックに入る場合には、そのブロックも無効であるとみなされる。全てのブロックが処理されると、必要とされるＣＦＧが判明する。
【００７４】
典型的なＣＦＧインスタンスの部分図を図６に６０２として示している。典型的なＣＦＧでは、無効なブロックが、大多数のブロックを形成し、それら無効なブロックは、さらなる分析から除外される。ステップ８０４で制御フローグラフを作成した後、コードレコグナイザ１０８は、静的分析用に問題のサイズを低減させるために、ステップ８０６で制御フロー分析を実行する。ＣＦＧ内の残りのブロックは、１つまたは複数のばらばらの連鎖（または、サブグラフ）を形成することができ、今度は、その各々が１つまたは複数のブロックから構成される。図６のＣＦＧ６０２において、ブロック６０４およびブロック６１２は無効であり、ブロック６０６は有効であって、有効なライブラリコールで終了する。ブロック６０８およびブロック６１０は連鎖を形成しているが、ブロック６１０における分岐命令のターゲットは未知である。ＣＦＧ６０２は一意な入口頂点および出口頂点を有しておらず、各連鎖は別々に分析されることに留意されたい。
【００７５】
ステップ８０８において、プログラムスライシングに基づくデータフロー分析を用いて、除去プロセスを継続する。プログラムスライシングとは、特定の演算に関連するプログラムの部分だけを抽出する分解技術である。出願人らは、１９８１年に米国カリフォルニア州サンディエゴで開催された第５回ソフトウェアエンジニアリング国際会議のプロシーディングの４３９ページ〜４４９ページに記載された、Ｍａｒｋ  Ｗｅｉｓｅｒによる「Program Slicing」に記述された後方静的スライシング技術手法（backward static slicing technique approach）を用いている。このプロシーディングは、参照することにより本明細書に組み込まれる。この手法は、スライシングアルゴリズムの中間表示として、制御フローグラフを用いる。このアルゴリズムは、実行時間計算量（running time complexity）Ｏ（ｖ×ｎ×ｅ）を有している。ここで、ｖ、ｎ、ｅはそれぞれ、ＣＦＧ内の変数の数、頂点の数、辺の数である。Ｉｎｔｅｌプラットフォームには固定数のレジスタしかなく、かつ、典型的なＣＦＧ内の頂点および辺の数はほぼ同じであると仮定すると、実行時間はＯ（ｎ2）である。プログラム依存グラフ（ＰＤＧ：Program Dependence Graph）やシステム依存グラフ（ＳＤＧ：System Dependence Graph）などの様々な表現を用いて、グラフの到達可能性に基づく分析を実行するその他の手法もある。このようなアルゴリズムには追加の表現のオーバヘッドが伴うが、精度が最重要である場合には、このようなアルゴリズムの方が適切である。
【００７６】
一般に、削減されたＣＦＧ内のどの連鎖であっても、当てはまる特性は少ない。連鎖における最後のブロック以外のブロックは全て、ネットワークフローに対するオフセットである分岐ターゲットを有しており、その後続ブロック（successor block）を指示する。連鎖における最後のブロックについては、以下のようなケースで、データのみを含むフローと実行エクスプロイトコード候補を含むフローとを区別する除去プロセスが講じられる。
【００７７】
第１のケースは、明らかなライブラリコールのケースである。連鎖における最後の命令が分岐命令、特にｃａｌｌ／ｊｍｐで終わるが、明らかなターゲット（即値アドレス指定／絶対アドレス指定）を有する場合、そのターゲットはライブラリコールアドレスでなければならない。即値分岐ターゲットを有する有効な分岐命令が他にあるならば、その分岐命令は、連鎖においてもっと早く出現して、次の有効なブロックを指示するであろう。対応する連鎖は、スタックがライブラリコールより前の矛盾のない状態にある場合にのみ実行することができるので、出願人らは、最後の分岐命令より前にプッシュ命令があることを予想する。コードレコグナイザは、スライシング基準＜ｓ，ｖ＞を用いてプログラムスライスを計算する。ここで、ｓはプッシュ命令のステートメント番号であり、ｖはそのオペランドである。出願人らは、命令の中で用いられる以前にｖが定義されると予想する。このような条件が満たされ、かつ、ライブラリコールが疑わしいものである場合には、警告が発せられる。また、最後の分岐命令およびプログラムスライスに対応するバイトシーケンスは、（以下でさらに詳述するように）シグネチャに変換される。
【００７８】
第２のケースは、明らかな割り込みのケースである。これは、分岐命令が明らかな分岐ターゲットを有する別のケースであり、その分岐ターゲットは有効な割り込み番号でなければならない。すなわち、割り込みの前に、レジスタｅａｘは有意義な値に設定される。ｉｎｔ命令から後方に動作して、コードレコグナイザ１０８は、ｅａｘレジスタの最初の使用を探し、そのポイントにてスライスを計算する。ｅａｘレジスタに０から２５５までのいずれかの値が割り当てられている場合には、警告が発せられ、適切なシグネチャが生成される。
【００７９】
第３のケースは、ｒｅｔ命令のケースである。この命令は、スタックの状態に応じて制御フローを変更する。従って、出願人らは、ｒｅｔがコールされる前に、連鎖における早いポイントで、スタックフレームを生成するコール命令か、または、（プッシュ命令などの）スタックの状態を明確に設定する命令を発見すると予想する。そうでなければ、ｒｅｔ命令を実行すると、エクスプロイトの成功ではなく、クラッシュを引き起こすことがある。
【００８０】
第４のケースは、分岐ターゲットが隠されているケースである。分岐ターゲットがレジスタのアドレス指定によって隠されている場合には、上述した分岐ターゲットに対する制約が、対応する隠された分岐ターゲットを保持することを確実にするだけで十分である。このケースでは、コードレコグナイザ１０８は、オペランドに有効な分岐ターゲットが割り当てられているか否かを確認する目的で、スライスを計算する。オペランドに有効な分岐ターゲットが割り当てられている場合には、警告が発せられる。
【００８１】
ポリモーフィックエクスプロイトコードの場合も、ステップ８０８でテストされてもよいが、この場合は若干異なる方法で処理される。デクリプタ（decryptor）本体のみが可視であると予想でき、デクリプタ本体はループとして実装されることが多いので、コードレコグナイザ１０８は、削減されたＣＦＧ内でサイクルの証拠を探すが、これは、Ｏ（ｎ）内に達成することができる。ここで、ｎは、有効な連鎖におけるステートメントの総数である。ここでもまた、使用されるアドレス指定モードに応じて、ループ自体が、明らかなこともあり得るし、隠されていることもあり得る。前者の場合、コードレコグナイザ１０８は、ループ本体の中で使用されている少なくとも１つのレジスタが本体の外側で初期化されたことを確認する。代替のチェック方法として、ループ本体の中の少なくとも１つのレジスタがネットワークフロー自体を参照することを確認することがあげられる。間接アドレス指定のためループが明らかでない場合には、状況は第４のケースと同様である。出願人らは、制御フローが元のネットワークフローを指示するように、分岐ターゲットに値が割り当てられることを予想する。
【００８２】
次いで、ステップ８１０において、コードレコグナイザ１０８は、次の３つの技法を用いて制約強化を行う。第１に、ホストコンピュータ内の全ての脆弱なバッファに対して、攻撃者はバッファの限度を超える任意の量のデータを書き込むおそれがあるが、書き込みは、マッピングされていないメモリまたは無効なメモリへと向けられ得るので、これはクラッシュという結果になる可能性が非常に高い。これがリモートエクスプロイトの目的であることはほとんどなく、成功させるためには、エクスプロイトコードは、バッファ内に収まるように、注意深く作成されなければならない。脆弱なバッファは各々、サイズが限られており、今度は、これが送信される感染ベクトル（infection vector）のサイズに制限を加える。
【００８３】
第２に、分岐ターゲットのタイプが、エクスプロイトコードに対して制限される。例えば、リモート感染中に伴う不確実性のため、制御フローが、任意のいかなるメモリ位置にも転送されることは不可能である。さらに、上述したサイズの制約のため、分岐ターゲットはペイロードコンポーネント内に存在することができ、従って、フローのサイズを上回るｃａｌｌ／ｊｕｍｐは無意味なものとなる。最後に、達成されなければならない目的のため、エクスプロイトコードは結局、制御をシステムコールに転送しなければならない。従って、注目すべき分岐命令は、ｊｕｍｐ（ｊｍｐ）系、ｃａｌｌ／ｒｅｔｕｒｎ（ｒｅｔ）系、ｌｏｏｐ系、および割り込みである。
【００８４】
第３に、攻撃者といえども、特権シェルなどの何らかの現実的な目的を達成するには、基礎をなすシステムコールサブシステムに目を向けなければならない。システムコールは、ライブラリインターフェース（Ｌｉｎｕｘではｇｌｉｂｃ、Ｗｉｎｄｏｗｓではｋｅｒｎｅｌ３２．ｄｌｌ，ｎｔｄｌｌ．ｄｌｌ）を通じて、あるいは割り込みを直接発行することによって呼び出すことができる。前者が選択された場合、Ｌｉｎｕｘでは０ｘ４０、Ｗｉｎｄｏｗｓでは０ｘ７７である、ライブラリの好適なベースロードアドレス（base load address）を探す。同様に、後者については、対応する割り込み番号は、Ｌｉｎｕｘではｉｎｔ  ０ｘ８０、Ｗｉｎｄｏｗｓではｉｎｔ  ０ｘ２ｅである。
【００８５】
エクスプロイトコードを検出する単純な手法は、分岐命令と、分岐命令のターゲットとを単に探して、上述した分岐ターゲット条件を確認することであろう。しかしながら、追加の分析を必要とする次の理由により、これだけでは十分でない。第１に、上記の条件を満たすバイトパターンがネットワークフローにおいて生じる確率は非常に低いが、それでも誤検出を回避するのに十分なほど低いわけではない。第２に、間接メモリアドレス指定のため、分岐ターゲットが明らかでない場合がある（例えば、「ｃａｌｌ  ０ｘ１２３４５６７８」という形式の代わりに、「ｃａｌｌ  ｅａｘ」または「ｃａｌｌ［ｅａｘ］」が使用される場合もある）。
【００８６】
エクスプロイトコード候補を識別するのに加えて、コードレコグナイザ１０８は、エクスプロイトコード候補のシグネチャを生成することもできる。制御フロー分析によって、余分な部分が除去されたＣＦＧが生成され、データフロー分析によって、有効なブロック内の注目すべき命令が識別される。このような命令に対応するバイトに基づいて、シグネチャが生成される。コードレコグナイザ１０８は、ＣＦＧ内の全てのブロックをシグネチャに変換することはしないことに留意されたい。というのは、バイナリ・ディスアセンブリからのノイズによって、エクスプロイトコードが誤って表現され、シグネチャが使用できなくなる可能性があるからである。シグネチャを生成している間に考慮すべき主な点は、制御フロー分析およびデータフロー分析は、違った角度で命令に注目してもよいが、シグネチャは、バイトを、ネットワークフローにおける発生順に含まなければならないことである。出願人らは、シグネチャについては、ワイルドカードを含む正規表現を用いる。というのは、関連する命令および対応するバイトシーケンスが、ネットワークフローにおいて切断されることがあるからである。
【００８７】
前述した本発明の詳細な説明は、あらゆる点で例示的なものにすぎず、限定的なものではないと理解されたい。本明細書で開示される本発明の範囲は、本発明の詳細な説明から判断されるべきでなく、特許法により認められる最大の広さに従って解釈される特許請求の範囲から判断されるべきである。本明細書に示して記述した実施形態は、本発明の原理を例示しているだけであり、当業者であれば、本発明の範囲および趣旨から逸脱することなく、様々な変形形態を実施できることが理解されよう。当業者であれば、本発明の範囲および趣旨から逸脱することなく、他の特徴の様々な組合せを実施することができよう。
【図面の簡単な説明】
【００８８】
【図１】本発明の一実施形態による、ネットワークフロー内のエクスプロイトコードを検出するためのシステムを示す図である。
【図２】本発明による機能を実行するようにプログラムすることができるコンピュータの高レベルのブロック図である。
【図３】コンテンツフィルタのフィルタリング機能を例示する図である。
【図４Ａ】例示的なバイトストリームを示す図である。
【図４Ｂ】様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。
【図４Ｃ】様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。
【図４Ｄ】様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。
【図４Ｅ】様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。
【図５】ＩＡ−３２アーキテクチャ向けの一般的な命令フォーマットの概要を示す図である。
【図６】制御フローグラフのインスタンスの部分図である。
【図７】ディスアセンブリ開始後、ｎバイトを過ぎて一致が生じる確率をプロットしたグラフである。
【図８】コードレコグナイザによって実行されるステップの、高レベルのフローチャートである。
【図１】
2008519374.tif 000018
【図２】
2008519374.tif 000019
【図３】
2008519374.tif 000020
【図４Ａ】
2008519374.tif 000021
【図４Ｂ】
2008519374.tif 000022
【図４Ｃ】
2008519374.tif 000023
【図４Ｄ】
2008519374.tif 000024
【図４Ｅ】
2008519374.tif 000025
【図５】
2008519374.tif 000026
【図６】
2008519374.tif 000027
【図７】
2008519374.tif 000028
【図８】
2008519374.tif 000029