不正処理検知装置、不正処理検知方法及びプログラム
【課題】コンピュータウィルスなどによる不正処理を検知する場合において誤検知の発生を軽減することのできる技術を提供する。
【解決手段】コンピュータ装置３００は、不正処理の検査を行う前に、検査する挙動をフィルタリングすることにより、誤検知を低減する。フィルタリング処理においては、コンピュータ装置３００は、コールスタックに積まれるリターンアドレス列を取得し、取得したリターンアドレス列と、予め生成されたリターンアドレス列とを比較し、比較結果に応じて、監視対象となるソフトウェアの挙動が異常か否かを判定する。異常でないと判定された場合にはソフトウェアの実行を継続する一方、異常であると判定された場合には、コンピュータ装置３００は、取得したリターンアドレス列に対応するコードを解析し、解析結果に応じて不正処理の有無を検出する。
【解決手段】コンピュータ装置３００は、不正処理の検査を行う前に、検査する挙動をフィルタリングすることにより、誤検知を低減する。フィルタリング処理においては、コンピュータ装置３００は、コールスタックに積まれるリターンアドレス列を取得し、取得したリターンアドレス列と、予め生成されたリターンアドレス列とを比較し、比較結果に応じて、監視対象となるソフトウェアの挙動が異常か否かを判定する。異常でないと判定された場合にはソフトウェアの実行を継続する一方、異常であると判定された場合には、コンピュータ装置３００は、取得したリターンアドレス列に対応するコードを解析し、解析結果に応じて不正処理の有無を検出する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ソフトウェアが実行されるときの挙動を利用して不正処理を検知する技術に関する。
【背景技術】
【０００２】
パーソナルコンピュータ（以下、ＰＣという）等の計算機器は、コンピュータウィルス（以下、ウィルスという）による攻撃にさらされている。ＰＣに対するウィルスによる被害は年々増加し、さらに悪質化している。例えば、以前はいたずらを目的としたウィルスが主流であったが、近年では金銭目的のウィルスが増加している。さらにウィルスはＰＣのみでなく携帯電話機にも感染する恐れがある。実際、携帯電話機に対するウィルス被害が報告されている。また、携帯電話機はＰＣよりも多くの個人情報を多く含んでいる可能性が高く、特に高機能化された携帯電話機では電子マネーなど価値の高い情報が多く含まれていることもある。
【０００３】
現在、ＰＣ向けのウィルス対策技術としては、ウィルススキャンと呼ばれる手法が主流となっている。この手法では、ウィルスの特徴点をパターンデータとして予め記録しておき、検査時にはこのパターンデータとマッチするものがないかを調べる。そのため、新種ウィルス等のパターンデータが定義されていない未知のウィルスは検知することができず、新たなパターンデータが追加されるまでの期間に被害が拡大してしまうという問題点を有している。そこで、既知のパターンデータとの照合によりウィルスを発見するのではなく、ソフトウェアが実行されているときの挙動を解析し、異常が発生していないかを調べる方法が検討されている。例えば、ウィルスがよく行う処理（例えば、ウィルス自身をコピーするという処理など）を予め登録しておき、その処理をしたときに異常と判断する、というビヘイビア法がある。また、ソフトウェアの正常な挙動を予め学習して正常モデルを作成し、実行時にこれと異なる挙動が発見されたら異常と判断する方法もある。
【０００４】
例えば特許文献１には、コンピュータウィルスや不正アクセスを抑制することを目的として、オペレーティングシステムが、プログラムから要求されたＡＰＩ（Application Program Interface）を実行する前に、メモリ装置上におけるプログラムの格納アドレスを取得し、そのアドレスが適正な位置を示しているか否かを比較判定することにより、ＡＰＩをコールしたプログラムが適正か不正かを判断する技術が提案されている。また、特許文献２には、バッファオーバーフローによるリターンアドレスの改ざんを防止するために、プログラムが実行されてリターンアドレスが書き換えられた場合、中央演算処理装置のデバッグ機能を利用してリターンアドレスの改ざんを検知し、予め保存された値で改ざんされたリターンアドレスを書き直し、プログラムを正常な動作に戻す技術が提案されている。また、特許文献３には、システムコールやＡＰＩ関数にブレークポイントを設定してシステムコールなどの呼び出しを監視し、監視対象プロセスの振る舞い（処理）と過去のコンピュータウィルスの特徴的な振る舞い（処理）とを比較することにより、コンピュータウィルスによるデータ改ざん等を防止する技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２００５／０２９３２８号
【特許文献２】国際公開第２００５／０２４６３０号
【特許文献３】国際公開第２００４／０７５０６０号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、ビヘイビア法では、ウィルスがよく行う処理を正常なソフトウェアが実行することもあるため、正常か異常かを正確に判断することは非常に難しい。そのため、異常が発生していないのに異常であると判断してしまう誤検知が発生し、ユーザの利便性を悪化させる。また、正常モデルを利用する方法では、ソフトウェアの挙動を全てモデル化することは一般に困難であり、特にユーザインタラクションがある場合はソフトウェアの挙動の数は無限に近くなる。そのため、正常モデルから外れる挙動を全て異常と判断してしまい、誤検知が発生するという問題を解消することはできない。
【０００７】
本発明は、コンピュータウィルスなどによる不正処理を検知する場合において誤検知の発生を軽減することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明は、ソフトウェアを実行する実行手段と、ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを複数記憶する挙動モデルデータ記憶手段と、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを複数記憶する不正処理定義データ記憶手段と、不正処理の検知対象となるソフトウェアが前記実行手段によって実行されるときにコールスタックに格納されるリターンアドレスを取得するリターンアドレス取得手段と、前記リターンアドレス取得手段によって取得されたリターンアドレスと、前記挙動モデルデータ記憶手段に記憶された各挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する挙動判定手段と、前記挙動判定手段によって正常でないと判定された場合に、前記リターンアドレス取得手段によって取得されたリターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された各不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知する不正処理検知手段とを具備することを特徴とする不正処理検知装置を提供する。
【０００９】
本発明の好ましい態様において、前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を前記挙動モデルデータとして複数記憶し、前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたリターンアドレス列との一致度が予め定められた条件を満たすか否かにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定してもよい。
【００１０】
また、本発明の別の好ましい態様において、前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列と当該リターンアドレス列が格納されているタイミングと異なるタイミングにおいて前記コールスタックに格納されているリターンアドレス列との差分を表すデータを前記挙動モデルデータとして複数記憶し、前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記異なるタイミングにおいて前記コールスタックに格納されている各リターンアドレスからなるリターンアドレス列との差分を、前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたデータと比較することにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定してもよい。
【００１１】
また、本発明の別の好ましい態様において、前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレスの少なくとも一部が、前記挙動モデルデータ記憶手段に記憶された複数の挙動モデルデータのうちのいずれかと一致する場合に、前記不正処理の検知対象となるソフトウェアの挙動が正常であると判定してもよい。
【発明の効果】
【００１２】
本発明によれば、不正処理を検知する場合において誤検知の発生を軽減することができる。
【図面の簡単な説明】
【００１３】
【図１】コンピュータ装置のハードウェア構成の一例を示すブロック図である。
【図２】異常検知装置の構成例を示すブロック図である。
【図３】コールスタックの変化の一例を示す模式図である。
【図４】コールスタックの構成の一例を示す模式図である。
【図５】バッファオーバーフロー攻撃時のコールスタックの変化の一例を示す模式図である。
【発明を実施するための形態】
【００１４】
本発明を実施するための形態について説明する。なお、以下の説明において、「ソフトウェア」を動作の主体として表現することがあるが、これは、その「ソフトウェア」に記述された手順を実行するＣＰＵ（Central Processing Unit）が動作の主体であることを意味している。
図１は、この発明の一実施形態に係る不正処理検知装置としてのコンピュータ装置３００の構成の一例を示すブロック図である。このコンピュータ装置３００は、どのようなコンピュータ装置であってもよく、例えばパーソナルコンピュータやサーバ装置のほか、携帯電話機やＰＤＡ（Personal Digital Assistants）などを含む。図において、ＣＰＵ３０１は、ＲＯＭ（Read Only Memory）３０３又は記憶部３０５に格納されたコンピュータプログラムを、ＲＡＭ（Random Access Memory）３０２をワークエリアとして実行することによって、コンピュータ装置３００の制御を行う。記憶部３０５は、ハードディスク等の記憶手段であり、コンピュータ装置３００の制御に関するプログラム等の各種プログラムが格納されている。入力部３０４は、外部装置と通信する通信手段である。ここにおいて、外部装置とは、例えば、外付けのフロッピー（登録商標）ディスクドライバやハードディスクなどの記録装置や、ネットワークを介して接続されるサーバ装置等である。入力部３０４は、外部装置と有線により通信を行ってもよいし、無線により通信を行ってもよい。なお、コンピュータ装置３００は、図１に示した構成以外に、例えば表示を行う表示部や利用者の操作を受け付ける操作部などの他の構成を有していてもよい。
【００１５】
コンピュータ装置３００の記憶部３０５には、ＯＳ（Operating System）プログラム（図示略）が記憶されているほかに、監視対象ソフトウェアプログラムＰＲＧ１と、ソフトウェア挙動異常検知プログラムＰＲＧ２と、不正検査プログラムＰＲＧ３とが記憶されている。なお、以下の説明では、説明の便宜上、コンピュータ装置３００のＣＰＵ３０１が記憶部３０５に記憶されたプログラムを実行することを、「ソフトウェアを実行する」という。また、記憶部３０５は、挙動モデル記憶領域３０５１と、不正処理定義記憶領域３０５２とを有している。挙動モデル記憶領域３０５１には、ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータが複数記憶される。ソフトウェアの挙動とは、ＣＰＵ３０１がそのソフトウェアに記述された手順に従って処理を行うときの、そのＣＰＵ３０１による処理内容のことである。この挙動モデルデータの内容は後述するため、ここではその詳細な説明を省略する。
【００１６】
次に、不正処理定義記憶領域３０５２には、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データが複数記憶されている。この不正処理定義データは、ウィルス等を原因とする不正な処理を検出する際に参照されるデータである。例えば、ウィルスである可能性が高い処理の特徴がリスト形式で列挙されたものが、不正処理定義データとして用いられる。具体的には、例えば、以下の（１）乃至（５）のような処理の内容を表すデータが不正処理定義データとして用いられる。
（１）ディスクをフォーマット、（２）自分自身を他へコピー、（３）実行ファイル書き換え、（４）メール大量送信、（５）特定のＴＣＰ（Transmission Control Protocol）ポートから発信
これらの不正処理定義データの内容は、いわゆるビヘイビア法において事前にソフトウェアが実行されているときの挙動を解析する手法を用いて特定されたものである。
【００１７】
次に、コンピュータ装置３００の機能的構成について図２を参照しつつ説明する。図２は、コンピュータ装置３００の機能的構成の一例を示す図である。図において、ソフトウェア実行手段１０は、コンピュータ装置３００のＣＰＵ３０１が記憶部３０５に記憶されている監視対象ソフトウェアプログラムＰＲＧ１を読み出して実行することによって実現される。また、ソフトウェア挙動異常検知手段１１０は、ＣＰＵ３０１が記憶部３０５に記憶されているソフトウェア挙動異常検知プログラムＰＲＧ２を読み出して実行することによって実現される。不正検査手段１２０は、ＣＰＵ３０１が記憶部３０５に記憶されている不正検査プログラムＰＲＧ３を読み出して実行することによって実現される。ソフトウェア実行手段１０は、監視対象となるソフトウェアを実行する手段であるが、図２においては、図が煩雑になるのを防ぐために、１つのソフトウェア実行手段１０のみを図示している。監視対象となるソフトウェアの数は１に限らず複数であってもよいから、ＣＰＵ３０１が複数のソフトウェアを並列的に実行している場合には、ソフトウェア実行手段１０は複数構成されることになる。
【００１８】
不正検査手段１２０は、ウィルス等による不正処理を検知する手段である。不正検査手段１２０は、不正処理定義記憶領域３０５２に記憶されている不正処理定義データを用い、ビヘイビア法に従って不正処理を検出する。ソフトウェア挙動異常検知手段１１０は、不正検査手段１２０がソフトウェアによる不正処理を検知する処理を行う前に、そのソフトウェアの挙動をフィルタリングする手段である。本実施形態ではソフトウェア挙動異常検知手段１１０がこのフィルタリングによってソフトウェアが不正である可能性があるか否かを判断し、不正検査手段１２０が、その可能性があるソフトウェアについてのみ不正処理の検知を行うという２段階の処理工程を経ることで、そのような２段階の処理工程を経ない場合と比べて、誤検知を低減することが可能となっている。
【００１９】
ソフトウェア挙動異常検知手段１１０は、ソフトウェア実行手段１０によって実行されている監視対象となるソフトウェア（以下「監視対象ソフトウェア」という）の挙動を表すデータ（以下「ソフトウェア挙動データ」という）を取得し、取得したソフトウェア挙動データを用いてソフトウェアの挙動が異常か否かを判定し、その判定結果を出力する。このソフトウェア挙動異常検知手段１１０は、ソフトウェア挙動取得手段２１０、モデル取得手段２２０、異常度合い判定手段２３０、及び異常判定情報取得手段２４０から構成されている。以下、これらの各手段の機能を説明する。
【００２０】
まず、ソフトウェア挙動取得手段２１０は、監視対象ソフトウェアの挙動を表すソフトウェア挙動データを取得する。ここでは、ソフトウェア挙動取得手段２１０は、ソフトウェアの挙動を表すソフトウェア挙動データとして、不正処理の検知対象となるソフトウェア（監視対象ソフトウェア）がソフトウェア実行手段１０によって実行されるときにコールスタックに格納されるリターンアドレスを取得する。コールスタックには、監視対象ソフトウェアに記述されたサブルーチンのうち、呼び出し元から呼び出された（コールされた）サブルーチンのリターンアドレスなどの情報が積まれており、監視対象ソフトウェアはこのリターンアドレスを元に、呼び出し元に戻る（リターンする）。なお、コールスタックにリターンアドレスを積む、とは、コールスタックに対し新たにリターンアドレスを格納するという意味である。このように、ソフトウェア挙動取得手段２１０は、ソフトウェア実行手段１０によって実行されている監視対象ソフトウェアが利用するリターンアドレスを取得する。
【００２１】
ここで、コールスタックに積まれるリターンアドレスの内容の一例について図面を参照しつつ説明する。図３（ａ）はソースコードの内容の一例を示す図であり、図３（ｂ）はコールスタックに積まれるリターンアドレスの一例を示す図である。
例えば図３（ａ）に示すようなソースコードを有するソフトウェアをＣＰＵが実行したとき、コールスタックの状態は図３（ｂ）のように変化する。図３（ａ）における（ｉ）〜（ｖ）と、図３（ｂ）における（ｉ）〜（ｖ）とは対応しており、例えば図３（ａ）の（ｉ）のソースコードを実行しているときのコールスタックの状態は図３（ｂ）の（ｉ）である。順を追って説明すると、まず、ソフトウェアにより、サブルーチンに相当する関数Ａがコールされ(ｉ)、その関数Ａがコールされた状態でさらに関数Ｂがコールされるときに、関数ＡのリターンアドレスReAdd(Ａ)がコールスタックに積まれる(ii)。さらに関数Ｂがコールされた状態でさらに関数Ｃがコールされると、コールスタックに関数ＢのリターンアドレスReAdd（Ｂ）が積まれる(iii)。つまり、関数Ｃを実行中のコールスタックの状態は、ReAdd（Ａ）とRetAdd（Ｂ）が積まれた状態である。そして、関数Ｃの実行が終わると、コールスタックに積まれた最上位のリターンアドレスReAdd（Ｂ）がコールスタックから取り出されることにより(iv)、関数Ｂにリターンし、その関数Ｂの実行が終わると、最上位のリターンアドレスReAdd（Ａ）がコールスタックから取り出されて(ｖ)、関数Ａにリターンする。このように、ソフトウェア挙動取得手段２１０は、コールスタックの状態の変化を調べることにより、監視対象ソフトウェアがコールおよびリターンするサブルーチンを推測することができる。また、監視対象ソフトウェアにおいて実行中の関数（サブルーチン）のリターンアドレスは、コールスタックには積まれていないので、その場合は、ソフトウェア挙動取得手段２１０はレジスタに格納された値を取得する。
【００２２】
次に、コールスタックの構成の一例について図面を参照しつつ説明する。図４は、コールスタックの構成の一例を示す模式図である。コールスタックには、サブルーチン毎にスタックフレームが積まれている。これらの各スタックフレームは、変数や引数などのサブルーチンに関する各種情報を格納しているが、リターンアドレスはその中の一つの要素である。つまり、ソフトウェア挙動取得手段２１０がリターンアドレスを取得する場合には、コールスタックのどの位置にリターンアドレスが積まれているかを把握する必要がある。例えばｘ８６アーキテクチャのようなフレームポインタを利用するような場合、そのフレームポインタが、コールスタックにおいてリターンアドレスが積まれている格納アドレスを示すので、ソフトウェア挙動取得手段２１０はこの値を利用してリターンアドレスを取得することができる。また、ＡＲＭアーキテクチャのようにフレームポインタを利用しないものもあるが、この場合は、ソフトウェア挙動取得手段２１０は、各コードの先頭数命令を逆アセンブルすることによりコールスタックの積み方を調べて格納アドレスを取得する方法や、デバッグ情報を利用して格納アドレスを取得する方法が考えられる。
【００２３】
ソフトウェア挙動取得手段２１０がリターンアドレスを取得するタイミングは、例えば、予め定められた時間が経過するたびであってもよく、また、例えば、システムコールが発行されるたびであってよく、また、例えば、インストラクションが発行されるたびであってもよい。また、ソフトウェア挙動取得手段２１０はこれらのタイミングを組み合わせて用いるようにしてもよい。具体的には、例えば、システムコールが発行されるたびにリターンアドレスを取得する場合、Ｌｉｎｕｘ（登録商標）の場合は、システムコールはptraceを利用して取得することができるし、また、カーネルを改変してトレース機能を埋め込んでおくことでリターンアドレスを取得するようにしてもよい。また、Ｗｉｎｄｏｗｓ（登録商標）で利用する場合は、システムコールはＡＰＩと呼ばれており、或るＡＰＩが呼び出される際にそこに割り込むＡＰＩフックを実現することができるから、この割り込みを利用してリターンアドレスを取得してもよい。
【００２４】
図２の説明に戻る。モデル取得手段２２０は、ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを作成し、作成した挙動モデルデータを挙動モデル記憶領域３０５１に記憶する。モデル取得手段２２０は、監視対象ソフトウェアが実行されているときにリアルタイムで挙動モデルデータを生成するようにしてもよく、また、例えば、監視対象ソフトウェアが実行される前に挙動モデルデータの生成処理を済ませておくようにしてもよい。また、モデル取得手段２２０がこの挙動モデルデータの生成処理を行うタイミングは、例えば、予め定められた単位時間が経過する毎に行うようにしてもよく、また、例えば、予め定められた日時に行うようにしてもよい。また、例えば、入力部３０４からの指示に応じて挙動モデルデータを生成するようにしてもよい。ソフトウェアの挙動とは、前述したように、ＣＰＵ３０１がそのソフトウェアに記述された手順に従って処理を行うときの、そのＣＰＵ３０１による処理内容のことであるが、ここでは特に、ソフトウェア挙動取得手段２１０が取得するリターンアドレスに関する情報（例えばリターンアドレスの列や、リターンアドレスとシステムコールの種別との組み合わせ等を含む）を、ソフトウェア挙動を表わす挙動モデルデータとする。
【００２５】
より、具体的には、モデル取得手段２２０が挙動モデルデータを生成する際、例えばソフトウェア挙動（リターンアドレス）の種類を表す挙動モデルデータを生成し、さらに、ソフトウェア挙動の種類ごとの出現頻度や出現順をその挙動モデルデータに含めるようにしてもよい。例えば、出現順を記録する場合は、ある時点でコールスタックにつまれているリターンアドレスを、ソフトウェアの実行を開始したときからカウントされる出現順と共に記録しておき、そのリターンアドレス及び出現順のセットを集めたものをモデルとする方法や、取得されるリターンアドレス全てをソフトウェアの実行を開始したときからカウントされる出現順に並べ、N（Nは任意の自然数）個ずつをセットとしてモデルとする方法がある。さらに、ある時点でコールスタックに積まれているリターンアドレス列と別の時点でコールスタックに積まれているリターンアドレス列との差分を取得し、これを集めたものをモデルとしてもよい。また、リターンアドレスだけでなく、システムコールの種類も利用することができる。例えば、あるシステムコールが発行されたときのリターンアドレスもしくはリターンアドレス列という組み合わせをモデルとしてもよい。
【００２６】
モデル取得手段２２０によって生成される挙動モデルデータは、監視対象ソフトウェアの正常な挙動をできる限り網羅的に含んでいる必要がある。そのため、モデル取得手段２２０がソフトウェアの挙動を取得するときには監視対象ソフトウェアの機能を網羅的に利用するように動作させる。また、モデル取得手段２２０は、監視対象ソフトウェアを実際に動かさなくても、オートマトン等の利用によりソースコード等を利用して静的にソフトウェア挙動を取得することが可能であるから、この方法を利用して挙動モデルデータの作成を行ってもよい。
【００２７】
次に、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたソフトウェア挙動データと、モデル取得手段２２０によって得られた挙動モデルデータとを比較し、その比較結果に応じて、監視対象ソフトウェアの挙動が異常か否かを判定する。この判定は、挙動モデルデータによって表されるモデルにある挙動は正常とし、そのモデルにない挙動は異常としてもよいし、そのモデルにある挙動と類似した挙動を正常とし、類似していない挙動を異常としてもよい。類似した挙動であるかどうかを判断する手法として、例えば、挙動に関してあるルールを決めておき、監視対象ソフトウェアの挙動がそのルールに合っているかを判断する方法が考えられる。例えばリターンアドレス列を挙動とし、リターンアドレスＡのあとにＢがあれば正常というルールを挙動モデルデータで表している場合、リターンアドレス列Ａ→Ｂ→Ｘが実際に得られたときには、その挙動モデルデータが表すルールに合致するＡ→Ｂが含まれているので正常と判断するといったような方法が利用できる。このように、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレス列とモデル取得手段２２０によって取得されたリターンアドレス列との一致度が予め定められた条件を満たすか否かにより、不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定してもよい。より具体的には、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレスの少なくとも一部が、モデル取得手段２２０によって取得された複数の挙動モデルデータのうちのいずれかと一致する場合に、不正処理の検知対象となるソフトウェアの挙動が正常であると判定するようにしてもよい。また、システムコールを利用したルール作成を行ってもよい。例えば、あるシステムコールＳ１が呼ばれたときにコールスタックにはリターンアドレスaが必要というルールを利用することができる。ルールの作成には、モデル作成時に得られた挙動の統計を利用することができる。
【００２８】
また、挙動モデルデータとして、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列と当該リターンアドレス列が格納されているタイミングと異なるタイミングにおいてコールスタックに格納されているリターンアドレス列との差分を表すデータを用いる場合には、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレスの列と上記予め定められたタイミングにおいてコールスタックに格納されているリターンアドレス列との差分を特定し、特定した差分とモデル取得手段２２０によって取得された挙動モデルデータとを比較することによって判定を行う。
【００２９】
ところで、バッファオーバーフローと呼ばれる不正な攻撃手法の主流は、コールスタックのリターンアドレスを書き換え、攻撃者が実行したい悪意あるコードへと処理フローを変えるというものである。図５は、バッファオーバーフローによる攻撃時のあるスタックフレームの様子を示したものであり、図５（ａ）はtmp変数の格納領域が確保されている状態を示し、図５（ｂ）はtmp変数が記録された状態を示す。図５（ａ）のようにtmp変数の格納領域には8バイトの領域が確保されているが、この変数のサイズをチェックしないという脆弱性を有するソフトウェアでは、tmp変数として8バイトを超える非常に大きな値を入れることができてしまう。このように、非常に大きいtmp変数がスタックフレームに格納されたことで、図５（ｂ）のように、その先のリターンアドレスが書き換えられてしまう（スタックは図中上から下へと使われる）。この例ではリターンアドレスＡが正常なリターン先であり、リターンアドレスＸは悪意あるルーチンへのリターン先である。こうすることで、このスタックフレームがコールスタックに積まれたときに悪意あるコードに処理を移すことが可能となる。このように、実行前にコールスタックのデータが上書きされ、且つ、システムコールのみが監視されている場合、上記のような不正なリターンアドレスの書き換えは検知できず、悪意あるルーチンが実行されたときに初めて異常が検知される。これに対し、本実施形態によれば、システムコールのみを監視するのではなく、システムコールの呼び出しの有無に関わらずコールスタックに積まれたリターンアドレスを用いて監視対象ソフトウェアの挙動が正常かを判定するから、悪意あるルーチンにリターンされる前に書き換えを検知でき、被害を未然に防ぐことが可能となる。
【００３０】
異常判定情報取得手段２４０は、異常度合い判定手段２３０により異常の度合いが高い、つまり、監視対象ソフトウェが不正なソフトウェアの可能性があると判断された場合、不正処理検知に必要な情報を取得する。必要な情報とは、リターンアドレスの指すアドレスに格納された情報が利用できる。
【００３１】
次に、不正検査手段１２０による処理に移行する。この不正検査手段１２０は、不正処理定義取得手段２５０及び異常判定手段２６０で構成される。
まず、不正処理定義取得手段２５０は、不正処理定義記憶領域３０５２から不正処理定義データを取得する。次に、異常判定手段２６０は異常判定情報取得手段２４０により得られた情報から、ソフトウェアの処理内容を調べ、その処理が不正処理定義取得手段２５０により取得された不正処理定義に含まれているかどうかを調べる。具体的には、異常判定手段２６０は、異常判定情報取得手段２４０が取得したリターンアドレスが示す格納領域に記憶されているデータを読み出し、異常発生時点でのソフトウェアの処理の内容を特定し、その内容が不正処理定義取得手段２５０により取得された不正処理定義に含まれているかどうかを調べる。含まれていない場合は何もせずにソフトウェアの実行を続け、含まれている場合は、異常が発生したと判断する。
【００３２】
このように、異常判定手段２６０は、異常度合い判定手段２３０によって正常でないと判定された場合に、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレスに対応するコード（オブジェクトコード等）を解析し、解析結果から特定される処理の内容と、不正処理定義記憶領域３０５２に記憶された不正処理定義データとを比較することによって、不正な処理を検知する。不正処理が検知された場合には、その旨を表示部を用いてユーザに通知してもよいし、監視対象ソフトウェアに実行を停止してもよい。また、ユーザには知らせず、その情報をホストとなる外部装置に対し、入力部３０４を介して通知してもよい。以上説明したように本実施形態によれば、ソフトウェア挙動異常検知手段１１０がフィルタリングによってソフトウェアが不正である可能性があるか否かを判断することによって、誤検知の可能性があるものをできるだけ除外して不正処理の検査の対象とするから、誤検知を低減することができる。
【００３３】
＜変形例＞
上述した実施形態は以下のような変形が可能である。なお、これらの各変形を適宜に組み合わせてもよい。
（１）上述の実施形態では、コンピュータ装置３００の機能的構成の一例として図２を例示したが、コンピュータ装置３００の機能的構成はこれに限らず、他の構成であってもよい。例えば、異常判定情報取得手段２４０が不正検査手段１２０に含まれる構成であってもよい。
【００３４】
（２）上述の実施形態では、モデル取得手段２２０がソフトウェアを正常に動作させたときのソフトウェア挙動から挙動モデルデータを作成したが、これに限らず、挙動モデルデータを予めコンピュータ装置３００の記憶部３０５に記憶しておくようにしてもよい。また、上述の実施形態では、モデル取得手段２２０が挙動モデルデータを作成したが、これに限らず、他の装置で挙動モデルデータの作成処理を行うようにしてもよい。この場合は、挙動モデルデータを生成した装置がコンピュータ装置３００へ挙動モデルデータを送信するようにし、コンピュータ装置３００は、他の装置から受信される挙動モデルデータを用いてソフトウェア挙動の異常判定処理を行う。
【００３５】
（３）上述の実施形態では、ビヘイビア法による不正検知を行うに先立ってソフトウェア挙動のフィルタリングを行うようにしたが、不正検知を行う手法はビヘイビア法に限らず、他の手法を用いて不正検知を行うようにしてもよい。要は、不正検知処理を実行するに先立って、ソフトウェア挙動のフィルタリングを行うものであればよい。
例えば、リターン先がライブラリであることを不正処理定義データとして用いてもよい。リターンアドレスを書き換えてリターン先をライブラリに変更することにより攻撃を行う、return-to-libc攻撃と呼ばれるものがあり、その一例として、例えばLinux（登録商標）のsystem関数を、引数を/bin/shとしてコールすることにより、攻撃者がシェルを実行する、という不正行為が知られている。このような攻撃を見つけるために、リターン先がライブラリである場合に不正処理であると検出するようにしてもよい。
【００３６】
（４）上述の実施形態では、不正処理定義記憶領域３０５２に不正な処理の内容を表すデータを予め記憶しておく構成としたが、これに限らず、正常な処理の内容を表すデータを予め記憶しておく構成とし、記憶された正常な処理と一致する場合にソフトウェア挙動が正常であるとＣＰＵ３０１が判定するようにしてもよい。
【００３７】
（５）上述の実施形態では、不正処理定義取得手段２５０と異常判定手段２６０とがコンピュータ装置３００に含まれる構成の例について説明したが、これに限らず、コンピュータ装置３００と通信ネットワーク等を介して接続されたサーバ装置が、不正処理定義取得手段２５０と異常判定手段２６０とを備える構成であってもよい。この場合は、コンピュータ装置３００は、異常判定情報取得手段２４０によって取得された情報をサーバ装置に通知し、サーバ装置が、コンピュータ装置３００から通知された情報を用いて不正処理の検出処理を実行する。また、サーバ装置で情報を収集する場合は、複数のコンピュータ装置からの情報を集約し、統計を取ってもよい。例えば、同じ内容の通知がたくさん集まった場合は、すぐに対処すべき等の判断に利用できる。
【００３８】
（６）上述の実施形態では、コンピュータ装置３００の記憶部３０５が、挙動モデル記憶領域３０５１及び不正処理定義記憶領域３０５２を備える構成となっていたが、これに限らず、コンピュータ装置３００が、挙動モデル記憶領域や不正処理定義記憶領域３０５２を備えるサーバ装置と、通信ネットワーク等を介して接続されている構成であってもよい。この場合は、コンピュータ装置３００は、通信ネットワーク等を介して接続されたサーバ装置にアクセスして、挙動モデルデータや不正処理定義データを受信するようにすればよい。
【００３９】
（７）上述の実施形態では、図２に示したソフトウェア挙動異常検知手段１１０と、不正検査手段１２０とは、ＣＰＵ３０１がそれぞれ異なるプログラムを実行することによって実現されるようにしたが、これに限らず、ソフトウェア挙動異常検知手段１１０と不正検査手段１２０とがひとつのプログラムによって実現される構成であってもよい。
【００４０】
（８）上述の実施形態におけるコンピュータ装置３００のＣＰＵ３０１によって実行されるプログラムは、磁気記録媒体（磁気テープ、磁気ディスクなど）、光記録媒体（光ディスクなど）、光磁気記録媒体、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で提供し得る。また、インターネットのようなネットワーク経由でコンピュータ装置３００にダウンロードさせることも可能である。なお、このような制御を行う制御手段としてはＣＰＵ以外にも種々の装置を適用することができ、例えば、専用のプロセッサなどを用いてもよい。
【符号の説明】
【００４１】
１１０…ソフトウェア挙動異常検知手段、１２０…不正検査手段、２１０…ソフトウェア挙動取得手段、２２０…モデル取得手段、２３０…異常度合い判定手段、２４０…異常判定情報取得手段、２５０…不正処理定義取得手段、２６０…異常判定手段、３００…コンピュータ装置、３０１…ＣＰＵ、３０２…ＲＡＭ、３０３…ＲＯＭ、３０４…入力部、３０５…記憶部。
【技術分野】
【０００１】
本発明は、ソフトウェアが実行されるときの挙動を利用して不正処理を検知する技術に関する。
【背景技術】
【０００２】
パーソナルコンピュータ（以下、ＰＣという）等の計算機器は、コンピュータウィルス（以下、ウィルスという）による攻撃にさらされている。ＰＣに対するウィルスによる被害は年々増加し、さらに悪質化している。例えば、以前はいたずらを目的としたウィルスが主流であったが、近年では金銭目的のウィルスが増加している。さらにウィルスはＰＣのみでなく携帯電話機にも感染する恐れがある。実際、携帯電話機に対するウィルス被害が報告されている。また、携帯電話機はＰＣよりも多くの個人情報を多く含んでいる可能性が高く、特に高機能化された携帯電話機では電子マネーなど価値の高い情報が多く含まれていることもある。
【０００３】
現在、ＰＣ向けのウィルス対策技術としては、ウィルススキャンと呼ばれる手法が主流となっている。この手法では、ウィルスの特徴点をパターンデータとして予め記録しておき、検査時にはこのパターンデータとマッチするものがないかを調べる。そのため、新種ウィルス等のパターンデータが定義されていない未知のウィルスは検知することができず、新たなパターンデータが追加されるまでの期間に被害が拡大してしまうという問題点を有している。そこで、既知のパターンデータとの照合によりウィルスを発見するのではなく、ソフトウェアが実行されているときの挙動を解析し、異常が発生していないかを調べる方法が検討されている。例えば、ウィルスがよく行う処理（例えば、ウィルス自身をコピーするという処理など）を予め登録しておき、その処理をしたときに異常と判断する、というビヘイビア法がある。また、ソフトウェアの正常な挙動を予め学習して正常モデルを作成し、実行時にこれと異なる挙動が発見されたら異常と判断する方法もある。
【０００４】
例えば特許文献１には、コンピュータウィルスや不正アクセスを抑制することを目的として、オペレーティングシステムが、プログラムから要求されたＡＰＩ（Application Program Interface）を実行する前に、メモリ装置上におけるプログラムの格納アドレスを取得し、そのアドレスが適正な位置を示しているか否かを比較判定することにより、ＡＰＩをコールしたプログラムが適正か不正かを判断する技術が提案されている。また、特許文献２には、バッファオーバーフローによるリターンアドレスの改ざんを防止するために、プログラムが実行されてリターンアドレスが書き換えられた場合、中央演算処理装置のデバッグ機能を利用してリターンアドレスの改ざんを検知し、予め保存された値で改ざんされたリターンアドレスを書き直し、プログラムを正常な動作に戻す技術が提案されている。また、特許文献３には、システムコールやＡＰＩ関数にブレークポイントを設定してシステムコールなどの呼び出しを監視し、監視対象プロセスの振る舞い（処理）と過去のコンピュータウィルスの特徴的な振る舞い（処理）とを比較することにより、コンピュータウィルスによるデータ改ざん等を防止する技術が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】国際公開第２００５／０２９３２８号
【特許文献２】国際公開第２００５／０２４６３０号
【特許文献３】国際公開第２００４／０７５０６０号
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、ビヘイビア法では、ウィルスがよく行う処理を正常なソフトウェアが実行することもあるため、正常か異常かを正確に判断することは非常に難しい。そのため、異常が発生していないのに異常であると判断してしまう誤検知が発生し、ユーザの利便性を悪化させる。また、正常モデルを利用する方法では、ソフトウェアの挙動を全てモデル化することは一般に困難であり、特にユーザインタラクションがある場合はソフトウェアの挙動の数は無限に近くなる。そのため、正常モデルから外れる挙動を全て異常と判断してしまい、誤検知が発生するという問題を解消することはできない。
【０００７】
本発明は、コンピュータウィルスなどによる不正処理を検知する場合において誤検知の発生を軽減することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、本発明は、ソフトウェアを実行する実行手段と、ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを複数記憶する挙動モデルデータ記憶手段と、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを複数記憶する不正処理定義データ記憶手段と、不正処理の検知対象となるソフトウェアが前記実行手段によって実行されるときにコールスタックに格納されるリターンアドレスを取得するリターンアドレス取得手段と、前記リターンアドレス取得手段によって取得されたリターンアドレスと、前記挙動モデルデータ記憶手段に記憶された各挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する挙動判定手段と、前記挙動判定手段によって正常でないと判定された場合に、前記リターンアドレス取得手段によって取得されたリターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された各不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知する不正処理検知手段とを具備することを特徴とする不正処理検知装置を提供する。
【０００９】
本発明の好ましい態様において、前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を前記挙動モデルデータとして複数記憶し、前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたリターンアドレス列との一致度が予め定められた条件を満たすか否かにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定してもよい。
【００１０】
また、本発明の別の好ましい態様において、前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列と当該リターンアドレス列が格納されているタイミングと異なるタイミングにおいて前記コールスタックに格納されているリターンアドレス列との差分を表すデータを前記挙動モデルデータとして複数記憶し、前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記異なるタイミングにおいて前記コールスタックに格納されている各リターンアドレスからなるリターンアドレス列との差分を、前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたデータと比較することにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定してもよい。
【００１１】
また、本発明の別の好ましい態様において、前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレスの少なくとも一部が、前記挙動モデルデータ記憶手段に記憶された複数の挙動モデルデータのうちのいずれかと一致する場合に、前記不正処理の検知対象となるソフトウェアの挙動が正常であると判定してもよい。
【発明の効果】
【００１２】
本発明によれば、不正処理を検知する場合において誤検知の発生を軽減することができる。
【図面の簡単な説明】
【００１３】
【図１】コンピュータ装置のハードウェア構成の一例を示すブロック図である。
【図２】異常検知装置の構成例を示すブロック図である。
【図３】コールスタックの変化の一例を示す模式図である。
【図４】コールスタックの構成の一例を示す模式図である。
【図５】バッファオーバーフロー攻撃時のコールスタックの変化の一例を示す模式図である。
【発明を実施するための形態】
【００１４】
本発明を実施するための形態について説明する。なお、以下の説明において、「ソフトウェア」を動作の主体として表現することがあるが、これは、その「ソフトウェア」に記述された手順を実行するＣＰＵ（Central Processing Unit）が動作の主体であることを意味している。
図１は、この発明の一実施形態に係る不正処理検知装置としてのコンピュータ装置３００の構成の一例を示すブロック図である。このコンピュータ装置３００は、どのようなコンピュータ装置であってもよく、例えばパーソナルコンピュータやサーバ装置のほか、携帯電話機やＰＤＡ（Personal Digital Assistants）などを含む。図において、ＣＰＵ３０１は、ＲＯＭ（Read Only Memory）３０３又は記憶部３０５に格納されたコンピュータプログラムを、ＲＡＭ（Random Access Memory）３０２をワークエリアとして実行することによって、コンピュータ装置３００の制御を行う。記憶部３０５は、ハードディスク等の記憶手段であり、コンピュータ装置３００の制御に関するプログラム等の各種プログラムが格納されている。入力部３０４は、外部装置と通信する通信手段である。ここにおいて、外部装置とは、例えば、外付けのフロッピー（登録商標）ディスクドライバやハードディスクなどの記録装置や、ネットワークを介して接続されるサーバ装置等である。入力部３０４は、外部装置と有線により通信を行ってもよいし、無線により通信を行ってもよい。なお、コンピュータ装置３００は、図１に示した構成以外に、例えば表示を行う表示部や利用者の操作を受け付ける操作部などの他の構成を有していてもよい。
【００１５】
コンピュータ装置３００の記憶部３０５には、ＯＳ（Operating System）プログラム（図示略）が記憶されているほかに、監視対象ソフトウェアプログラムＰＲＧ１と、ソフトウェア挙動異常検知プログラムＰＲＧ２と、不正検査プログラムＰＲＧ３とが記憶されている。なお、以下の説明では、説明の便宜上、コンピュータ装置３００のＣＰＵ３０１が記憶部３０５に記憶されたプログラムを実行することを、「ソフトウェアを実行する」という。また、記憶部３０５は、挙動モデル記憶領域３０５１と、不正処理定義記憶領域３０５２とを有している。挙動モデル記憶領域３０５１には、ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータが複数記憶される。ソフトウェアの挙動とは、ＣＰＵ３０１がそのソフトウェアに記述された手順に従って処理を行うときの、そのＣＰＵ３０１による処理内容のことである。この挙動モデルデータの内容は後述するため、ここではその詳細な説明を省略する。
【００１６】
次に、不正処理定義記憶領域３０５２には、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データが複数記憶されている。この不正処理定義データは、ウィルス等を原因とする不正な処理を検出する際に参照されるデータである。例えば、ウィルスである可能性が高い処理の特徴がリスト形式で列挙されたものが、不正処理定義データとして用いられる。具体的には、例えば、以下の（１）乃至（５）のような処理の内容を表すデータが不正処理定義データとして用いられる。
（１）ディスクをフォーマット、（２）自分自身を他へコピー、（３）実行ファイル書き換え、（４）メール大量送信、（５）特定のＴＣＰ（Transmission Control Protocol）ポートから発信
これらの不正処理定義データの内容は、いわゆるビヘイビア法において事前にソフトウェアが実行されているときの挙動を解析する手法を用いて特定されたものである。
【００１７】
次に、コンピュータ装置３００の機能的構成について図２を参照しつつ説明する。図２は、コンピュータ装置３００の機能的構成の一例を示す図である。図において、ソフトウェア実行手段１０は、コンピュータ装置３００のＣＰＵ３０１が記憶部３０５に記憶されている監視対象ソフトウェアプログラムＰＲＧ１を読み出して実行することによって実現される。また、ソフトウェア挙動異常検知手段１１０は、ＣＰＵ３０１が記憶部３０５に記憶されているソフトウェア挙動異常検知プログラムＰＲＧ２を読み出して実行することによって実現される。不正検査手段１２０は、ＣＰＵ３０１が記憶部３０５に記憶されている不正検査プログラムＰＲＧ３を読み出して実行することによって実現される。ソフトウェア実行手段１０は、監視対象となるソフトウェアを実行する手段であるが、図２においては、図が煩雑になるのを防ぐために、１つのソフトウェア実行手段１０のみを図示している。監視対象となるソフトウェアの数は１に限らず複数であってもよいから、ＣＰＵ３０１が複数のソフトウェアを並列的に実行している場合には、ソフトウェア実行手段１０は複数構成されることになる。
【００１８】
不正検査手段１２０は、ウィルス等による不正処理を検知する手段である。不正検査手段１２０は、不正処理定義記憶領域３０５２に記憶されている不正処理定義データを用い、ビヘイビア法に従って不正処理を検出する。ソフトウェア挙動異常検知手段１１０は、不正検査手段１２０がソフトウェアによる不正処理を検知する処理を行う前に、そのソフトウェアの挙動をフィルタリングする手段である。本実施形態ではソフトウェア挙動異常検知手段１１０がこのフィルタリングによってソフトウェアが不正である可能性があるか否かを判断し、不正検査手段１２０が、その可能性があるソフトウェアについてのみ不正処理の検知を行うという２段階の処理工程を経ることで、そのような２段階の処理工程を経ない場合と比べて、誤検知を低減することが可能となっている。
【００１９】
ソフトウェア挙動異常検知手段１１０は、ソフトウェア実行手段１０によって実行されている監視対象となるソフトウェア（以下「監視対象ソフトウェア」という）の挙動を表すデータ（以下「ソフトウェア挙動データ」という）を取得し、取得したソフトウェア挙動データを用いてソフトウェアの挙動が異常か否かを判定し、その判定結果を出力する。このソフトウェア挙動異常検知手段１１０は、ソフトウェア挙動取得手段２１０、モデル取得手段２２０、異常度合い判定手段２３０、及び異常判定情報取得手段２４０から構成されている。以下、これらの各手段の機能を説明する。
【００２０】
まず、ソフトウェア挙動取得手段２１０は、監視対象ソフトウェアの挙動を表すソフトウェア挙動データを取得する。ここでは、ソフトウェア挙動取得手段２１０は、ソフトウェアの挙動を表すソフトウェア挙動データとして、不正処理の検知対象となるソフトウェア（監視対象ソフトウェア）がソフトウェア実行手段１０によって実行されるときにコールスタックに格納されるリターンアドレスを取得する。コールスタックには、監視対象ソフトウェアに記述されたサブルーチンのうち、呼び出し元から呼び出された（コールされた）サブルーチンのリターンアドレスなどの情報が積まれており、監視対象ソフトウェアはこのリターンアドレスを元に、呼び出し元に戻る（リターンする）。なお、コールスタックにリターンアドレスを積む、とは、コールスタックに対し新たにリターンアドレスを格納するという意味である。このように、ソフトウェア挙動取得手段２１０は、ソフトウェア実行手段１０によって実行されている監視対象ソフトウェアが利用するリターンアドレスを取得する。
【００２１】
ここで、コールスタックに積まれるリターンアドレスの内容の一例について図面を参照しつつ説明する。図３（ａ）はソースコードの内容の一例を示す図であり、図３（ｂ）はコールスタックに積まれるリターンアドレスの一例を示す図である。
例えば図３（ａ）に示すようなソースコードを有するソフトウェアをＣＰＵが実行したとき、コールスタックの状態は図３（ｂ）のように変化する。図３（ａ）における（ｉ）〜（ｖ）と、図３（ｂ）における（ｉ）〜（ｖ）とは対応しており、例えば図３（ａ）の（ｉ）のソースコードを実行しているときのコールスタックの状態は図３（ｂ）の（ｉ）である。順を追って説明すると、まず、ソフトウェアにより、サブルーチンに相当する関数Ａがコールされ(ｉ)、その関数Ａがコールされた状態でさらに関数Ｂがコールされるときに、関数ＡのリターンアドレスReAdd(Ａ)がコールスタックに積まれる(ii)。さらに関数Ｂがコールされた状態でさらに関数Ｃがコールされると、コールスタックに関数ＢのリターンアドレスReAdd（Ｂ）が積まれる(iii)。つまり、関数Ｃを実行中のコールスタックの状態は、ReAdd（Ａ）とRetAdd（Ｂ）が積まれた状態である。そして、関数Ｃの実行が終わると、コールスタックに積まれた最上位のリターンアドレスReAdd（Ｂ）がコールスタックから取り出されることにより(iv)、関数Ｂにリターンし、その関数Ｂの実行が終わると、最上位のリターンアドレスReAdd（Ａ）がコールスタックから取り出されて(ｖ)、関数Ａにリターンする。このように、ソフトウェア挙動取得手段２１０は、コールスタックの状態の変化を調べることにより、監視対象ソフトウェアがコールおよびリターンするサブルーチンを推測することができる。また、監視対象ソフトウェアにおいて実行中の関数（サブルーチン）のリターンアドレスは、コールスタックには積まれていないので、その場合は、ソフトウェア挙動取得手段２１０はレジスタに格納された値を取得する。
【００２２】
次に、コールスタックの構成の一例について図面を参照しつつ説明する。図４は、コールスタックの構成の一例を示す模式図である。コールスタックには、サブルーチン毎にスタックフレームが積まれている。これらの各スタックフレームは、変数や引数などのサブルーチンに関する各種情報を格納しているが、リターンアドレスはその中の一つの要素である。つまり、ソフトウェア挙動取得手段２１０がリターンアドレスを取得する場合には、コールスタックのどの位置にリターンアドレスが積まれているかを把握する必要がある。例えばｘ８６アーキテクチャのようなフレームポインタを利用するような場合、そのフレームポインタが、コールスタックにおいてリターンアドレスが積まれている格納アドレスを示すので、ソフトウェア挙動取得手段２１０はこの値を利用してリターンアドレスを取得することができる。また、ＡＲＭアーキテクチャのようにフレームポインタを利用しないものもあるが、この場合は、ソフトウェア挙動取得手段２１０は、各コードの先頭数命令を逆アセンブルすることによりコールスタックの積み方を調べて格納アドレスを取得する方法や、デバッグ情報を利用して格納アドレスを取得する方法が考えられる。
【００２３】
ソフトウェア挙動取得手段２１０がリターンアドレスを取得するタイミングは、例えば、予め定められた時間が経過するたびであってもよく、また、例えば、システムコールが発行されるたびであってよく、また、例えば、インストラクションが発行されるたびであってもよい。また、ソフトウェア挙動取得手段２１０はこれらのタイミングを組み合わせて用いるようにしてもよい。具体的には、例えば、システムコールが発行されるたびにリターンアドレスを取得する場合、Ｌｉｎｕｘ（登録商標）の場合は、システムコールはptraceを利用して取得することができるし、また、カーネルを改変してトレース機能を埋め込んでおくことでリターンアドレスを取得するようにしてもよい。また、Ｗｉｎｄｏｗｓ（登録商標）で利用する場合は、システムコールはＡＰＩと呼ばれており、或るＡＰＩが呼び出される際にそこに割り込むＡＰＩフックを実現することができるから、この割り込みを利用してリターンアドレスを取得してもよい。
【００２４】
図２の説明に戻る。モデル取得手段２２０は、ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを作成し、作成した挙動モデルデータを挙動モデル記憶領域３０５１に記憶する。モデル取得手段２２０は、監視対象ソフトウェアが実行されているときにリアルタイムで挙動モデルデータを生成するようにしてもよく、また、例えば、監視対象ソフトウェアが実行される前に挙動モデルデータの生成処理を済ませておくようにしてもよい。また、モデル取得手段２２０がこの挙動モデルデータの生成処理を行うタイミングは、例えば、予め定められた単位時間が経過する毎に行うようにしてもよく、また、例えば、予め定められた日時に行うようにしてもよい。また、例えば、入力部３０４からの指示に応じて挙動モデルデータを生成するようにしてもよい。ソフトウェアの挙動とは、前述したように、ＣＰＵ３０１がそのソフトウェアに記述された手順に従って処理を行うときの、そのＣＰＵ３０１による処理内容のことであるが、ここでは特に、ソフトウェア挙動取得手段２１０が取得するリターンアドレスに関する情報（例えばリターンアドレスの列や、リターンアドレスとシステムコールの種別との組み合わせ等を含む）を、ソフトウェア挙動を表わす挙動モデルデータとする。
【００２５】
より、具体的には、モデル取得手段２２０が挙動モデルデータを生成する際、例えばソフトウェア挙動（リターンアドレス）の種類を表す挙動モデルデータを生成し、さらに、ソフトウェア挙動の種類ごとの出現頻度や出現順をその挙動モデルデータに含めるようにしてもよい。例えば、出現順を記録する場合は、ある時点でコールスタックにつまれているリターンアドレスを、ソフトウェアの実行を開始したときからカウントされる出現順と共に記録しておき、そのリターンアドレス及び出現順のセットを集めたものをモデルとする方法や、取得されるリターンアドレス全てをソフトウェアの実行を開始したときからカウントされる出現順に並べ、N（Nは任意の自然数）個ずつをセットとしてモデルとする方法がある。さらに、ある時点でコールスタックに積まれているリターンアドレス列と別の時点でコールスタックに積まれているリターンアドレス列との差分を取得し、これを集めたものをモデルとしてもよい。また、リターンアドレスだけでなく、システムコールの種類も利用することができる。例えば、あるシステムコールが発行されたときのリターンアドレスもしくはリターンアドレス列という組み合わせをモデルとしてもよい。
【００２６】
モデル取得手段２２０によって生成される挙動モデルデータは、監視対象ソフトウェアの正常な挙動をできる限り網羅的に含んでいる必要がある。そのため、モデル取得手段２２０がソフトウェアの挙動を取得するときには監視対象ソフトウェアの機能を網羅的に利用するように動作させる。また、モデル取得手段２２０は、監視対象ソフトウェアを実際に動かさなくても、オートマトン等の利用によりソースコード等を利用して静的にソフトウェア挙動を取得することが可能であるから、この方法を利用して挙動モデルデータの作成を行ってもよい。
【００２７】
次に、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたソフトウェア挙動データと、モデル取得手段２２０によって得られた挙動モデルデータとを比較し、その比較結果に応じて、監視対象ソフトウェアの挙動が異常か否かを判定する。この判定は、挙動モデルデータによって表されるモデルにある挙動は正常とし、そのモデルにない挙動は異常としてもよいし、そのモデルにある挙動と類似した挙動を正常とし、類似していない挙動を異常としてもよい。類似した挙動であるかどうかを判断する手法として、例えば、挙動に関してあるルールを決めておき、監視対象ソフトウェアの挙動がそのルールに合っているかを判断する方法が考えられる。例えばリターンアドレス列を挙動とし、リターンアドレスＡのあとにＢがあれば正常というルールを挙動モデルデータで表している場合、リターンアドレス列Ａ→Ｂ→Ｘが実際に得られたときには、その挙動モデルデータが表すルールに合致するＡ→Ｂが含まれているので正常と判断するといったような方法が利用できる。このように、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレス列とモデル取得手段２２０によって取得されたリターンアドレス列との一致度が予め定められた条件を満たすか否かにより、不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定してもよい。より具体的には、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレスの少なくとも一部が、モデル取得手段２２０によって取得された複数の挙動モデルデータのうちのいずれかと一致する場合に、不正処理の検知対象となるソフトウェアの挙動が正常であると判定するようにしてもよい。また、システムコールを利用したルール作成を行ってもよい。例えば、あるシステムコールＳ１が呼ばれたときにコールスタックにはリターンアドレスaが必要というルールを利用することができる。ルールの作成には、モデル作成時に得られた挙動の統計を利用することができる。
【００２８】
また、挙動モデルデータとして、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列と当該リターンアドレス列が格納されているタイミングと異なるタイミングにおいてコールスタックに格納されているリターンアドレス列との差分を表すデータを用いる場合には、異常度合い判定手段２３０は、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレスの列と上記予め定められたタイミングにおいてコールスタックに格納されているリターンアドレス列との差分を特定し、特定した差分とモデル取得手段２２０によって取得された挙動モデルデータとを比較することによって判定を行う。
【００２９】
ところで、バッファオーバーフローと呼ばれる不正な攻撃手法の主流は、コールスタックのリターンアドレスを書き換え、攻撃者が実行したい悪意あるコードへと処理フローを変えるというものである。図５は、バッファオーバーフローによる攻撃時のあるスタックフレームの様子を示したものであり、図５（ａ）はtmp変数の格納領域が確保されている状態を示し、図５（ｂ）はtmp変数が記録された状態を示す。図５（ａ）のようにtmp変数の格納領域には8バイトの領域が確保されているが、この変数のサイズをチェックしないという脆弱性を有するソフトウェアでは、tmp変数として8バイトを超える非常に大きな値を入れることができてしまう。このように、非常に大きいtmp変数がスタックフレームに格納されたことで、図５（ｂ）のように、その先のリターンアドレスが書き換えられてしまう（スタックは図中上から下へと使われる）。この例ではリターンアドレスＡが正常なリターン先であり、リターンアドレスＸは悪意あるルーチンへのリターン先である。こうすることで、このスタックフレームがコールスタックに積まれたときに悪意あるコードに処理を移すことが可能となる。このように、実行前にコールスタックのデータが上書きされ、且つ、システムコールのみが監視されている場合、上記のような不正なリターンアドレスの書き換えは検知できず、悪意あるルーチンが実行されたときに初めて異常が検知される。これに対し、本実施形態によれば、システムコールのみを監視するのではなく、システムコールの呼び出しの有無に関わらずコールスタックに積まれたリターンアドレスを用いて監視対象ソフトウェアの挙動が正常かを判定するから、悪意あるルーチンにリターンされる前に書き換えを検知でき、被害を未然に防ぐことが可能となる。
【００３０】
異常判定情報取得手段２４０は、異常度合い判定手段２３０により異常の度合いが高い、つまり、監視対象ソフトウェが不正なソフトウェアの可能性があると判断された場合、不正処理検知に必要な情報を取得する。必要な情報とは、リターンアドレスの指すアドレスに格納された情報が利用できる。
【００３１】
次に、不正検査手段１２０による処理に移行する。この不正検査手段１２０は、不正処理定義取得手段２５０及び異常判定手段２６０で構成される。
まず、不正処理定義取得手段２５０は、不正処理定義記憶領域３０５２から不正処理定義データを取得する。次に、異常判定手段２６０は異常判定情報取得手段２４０により得られた情報から、ソフトウェアの処理内容を調べ、その処理が不正処理定義取得手段２５０により取得された不正処理定義に含まれているかどうかを調べる。具体的には、異常判定手段２６０は、異常判定情報取得手段２４０が取得したリターンアドレスが示す格納領域に記憶されているデータを読み出し、異常発生時点でのソフトウェアの処理の内容を特定し、その内容が不正処理定義取得手段２５０により取得された不正処理定義に含まれているかどうかを調べる。含まれていない場合は何もせずにソフトウェアの実行を続け、含まれている場合は、異常が発生したと判断する。
【００３２】
このように、異常判定手段２６０は、異常度合い判定手段２３０によって正常でないと判定された場合に、ソフトウェア挙動取得手段２１０によって取得されたリターンアドレスに対応するコード（オブジェクトコード等）を解析し、解析結果から特定される処理の内容と、不正処理定義記憶領域３０５２に記憶された不正処理定義データとを比較することによって、不正な処理を検知する。不正処理が検知された場合には、その旨を表示部を用いてユーザに通知してもよいし、監視対象ソフトウェアに実行を停止してもよい。また、ユーザには知らせず、その情報をホストとなる外部装置に対し、入力部３０４を介して通知してもよい。以上説明したように本実施形態によれば、ソフトウェア挙動異常検知手段１１０がフィルタリングによってソフトウェアが不正である可能性があるか否かを判断することによって、誤検知の可能性があるものをできるだけ除外して不正処理の検査の対象とするから、誤検知を低減することができる。
【００３３】
＜変形例＞
上述した実施形態は以下のような変形が可能である。なお、これらの各変形を適宜に組み合わせてもよい。
（１）上述の実施形態では、コンピュータ装置３００の機能的構成の一例として図２を例示したが、コンピュータ装置３００の機能的構成はこれに限らず、他の構成であってもよい。例えば、異常判定情報取得手段２４０が不正検査手段１２０に含まれる構成であってもよい。
【００３４】
（２）上述の実施形態では、モデル取得手段２２０がソフトウェアを正常に動作させたときのソフトウェア挙動から挙動モデルデータを作成したが、これに限らず、挙動モデルデータを予めコンピュータ装置３００の記憶部３０５に記憶しておくようにしてもよい。また、上述の実施形態では、モデル取得手段２２０が挙動モデルデータを作成したが、これに限らず、他の装置で挙動モデルデータの作成処理を行うようにしてもよい。この場合は、挙動モデルデータを生成した装置がコンピュータ装置３００へ挙動モデルデータを送信するようにし、コンピュータ装置３００は、他の装置から受信される挙動モデルデータを用いてソフトウェア挙動の異常判定処理を行う。
【００３５】
（３）上述の実施形態では、ビヘイビア法による不正検知を行うに先立ってソフトウェア挙動のフィルタリングを行うようにしたが、不正検知を行う手法はビヘイビア法に限らず、他の手法を用いて不正検知を行うようにしてもよい。要は、不正検知処理を実行するに先立って、ソフトウェア挙動のフィルタリングを行うものであればよい。
例えば、リターン先がライブラリであることを不正処理定義データとして用いてもよい。リターンアドレスを書き換えてリターン先をライブラリに変更することにより攻撃を行う、return-to-libc攻撃と呼ばれるものがあり、その一例として、例えばLinux（登録商標）のsystem関数を、引数を/bin/shとしてコールすることにより、攻撃者がシェルを実行する、という不正行為が知られている。このような攻撃を見つけるために、リターン先がライブラリである場合に不正処理であると検出するようにしてもよい。
【００３６】
（４）上述の実施形態では、不正処理定義記憶領域３０５２に不正な処理の内容を表すデータを予め記憶しておく構成としたが、これに限らず、正常な処理の内容を表すデータを予め記憶しておく構成とし、記憶された正常な処理と一致する場合にソフトウェア挙動が正常であるとＣＰＵ３０１が判定するようにしてもよい。
【００３７】
（５）上述の実施形態では、不正処理定義取得手段２５０と異常判定手段２６０とがコンピュータ装置３００に含まれる構成の例について説明したが、これに限らず、コンピュータ装置３００と通信ネットワーク等を介して接続されたサーバ装置が、不正処理定義取得手段２５０と異常判定手段２６０とを備える構成であってもよい。この場合は、コンピュータ装置３００は、異常判定情報取得手段２４０によって取得された情報をサーバ装置に通知し、サーバ装置が、コンピュータ装置３００から通知された情報を用いて不正処理の検出処理を実行する。また、サーバ装置で情報を収集する場合は、複数のコンピュータ装置からの情報を集約し、統計を取ってもよい。例えば、同じ内容の通知がたくさん集まった場合は、すぐに対処すべき等の判断に利用できる。
【００３８】
（６）上述の実施形態では、コンピュータ装置３００の記憶部３０５が、挙動モデル記憶領域３０５１及び不正処理定義記憶領域３０５２を備える構成となっていたが、これに限らず、コンピュータ装置３００が、挙動モデル記憶領域や不正処理定義記憶領域３０５２を備えるサーバ装置と、通信ネットワーク等を介して接続されている構成であってもよい。この場合は、コンピュータ装置３００は、通信ネットワーク等を介して接続されたサーバ装置にアクセスして、挙動モデルデータや不正処理定義データを受信するようにすればよい。
【００３９】
（７）上述の実施形態では、図２に示したソフトウェア挙動異常検知手段１１０と、不正検査手段１２０とは、ＣＰＵ３０１がそれぞれ異なるプログラムを実行することによって実現されるようにしたが、これに限らず、ソフトウェア挙動異常検知手段１１０と不正検査手段１２０とがひとつのプログラムによって実現される構成であってもよい。
【００４０】
（８）上述の実施形態におけるコンピュータ装置３００のＣＰＵ３０１によって実行されるプログラムは、磁気記録媒体（磁気テープ、磁気ディスクなど）、光記録媒体（光ディスクなど）、光磁気記録媒体、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で提供し得る。また、インターネットのようなネットワーク経由でコンピュータ装置３００にダウンロードさせることも可能である。なお、このような制御を行う制御手段としてはＣＰＵ以外にも種々の装置を適用することができ、例えば、専用のプロセッサなどを用いてもよい。
【符号の説明】
【００４１】
１１０…ソフトウェア挙動異常検知手段、１２０…不正検査手段、２１０…ソフトウェア挙動取得手段、２２０…モデル取得手段、２３０…異常度合い判定手段、２４０…異常判定情報取得手段、２５０…不正処理定義取得手段、２６０…異常判定手段、３００…コンピュータ装置、３０１…ＣＰＵ、３０２…ＲＡＭ、３０３…ＲＯＭ、３０４…入力部、３０５…記憶部。
【特許請求の範囲】
【請求項１】
ソフトウェアを実行する実行手段と、
ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを複数記憶する挙動モデルデータ記憶手段と、
ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを複数記憶する不正処理定義データ記憶手段と、
不正処理の検知対象となるソフトウェアが前記実行手段によって実行されるときにコールスタックに格納されるリターンアドレスを取得するリターンアドレス取得手段と、
前記リターンアドレス取得手段によって取得されたリターンアドレスと、前記挙動モデルデータ記憶手段に記憶された各挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する挙動判定手段と、
前記挙動判定手段によって正常でないと判定された場合に、前記リターンアドレス取得手段によって取得されたリターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された各不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知する不正処理検知手段と
を具備することを特徴とする不正処理検知装置。
【請求項２】
前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を前記挙動モデルデータとして複数記憶し、
前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、
前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたリターンアドレス列との一致度が予め定められた条件を満たすか否かにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する
ことを特徴とする請求項１に記載の不正処理検知装置。
【請求項３】
前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列と当該リターンアドレス列が格納されているタイミングと異なるタイミングにおいて前記コールスタックに格納されているリターンアドレス列との差分を表すデータを前記挙動モデルデータとして複数記憶し、
前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、
前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記異なるタイミングにおいて前記コールスタックに格納されている各リターンアドレスからなるリターンアドレス列との差分を、前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたデータと比較することにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する
ことを特徴とする請求項１に記載の不正処理検知装置。
【請求項４】
前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレスの少なくとも一部が、前記挙動モデルデータ記憶手段に記憶された複数の挙動モデルデータのうちのいずれかと一致する場合に、前記不正処理の検知対象となるソフトウェアの挙動が正常であると判定する
ことを特徴とする請求項１に記載の不正処理検知装置。
【請求項５】
ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを記憶する挙動モデルデータ記憶手段と、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを記憶する不正処理定義データ記憶手段と、ソフトウェアを実行する実行手段とを備えた不正処理検知装置が行う不正処理検知方法であって、
不正処理の検知対象となるソフトウェアが前記実行手段により実行されるときにコールスタックに格納されるリターンアドレスを取得するステップと、
取得された前記リターンアドレスと、前記挙動モデルデータ記憶手段に記憶された挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定するステップと、
前記不正処理の検知対象となるソフトウェアの挙動が正常でないと判定された場合に、取得された前記リターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知するステップと
を有することを特徴とする不正処理検知方法。
【請求項６】
ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを記憶する挙動モデルデータ記憶手段と、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを記憶する不正処理定義データ記憶手段と、ソフトウェアを実行する実行手段とを備えたコンピュータに、
不正処理の検知対象となるソフトウェアが前記実行手段により実行されるときにコールスタックに格納されるリターンアドレスを取得するステップと、
取得された前記リターンアドレスと、前記挙動モデルデータ記憶手段に記憶された挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定するステップと、
前記不正処理の検知対象となるソフトウェアの挙動が正常でないと判定された場合に、取得された前記リターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知するステップと
を実行させるためのプログラム。
【請求項１】
ソフトウェアを実行する実行手段と、
ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを複数記憶する挙動モデルデータ記憶手段と、
ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを複数記憶する不正処理定義データ記憶手段と、
不正処理の検知対象となるソフトウェアが前記実行手段によって実行されるときにコールスタックに格納されるリターンアドレスを取得するリターンアドレス取得手段と、
前記リターンアドレス取得手段によって取得されたリターンアドレスと、前記挙動モデルデータ記憶手段に記憶された各挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する挙動判定手段と、
前記挙動判定手段によって正常でないと判定された場合に、前記リターンアドレス取得手段によって取得されたリターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された各不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知する不正処理検知手段と
を具備することを特徴とする不正処理検知装置。
【請求項２】
前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を前記挙動モデルデータとして複数記憶し、
前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、
前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたリターンアドレス列との一致度が予め定められた条件を満たすか否かにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する
ことを特徴とする請求項１に記載の不正処理検知装置。
【請求項３】
前記挙動モデルデータ記憶手段は、ソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列と当該リターンアドレス列が格納されているタイミングと異なるタイミングにおいて前記コールスタックに格納されているリターンアドレス列との差分を表すデータを前記挙動モデルデータとして複数記憶し、
前記リターンアドレス取得手段は、前記実行手段によってソフトウェアが実行されるときにコールスタックに格納される各リターンアドレスからなるリターンアドレス列を取得し、
前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレス列と前記異なるタイミングにおいて前記コールスタックに格納されている各リターンアドレスからなるリターンアドレス列との差分を、前記挙動モデルデータ記憶手段に挙動モデルデータとして記憶されたデータと比較することにより、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定する
ことを特徴とする請求項１に記載の不正処理検知装置。
【請求項４】
前記挙動判定手段は、前記リターンアドレス取得手段によって取得されたリターンアドレスの少なくとも一部が、前記挙動モデルデータ記憶手段に記憶された複数の挙動モデルデータのうちのいずれかと一致する場合に、前記不正処理の検知対象となるソフトウェアの挙動が正常であると判定する
ことを特徴とする請求項１に記載の不正処理検知装置。
【請求項５】
ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを記憶する挙動モデルデータ記憶手段と、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを記憶する不正処理定義データ記憶手段と、ソフトウェアを実行する実行手段とを備えた不正処理検知装置が行う不正処理検知方法であって、
不正処理の検知対象となるソフトウェアが前記実行手段により実行されるときにコールスタックに格納されるリターンアドレスを取得するステップと、
取得された前記リターンアドレスと、前記挙動モデルデータ記憶手段に記憶された挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定するステップと、
前記不正処理の検知対象となるソフトウェアの挙動が正常でないと判定された場合に、取得された前記リターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知するステップと
を有することを特徴とする不正処理検知方法。
【請求項６】
ソフトウェアが実行されるときにコールスタックに格納される複数のリターンアドレスを含み、当該複数のリターンアドレスによって当該ソフトウェアの挙動を表した挙動モデルデータを記憶する挙動モデルデータ記憶手段と、ソフトウェアが実行されるときの不正な処理の内容を表す不正処理定義データを記憶する不正処理定義データ記憶手段と、ソフトウェアを実行する実行手段とを備えたコンピュータに、
不正処理の検知対象となるソフトウェアが前記実行手段により実行されるときにコールスタックに格納されるリターンアドレスを取得するステップと、
取得された前記リターンアドレスと、前記挙動モデルデータ記憶手段に記憶された挙動モデルデータに含まれるリターンアドレスとを比較し、その比較結果に応じて、前記不正処理の検知対象となるソフトウェアの挙動が正常か否かを判定するステップと、
前記不正処理の検知対象となるソフトウェアの挙動が正常でないと判定された場合に、取得された前記リターンアドレスに対応するコードを解析し、その解析結果から特定される処理の内容と、前記不正処理定義データ記憶手段に記憶された不正処理定義データによって表される不正な処理の内容とを比較することによって、不正な処理を検知するステップと
を実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２０１０−２５７１５０（Ｐ２０１０−２５７１５０Ａ）
【公開日】平成２２年１１月１１日（２０１０．１１．１１）
【国際特許分類】
【出願番号】特願２００９−１０５５８２（Ｐ２００９−１０５５８２）
【出願日】平成２１年４月２３日（２００９．４．２３）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【出願人】（５０４１７１１３４）国立大学法人 筑波大学 (510)
【Ｆターム（参考）】
【公開日】平成２２年１１月１１日（２０１０．１１．１１）
【国際特許分類】
【出願日】平成２１年４月２３日（２００９．４．２３）
【出願人】（３９２０２６６９３）株式会社エヌ・ティ・ティ・ドコモ (5,876)
【出願人】（５０４１７１１３４）国立大学法人 筑波大学 (510)
【Ｆターム（参考）】
[ Back to top ]