JP4676499B2 - ネットワークフロー内のエクスプロイトコードの検出 - Google Patents

Description

本発明は、一般に、コンピュータシステムのエクスプロイト（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）が生じるように見えるので、これは注目すべきことである。図４Ａに示すバイトストリームについてみると、このバイトストリームは、ランダムなプリアンブルから構成され、その後にＮＯＰ（０ｘ９０）命令であるＮＯＯＰスレッドが続く。バイトストリームは、オフセット０、１、２、および３を開始点としてディスアセンブルされ、そのディスアセンブリの出力が、図４Ｂ、図４Ｃ、図４Ｄ、および図４Ｅにそれぞれ示されている。これらの図は、データストリームをＩｎｔｅｌバイナリコードとして解釈する３つの側面を示している。第１に、ほとんど全てのデータバイトは、正当なＩｎｔｅｌ命令にディスアセンブルされる。第２に、全てのディスアセンブリストリームは、オフセットおよび先行する不要なデータに関わらず、急速にＮＯＯＰスレッドに収束する。第３に、ＮＯＯＰスレッドからの若干の命令が失われるが、それにも関わらず、収束が生じる。

収束現象は、Ｉｎｔｅｌの命令セットの性質によって説明することができる。Ｉｎｔｅｌは、複雑な命令セットのコンピュータアーキテクチャを使用しているため、その命令セットは非常に密度が高い。ディスアセンブルを開始する所与の開始バイトとして可能な２５６個の値のうち、１つだけ（０ｘＦ１）が不正なものである。急速な収束についての別の関連する側面は、Ｉｎｔｅｌが可変長の命令セットを使用していることである。図５は、ＩＡ−３２アーキテクチャ向けの一般的な命令フォーマットの概要を示している。実際の復号された命令の長さは、１〜３バイトの長さであり得るオプコードだけでなく、適用可能であれば、プレフィックス、ＭｏｄＲ／ＭバイトおよびＳＩＢバイトによって与えられる指示にも依存する。また、全ての開始バイトがディスアセンブリの成功をもたらすわけではなく、そのような場合、それらは、図４Ｃおよび図４Ｄのオフセット０ｘ０００００００６にて示されるように、データバイトとして復号されることに留意されたい。

収束現象のより正式な数学的分析を以下に示す。バイトストリームに対して、実際のエクスプロイトコードが、何らかのオフセットｘ＝０，１，２，．．．にて組み込まれていると仮定する。理想的には、命令ストリームを復元するためのバイナリ・ディスアセンブリは、ｘにて始まるか、または、少なくともｘにて一致する必要がある。しかしながら、出願人らはｘを知らないので、バイトストリーム内の最初のバイトから開始する。出願人らは、ｘの後どれくらいでディスアセンブリがエクスプロイトコードの実際の命令ストリームと一致するのかを知ることに関心がある。

この疑問に答えるために、ディスアセンブリのプロセスを、バイトストリーム全体にわたるランダムウォークとしてモデル化する。このプロセスのモデルでは、各バイトが状態スペースにおける１個の状態に対応する。ディスアセンブリは、厳密に前方に進むランダムウォークであって、各ステップのサイズは、所与のバイトにて復号された命令の長さによって与えられる。２つのランダムウォークが存在し、一方は出願人らのディスアセンブリに対応し、他方は実際の命令ストリームに対応する。両方のランダムウォークが同時に進む必要はないし、両方のランダムウォークが一致するポイントに到達するのに同数のステップを取る必要もないことに留意されたい。

数学的用語に翻訳すると、Ｌ＝｛１，．．．．．，Ｎ｝は、確率｛ｐ₁，．．．．．，ｐ_N｝で生じる、考えられ得るステップのサイズまたは命令の長さの集合とする。第１のウォークについては、ステップのサイズを

とし、

と定義する。

同様に、第２のウォークについては、ステップのサイズを

とし、

とする。

出願人らは、ランダムウォーク｛Ｚ_k｝と、

とが交差する確率を発見することに関心があり、もし交差するのであるならば、どのバイト位置で交差するかということに関心がある。

これを行う１つの方法は、次のように定義される「ギャップ（gap）」を詳しく調べることである。ここで、Ｇ₀＝０、

とする。

ならば、Ｇ₁＝０となり、この場合、両ウォークは１ステップ後に交差する。Ｇ₁＞０の場合、一般性を失うことなく、

と仮定する。出願人らのアプリケーションの観点からすると、｛Ｚ_k｝は出願人らのディスアセンブリに対応するウォークであり、

は実際の命令ストリームである。

であり、

であると定義する。一般に、Ｚと、

とは、各「ギャップ」変数Ｇ_nの定義において、「先行部（leader）」と「遅行部（laggard）」との役割を交代する。｛Ｇ_n｝はマルコフ連鎖を形成する。マルコフ連鎖を単純化できない場合、ランダムウォークは正の確率（positive probability）で交差し、実際、第１回目では、ギャップのサイズは０である。ここで、
Ｔ＝ｉｎｆ｛ｎ＞０：Ｇ_n＝０｝
を両方のウォークが交差する最初の時間であるとする。この交差が生じるプログラムブロック内のバイト位置は、以下の式により与えられる。

一般に、出願人らには、プログラムブロック内の出願人らの開始位置であるＺ₁は分からない。というのは、出願人らは、プログラムのエントリポイントを知らないからである。従って、出願人らは、一致が生じるディスアセンブリ開始ポイント後のバイト位置の数を表す量である、

について、大いに関心がある。分配（partition）と多項分布とを用いて、
ｉ，ｊ∈｛０，１，．．．，Ｎ−１｝の各々について、
推移確率の行列ｐ_n（ｉ，ｊ）＝Ｐ（Ｇ_n+1＝ｊ｜Ｇ_n＝ｉ）を計算することができる。実際、ｐ_n（ｉ，ｊ）＝ｐ（ｉ，ｊ）は、ｎに依存しない、すなわち、マルコフ連鎖は一様である。この行列によって、例えば、２つのランダムウォークが、ディスアセンブリの開始後、ｎの位置で交差する確率を計算することができる。

上記の計算に必要な命令の長さの確率｛ｐ₁，．．．，ｐ_N｝は、ネットワークフローのバイトコンテンツに依存する。命令の長さの確率は、実証的分析の間に選択された同じネットワークフロー（ＨＴＴＰ、ＳＳＨ、ＸＩＩ、ＣＩＦＳ）に対するディスアセンブリと統計的計算とによって得られた。図７において、ディスアセンブリ開始後、ｎバイトを過ぎて交差（一致）が生じる確率

を、ｎ＝０，．．．，９９についてプロットした。

この確率は急に低下することが明らかであり、実際、ディスアセンブリ開始後、それぞれ２１番目（ＨＴＴＰ）、１６番目（ＳＳＨ）、１５番目（ＸＩＩ）、および１６番目（ＣＩＦＳ）のバイトの位置、または、それらより前の位置で、ディスアセンブリ「ウォーク」と「プログラムウォーク」とが、確率０．９５で交差する。平均すると、両ウォークは、それぞれわずか６．３バイト（ＨＴＴＰ）、４．５バイト（ＳＳＨ）、３．２バイト（ＸＩＩ）、および４．３バイト（ＣＩＦＳ）後に交差することになる。

セキュリティの観点から、静的分析は、プログラムコードの脆弱性と、それに関連したソフトウェアのバグとを発見するのに使用されることが多い。静的分析はまた、所与のプログラムが悪意のあるコードを含んでいるか否かを判定するためにも使用される。しかしながら、コード難読化技術およびエイリアシングの論証不能性のため、合理的な期限内に正確な静的分析を行うのは、非常に難しい問題である。一方では、表面的な静的分析は効率的であるが対象範囲が狭くなることがあり、他方では、高精度を追求すると、通常、非常に処理時間がかかる結果になりやすい。一般論として、出願人らの手法は、ネットワークフローに対して静的分析を用いるのであり、オンラインネットワークベースの実装を実現するためには、効率性が重要な設計目標となる。通常であれば、これは精度の悪さをもたらすことがあるが、出願人らの手法は、除外プロセスを工夫するためだけに静的分析を用いるのであり、この手法は、エクスプロイトコードが、エクスプロイトコードのサイズと制御フローとの点で、いくつかの制約を受けるという前提に基づいている。これらの制約は、その後、バイトストリームがデータであるか、または、プログラムのようなコードであるかを判定するのに役立つように用いられる。

復元され得る情報量に応じて、静的分析の観点から、エクスプロイトコードには２つの大きなカテゴリがある。第１のカテゴリは、既知のエクスプロイト、ゼロデイエクスプロイト、およびメタモーフィック（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）Ｏ（ｖ×ｎ×ｅ）を有している。ここで、ｖ、ｎ、ｅはそれぞれ、ＣＦＧ内の変数の数、頂点の数、辺の数である。Ｉｎｔｅｌプラットフォームには固定数のレジスタしかなく、かつ、典型的なＣＦＧ内の頂点および辺の数はほぼ同じであると仮定すると、実行時間はＯ（ｎ²）である。プログラム依存グラフ（ＰＤＧ：Program Dependence Graph）やシステム依存グラフ（ＳＤＧ：System Dependence Graph）などの様々な表現を用いて、グラフの到達可能性に基づく分析を実行するその他の手法もある。このようなアルゴリズムには追加の表現のオーバヘッドが伴うが、精度が最重要である場合には、このようなアルゴリズムの方が適切である。

一般に、削減されたＣＦＧ内のどの連鎖であっても、当てはまる特性は少ない。連鎖における最後のブロック以外のブロックは全て、ネットワークフローに対するオフセットである分岐ターゲットを有しており、その後続ブロック（successor block）を指示する。連鎖における最後のブロックについては、以下のようなケースで、データのみを含むフローと実行エクスプロイトコード候補を含むフローとを区別する除去プロセスが講じられる。

第１のケースは、明らかなライブラリコールのケースである。連鎖における最後の命令が分岐命令、特にｃａｌｌ／ｊｍｐで終わるが、明らかなターゲット（即値アドレス指定／絶対アドレス指定）を有する場合、そのターゲットはライブラリコールアドレスでなければならない。即値分岐ターゲットを有する有効な分岐命令が他にあるならば、その分岐命令は、連鎖においてもっと早く出現して、次の有効なブロックを指示するであろう。対応する連鎖は、スタックがライブラリコールより前の矛盾のない状態にある場合にのみ実行することができるので、出願人らは、最後の分岐命令より前にプッシュ命令があることを予想する。コードレコグナイザは、スライシング基準＜ｓ，ｖ＞を用いてプログラムスライスを計算する。ここで、ｓはプッシュ命令のステートメント番号であり、ｖはそのオペランドである。出願人らは、命令の中で用いられる以前にｖが定義されると予想する。このような条件が満たされ、かつ、ライブラリコールが疑わしいものである場合には、警告が発せられる。また、最後の分岐命令およびプログラムスライスに対応するバイトシーケンスは、（以下でさらに詳述するように）シグネチャに変換される。

第２のケースは、明らかな割り込みのケースである。これは、分岐命令が明らかな分岐ターゲットを有する別のケースであり、その分岐ターゲットは有効な割り込み番号でなければならない。すなわち、割り込みの前に、レジスタｅａｘは有意義な値に設定される。ｉｎｔ命令から後方に動作して、コードレコグナイザ１０８は、ｅａｘレジスタの最初の使用を探し、そのポイントにてスライスを計算する。ｅａｘレジスタに０から２５５までのいずれかの値が割り当てられている場合には、警告が発せられ、適切なシグネチャが生成される。

第３のケースは、ｒｅｔ命令のケースである。この命令は、スタックの状態に応じて制御フローを変更する。従って、出願人らは、ｒｅｔがコールされる前に、連鎖における早いポイントで、スタックフレームを生成するコール命令か、または、（プッシュ命令などの）スタックの状態を明確に設定する命令を発見すると予想する。そうでなければ、ｒｅｔ命令を実行すると、エクスプロイトの成功ではなく、クラッシュを引き起こすことがある。

第４のケースは、分岐ターゲットが隠されているケースである。分岐ターゲットがレジスタのアドレス指定によって隠されている場合には、上述した分岐ターゲットに対する制約が、対応する隠された分岐ターゲットを保持することを確実にするだけで十分である。このケースでは、コードレコグナイザ１０８は、オペランドに有効な分岐ターゲットが割り当てられているか否かを確認する目的で、スライスを計算する。オペランドに有効な分岐ターゲットが割り当てられている場合には、警告が発せられる。

ポリモーフィックエクスプロイトコードの場合も、ステップ８０８でテストされてもよいが、この場合は若干異なる方法で処理される。デクリプタ（decryptor）本体のみが可視であると予想でき、デクリプタ本体はループとして実装されることが多いので、コードレコグナイザ１０８は、削減されたＣＦＧ内でサイクルの証拠を探すが、これは、Ｏ（ｎ）内に達成することができる。ここで、ｎは、有効な連鎖におけるステートメントの総数である。ここでもまた、使用されるアドレス指定モードに応じて、ループ自体が、明らかなこともあり得るし、隠されていることもあり得る。前者の場合、コードレコグナイザ１０８は、ループ本体の中で使用されている少なくとも１つのレジスタが本体の外側で初期化されたことを確認する。代替のチェック方法として、ループ本体の中の少なくとも１つのレジスタがネットワークフロー自体を参照することを確認することがあげられる。間接アドレス指定のためループが明らかでない場合には、状況は第４のケースと同様である。出願人らは、制御フローが元のネットワークフローを指示するように、分岐ターゲットに値が割り当てられることを予想する。

次いで、ステップ８１０において、コードレコグナイザ１０８は、次の３つの技法を用いて制約強化を行う。第１に、ホストコンピュータ内の全ての脆弱なバッファに対して、攻撃者はバッファの限度を超える任意の量のデータを書き込むおそれがあるが、書き込みは、マッピングされていないメモリまたは無効なメモリへと向けられ得るので、これはクラッシュという結果になる可能性が非常に高い。これがリモートエクスプロイトの目的であることはほとんどなく、成功させるためには、エクスプロイトコードは、バッファ内に収まるように、注意深く作成されなければならない。脆弱なバッファは各々、サイズが限られており、今度は、これが送信される感染ベクトル（infection vector）のサイズに制限を加える。

第２に、分岐ターゲットのタイプが、エクスプロイトコードに対して制限される。例えば、リモート感染中に伴う不確実性のため、制御フローが、任意のいかなるメモリ位置にも転送されることは不可能である。さらに、上述したサイズの制約のため、分岐ターゲットはペイロードコンポーネント内に存在することができ、従って、フローのサイズを上回るｃａｌｌ／ｊｕｍｐは無意味なものとなる。最後に、達成されなければならない目的のため、エクスプロイトコードは結局、制御をシステムコールに転送しなければならない。従って、注目すべき分岐命令は、ｊｕｍｐ（ｊｍｐ）系、ｃａｌｌ／ｒｅｔｕｒｎ（ｒｅｔ）系、ｌｏｏｐ系、および割り込みである。

第３に、攻撃者といえども、特権シェルなどの何らかの現実的な目的を達成するには、基礎をなすシステムコールサブシステムに目を向けなければならない。システムコールは、ライブラリインターフェース（Ｌｉｎｕｘではｇｌｉｂｃ、Ｗｉｎｄｏｗｓではｋｅｒｎｅｌ３２．ｄｌｌ，ｎｔｄｌｌ．ｄｌｌ）を通じて、あるいは割り込みを直接発行することによって呼び出すことができる。前者が選択された場合、Ｌｉｎｕｘでは０ｘ４０、Ｗｉｎｄｏｗｓでは０ｘ７７である、ライブラリの好適なベースロードアドレス（base load address）を探す。同様に、後者については、対応する割り込み番号は、Ｌｉｎｕｘではｉｎｔ ０ｘ８０、Ｗｉｎｄｏｗｓではｉｎｔ ０ｘ２ｅである。

エクスプロイトコードを検出する単純な手法は、分岐命令と、分岐命令のターゲットとを単に探して、上述した分岐ターゲット条件を確認することであろう。しかしながら、追加の分析を必要とする次の理由により、これだけでは十分でない。第１に、上記の条件を満たすバイトパターンがネットワークフローにおいて生じる確率は非常に低いが、それでも誤検出を回避するのに十分なほど低いわけではない。第２に、間接メモリアドレス指定のため、分岐ターゲットが明らかでない場合がある（例えば、「ｃａｌｌ ０ｘ１２３４５６７８」という形式の代わりに、「ｃａｌｌ ｅａｘ」または「ｃａｌｌ［ｅａｘ］」が使用される場合もある）。

エクスプロイトコード候補を識別するのに加えて、コードレコグナイザ１０８は、エクスプロイトコード候補のシグネチャを生成することもできる。制御フロー分析によって、余分な部分が除去されたＣＦＧが生成され、データフロー分析によって、有効なブロック内の注目すべき命令が識別される。このような命令に対応するバイトに基づいて、シグネチャが生成される。コードレコグナイザ１０８は、ＣＦＧ内の全てのブロックをシグネチャに変換することはしないことに留意されたい。というのは、バイナリ・ディスアセンブリからのノイズによって、エクスプロイトコードが誤って表現され、シグネチャが使用できなくなる可能性があるからである。シグネチャを生成している間に考慮すべき主な点は、制御フロー分析およびデータフロー分析は、違った角度で命令に注目してもよいが、シグネチャは、バイトを、ネットワークフローにおける発生順に含まなければならないことである。出願人らは、シグネチャについては、ワイルドカードを含む正規表現を用いる。というのは、関連する命令および対応するバイトシーケンスが、ネットワークフローにおいて切断されることがあるからである。

前述した本発明の詳細な説明は、あらゆる点で例示的なものにすぎず、限定的なものではないと理解されたい。本明細書で開示される本発明の範囲は、本発明の詳細な説明から判断されるべきでなく、特許法により認められる最大の広さに従って解釈される特許請求の範囲から判断されるべきである。本明細書に示して記述した実施形態は、本発明の原理を例示しているだけであり、当業者であれば、本発明の範囲および趣旨から逸脱することなく、様々な変形形態を実施できることが理解されよう。当業者であれば、本発明の範囲および趣旨から逸脱することなく、他の特徴の様々な組合せを実施することができよう。

本発明の一実施形態による、ネットワークフロー内のエクスプロイトコードを検出するためのシステムを示す図である。 本発明による機能を実行するようにプログラムすることができるコンピュータの高レベルのブロック図である。 コンテンツフィルタのフィルタリング機能を例示する図である。 例示的なバイトストリームを示す図である。 様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。 様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。 様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。 様々なオフセットにて開始される図４Ａのバイトストリームのディスアセンブリを例示する図である。 ＩＡ−３２アーキテクチャ向けの一般的な命令フォーマットの概要を示す図である。 制御フローグラフのインスタンスの部分図である。 ディスアセンブリ開始後、ｎバイトを過ぎて一致が生じる確率をプロットしたグラフである。 コードレコグナイザによって実行されるステップの、高レベルのフローチャートである。

Claims (19)

1. ネットワークトラヒックをモニタリングしてエクスプロイトコードを検出するエクスプロイト検出器における方法であって、
   ネットワークデータパケットをインターセプトするステップと、
   前記インターセプトしたデータパケットからデータフローを生成するステップと、
   正規の実行コードを含む前記データフローの少なくとも一部分をフィルタリングするステップであって、正規のプログラムコードを示す正規の実行コードを含む少なくとも１つの正規のプログラムの指標を識別することを含むステップと、
   正規のプログラムコードとして識別されないデータフローの一部分を含む前記データフローのフィルタリングされていない部分を、前記正規のプログラムコードを除いてコードレコグナイザに提供するステップと、
   前記コードレコグナイザが、前記データフローの前記フィルタリングされていない部分の中からエクスプロイト候補として実行コードを検出するステップと
   を備えることを特徴とする方法。
2. 前記フィルタリングは、予め定められたルールのセットに基づくことを特徴とする請求項１に記載の方法。
3. 前記正規のプログラムコードが悪意のあるコードを含むか否かを判定するステップをさらに備えることを特徴とする請求項１に記載の方法。
4. 前記実行コードを検出するステップは、前記データフローの前記フィルタリングされていない部分に対してコンバージェント・バイナリ・ディスアセンブリを行うことを含むことを特徴とする請求項１に記載の方法。
5. 前記実行コードを検出するステップは、
   前記コンバージェント・バイナリ・ディスアセンブリの結果から制御フローグラフを作成し、この結果を前記コンバージェント・バイナリ・ディスアセンブリのブロックである見込まれる制御フローを示すエッジによって接続されたノードとして表すステップと、
   前記制御フローグラフを用いて制御フロー分析を行い、エクスプロイト候補実行コードを含まないブロックを削除することにより前記制御フローグラフを変更するステップと
   をさらに含むことを特徴とする請求項４に記載の方法。
6. 制約強化を行うステップをさらに備えることを特徴とする請求項１に記載の方法。
7. 前記検出した実行コードからコードシグネチャを生成するステップをさらに備えることを特徴とする請求項１に記載の方法。
8. ネットワークトラヒックをモニタリングするシステムであって、
   インターセプトされたネットワークデータパケットを受信するネットワークインターフェースと、
   前記インターセプトされたネットワークデータパケットからデータフローを生成するフローモニタと、
   前記データフローの少なくとも一部分をフィルタリングするコンテンツフィルタであって、前記データフローから正規のプログラムコードをフィルタリングするコンテンツフィルタと、
   前記正規のプログラムコードを除く、前記コンテンツフィルタにより解析された前記データフローの他の部分を受信し、
   前記データフローの前記他の部分の中からエクスプロイト候補として実行コードを検出する実行コードレコグナイザと
   を備えたことを特徴とするシステム。
9. 前記コンテンツフィルタは、フィルタリングルールのセットを格納することを特徴とする請求項８に記載のシステム。
10. 前記正規のプログラムコードが悪意のあるコードを含むか否かを判定する悪意プログラムアナライザをさらに備えたことを特徴とする請求項８に記載のシステム。
11. 前記実行コードレコグナイザは、コンバージェント・バイナリ・ディスアセンブリを行うことを特徴とする請求項８に記載のシステム。
12. ネットワークトラヒックをモニタリングするシステムであって、
    ネットワークデータパケットをインターセプトする手段と、
    前記インターセプトしたデータパケットからデータフローを生成する手段と、
    正規の実行コードを含む前記データフローの少なくとも一部分をフィルタリングする手段であって、正規のプログラムコードを示す正規の実行コードを含む少なくとも１つの正規のプログラムの指標を識別することを含む手段と、
    正規のプログラムコードとして識別されないデータフローの一部分を含む前記データフローのフィルタリングされていない部分を、前記正規のプログラムコードを除いてコードレコグナイザに提供する手段と、
    前記データフローの前記フィルタリングされていない部分の中からエクスプロイト候補として実行コードを検出するコードレコグナイザと
    を備えたことを特徴とするシステム。
13. 前記フィルタリングする手段は、予め定められたルールのセットを含むことを特徴とする請求項１２に記載のシステム。
14. 前記正規のプログラムコードが悪意のあるコードを含むか否かを判定する手段をさらに備えたことを特徴とする請求項１２に記載のシステム。
15. 前記コードレコグナイザは、前記データフローの前記フィルタリングされていない部分に対してコンバージェント・バイナリ・ディスアセンブリを行う手段を含むことを特徴とする請求項１２に記載のシステム。
16. 前記コードレコグナイザは、
    制御フローグラフを作成する手段と、
    前記制御フローグラフを用いて制御フロー分析を行う手段と
    をさらに含むことを特徴とする請求項１５に記載のシステム。
17. 制約強化を行う手段をさらに備えたことを特徴とする請求項１２に記載のシステム。
18. 前記検出した実行コードからコードシグネチャを生成する手段をさらに備えたことを特徴とする請求項１２に記載のシステム。
19. コンピュータに、請求項１ないし７のいずれかに記載の各ステップを実行させるためのコンピュータプログラム。

Images