JP6455738B2 - パッチファイル分析システム - Google Patents

Description

本発明は、応用プログラムのパッチファイルに対して動作パターン及び形態などにおいて、既存のファイルとの類似性があるか否かと共に、パッチファイルによって危険性の高い行為が行われるか否かを判断して、パッチファイルに含まれてくるマルウェア、ウイルス、バックドア、機能低下コードなどを検出するパッチファイル分析システム及び分析方法に関する。

コンピュータ技術分野において、パッチ（ｐａｔｃｈ）は、コンピュータなどにインストールされた各種応用プログラムまたはデータなどの障害を修正するとか、応用プログラムまたはデータなどの既存情報を最新情報に変える動作を指称する。従って、コンピュータにインストールされた各種応用プログラムは、周期的に提供されるパッチファイルのインストールを介してパッチが行われ、ユーザーは、前記パッチを介して該当応用プログラムを安定して利用をすることができる。

ところが、社会工学的な攻撃の発達とともに、マルウェアをあたかも正常なパッチファイルのように配布するとか、パッチファイルがマルウェアに感染されるとか、バックドアを含ませることによって、該当パッチファイルをインストールしたシステムに深刻な障害を引き起こす事例が多数発生している。

このような深刻さにもかかわらず、従来には、応用プログラムに対するアップデートファイル（パッチファイル）が前記応用プログラムの該当製造社から提供したパッチファイルであるか否かを判断する方法が全くなく、これによって、パッチファイルによるコンピュータのマルウェア感染が頻繁であった。

前述した問題を解消するために、従来のワクチンプログラムは、マルウェアなどの動作パターンを確認して、該当動作パターンが確認されると、マルウェアによる感染と見做し、これを治癒するようにした。

しかし、従来のワクチンプログラムは、パッチファイルがマルウェアであるか否かのみを判断するだけであり、該当パッチファイルが前記製造社で作られた正常なパッチファイルであるか否かを判断することができなかった。また、動作パターンに対する情報がない場合には、マルウェアの感染の可否を判断することができなかったし、感染可否判断が動作パターンの分析にのみ重点を置くので、論理爆弾、隠されたコードなどによる新しい形式のマルウェアは、従来のワクチンプログラムにおいて全く検出することができないという問題があった。

これに対し本発明は、前記のような問題を解消するために発明されたものであって、応用プログラムのパッチファイルに対して、動作パターン、ファイル形態側面から既存の正常な応用プログラムファイルとの類似性を判断し、更に、パッチファイルの危険行為を把握して、該当パッチファイルが正常なパッチファイルであるか否かをユーザーが判別することができるパッチファイル分析システム及び分析方法の提供を解決課題にしようとする。

前記の技術的課題を達成するために、本発明は、
応用プログラムに構成された設定情報を収集して基準情報として生成するプログラム分析モジュールと、
前記基準情報を格納する基準情報ＤＢと、
前記応用プログラムのパッチファイルを分析して、前記パッチファイルに構成された設定情報をパッチ情報として生成するパッチファイル分析モジュールと、
前記パッチ情報に対応する基準情報を前記基準情報ＤＢから検索し、前記パッチ情報及び基準情報を比較する比較モジュールと、を含むパッチファイル分析システムである。

本発明は、応用プログラムのインストールファイル及び既存のパッチファイルから収集した基準情報を新しいパッチファイルのパッチ情報と比較して、ファイル形態の変化、新しいＡＰＩ呼び出しなどの新しい危険な行為が含まれているか否かを判断することができるので、パッチ過程で危険なパッチファイルのインストールを防止することができる効果がある。

本発明による分析システムの構成を示したブロック図である。 本発明による分析システムを利用した分析方法を順次示したフローチャートである。 本発明による分析システムの他の実施例を示したブロック図である。 本発明によるパッチ進行過程を概略的に示したフローチャートである。

前述した本発明の特徴及び効果は、添付された図面と関連した下記の詳細な説明を通じてより明らかになるはずであり、それによって、本発明の属する技術分野において、通常の知識を有する者が本発明の技術的思想を容易に実施することができるだろう。本発明は、様々な変更を加えることができ、様々な形態を有することができるところ、特定の実施例などを図面に例示して本文に詳細に説明しようとする。しかし、これは本発明を特定の開示形態に対して限定しようとするものではなく、本発明の思想及び技術範囲に含まれるすべての変更、均等物ないし代替物を含むものとして理解されるべきである。本出願で使った用語は、単に特定の実施例などを説明するために使われたものであって、本発明を限定しようとする意図ではない。

以下、本発明を実施するための具体的な内容が添付された図面に基づいて詳細に説明する。

図１は、本発明による分析システムの構成を示したブロック図であり、これを参照して説明する。

一般に、パッチファイルは、既存のプログラムの機能を大きく修正するとか、システムの敏感な領域に同意せずにアクセスするコードを含まない。

本発明による分析システム１００は、パッチファイルの前述した特性を活用して、新しいパッチファイルが既存のプログラムの動作を大きく外れるとか、システムの敏感な領域を新たにアクセスするコードが存在することが確認されると、これを検査して分析結果をユーザーに報知することが基本動作概念である。

本発明による分析システム１００は、既存のプログラムを分析して、システム呼び出し情報を格納し、システムの敏感な領域にアクセスする関連データが格納された危険知識ベースを管理し、新しいパッチファイルを分析して、既存のプログラムとの差異とシステム民間領域の新しいアクセスを分析することができるように構成される。

このための本発明による分析システム１００は、任意の端末機に対する応用プログラムの設定情報（応用プログラムに属するファイル形態情報及び動作パターン情報など）を収集して基準情報として設定するプログラム分析モジュール１２０と、前記基準情報を格納する基準情報ＤＢ１１０と、前記応用プログラムのパッチファイルを分析してファイル形態情報及び動作パターン情報などの分析情報を収集し、前記分析情報をパッチ情報として設定するパッチファイル分析モジュール１３０と、前記応用プログラムの基準情報及びパッチ情報を比較する比較モジュール１４０と、を含む。

基準情報ＤＢ１１０は、先に説明したように、前記応用プログラムの設定情報は勿論、正常なパッチファイルから構成された設定情報（各ファイルの形態情報及び動作パターン情報など）を基準情報として格納する。

プログラム分析モジュール１２０は、前記基準情報を生成する。本発明による実施例において、基準情報は、前述したように、前記応用プログラムの設定情報（ファイル形態情報及び動作パターン情報など）を分析して生成されるが、これを下記でより具体的に説明する。

動作パターン情報は、静的分析及び動的分析（デバッグ）を介して行われる。

前記静的分析は、応用プログラムのインストールファイルなどが実行していない状態で、ＯＳに対するＡＰＩ、またはサービス関数の呼び出し履歴を確認し、これを記録する。もう少し説明すると、静的分析技術は、ソフトウェアの静的表現（ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）に基づいてソフトウェアの動作に対する情報を推論する。これは、ソフトウェアが動作するときに、これを観察して情報を収集する動的分析技術と対比される。コードが実行されていない状態で分析するので、テストケースは必要ない。静的分析は、２つのステップの過程を経る。第一のステップでは、ソフトウェアのバイナリファイルから意味情報（ｓｅｍａｎｔｉｃ ｉｎｆｏｒｍａｔｉｏｎ）を抽出する。第二のステップでは、この情報を利用して欠陷や所望の他の特性を捜す。

前記動的分析は、前記インストールファイルを実行した状態で、動的でＯＳに対するＡＰＩ、またはサービス関数の呼び出し履歴を確認し、これを記録する。静的分析または動的分析などを介して該当応用プログラムから呼び出し及びロードされるＡＰＩ及びサービス関数リストを確認することができ、パッチファイルによって新規に追加されるＡＰＩ及びサービス関数リストを確認することができる。

参考までに、関数ごとに使うリソース内訳（ファイル及びレジストリなど）の確認は、前記静的分析及び動的分析を通じて行われることができ、これを通じて基準情報を生成する。例えば、Ｃｒｅａｔｅｆｉｌｅ関数は、ファイル及びＩ／Ｏデバイスを生成するとか、オープンする関数であるが、パッチファイルが任意ファイル及びＩ／Ｏデバイスにアクセスするために、主に活用する。プログラム分析モジュール１２０は、Ｃｒｅａｔｅｆｉｌｅ関数のｐａｒａｍｅｔｅｒを‘アクセス先のファイル’と指定し、インストールファイルのインストール過程中、Ｃｒｅａｔｅｆｉｌｅ関数がアクセスするファイルリストを基準情報に含む。以後、該当応用プログラムのパッチファイルが正常なパッチファイルであるものとして判明されると、パッチ過程でＣｒｅａｔｅｆｉｌｅ関数がアクセスするファイルリストを基準情報ＤＢ１１０に持続的にアップデートすることができる。

以上説明したように、プログラム分析モジュール１２０は、前記応用プログラムファイルに対するファイル形態情報と動作パターン情報などを把握して基準情報として生成し、このように生成した基準情報を基準情報ＤＢ１１０に格納する。

パッチファイル分析モジュール１３０は、該当応用プログラムのパッチファイルに対するファイル形態情報と動作パターン情報などを収集してパッチ情報として生成する。パッチ情報は、基準情報であるファイルの形態情報と動作パターン情報に対応した情報が収集され得る。一例として、パッチ情報は、基準情報のファイル形態情報と共に動作パターン情報に例示されたＡＰＩリストまたはサービス関数リストなどに相応して、パッチ時ＯＳから呼び出される呼び出しリストを含むことができる。

比較モジュール１４０は、該当応用プログラムの基準情報を基準情報ＤＢ１１０から検索し、パッチファイル分析モジュール１３０が生成したパッチ情報を前記基準情報と比較する。

比較結果、基準情報とパッチ情報に差があると、該当結果内容を様々な形態（ｄｏｃ、ｐｄｆ、ｈｔｍｌなど）の結果報告書として出力することができ、以後、パッチ情報に対する危険度を更に判断して結果報告書に含むことができる。以後、管理者は、結果報告書に基づいて該当応用プログラムの製造社２００に問い合わせて、パッチファイルが製造社２００から配布された正常なファイルであるか否かを問い合わせする。製造２００から該当パッチファイルが正常であれば、前記パッチファイルのパッチ情報を基準情報にアップデートし、該当ファイルをパッチする。パッチ方式は、既存の公知、共用のパッチ技術が適用されるので、これに対する具体的な説明は省略する。

以上の内容を参考にして、本発明によるパッチ分析方法を説明する。

図２は、本発明による分析システムを利用した分析方法を順次示したフローチャートであるところ、これを参照して説明する。

Ｓ１０；基準情報生成ステップ
管理者は、任意の応用プログラムのインストールファイル（例えば、ｓｅｔｕｐファイル）の構成情報をプログラム分析モジュール１２０に入力データとして入力して基準情報として設定する。また、正常なパッチファイルがあれば、前記パッチファイル構成情報もプログラム分析モジュール１２０に入力データとして入力して前記基準情報に補強する。

プログラム分析モジュール１２０は、入力された応用プログラムのインストールファイル及び正常なパッチファイルに対する情報を把握して、該当応用プログラムの基準情報として生成するが、前述したように、前記基準情報は、インストールファイル及び正常なパッチファイルの形態情報と動作パターン情報を含む。プログラム分析モジュール１２０が形態情報と動作パターン情報を収集する技術は、先に説明したことがあるので、ここでは、追加説明は省略する。

Ｓ２０；パッチ情報確認ステップ
パッチファイル分析モジュール１３０は、該当応用プログラムの新しいパッチのためのパッチファイルのファイル形態情報と動作パターン情報などを収集して、パッチ情報として生成する。パッチ情報は、基準情報であるファイルの形態情報と動作パターン情報に対応して収集され得る。基準情報のファイル形態情報と共に動作パターン情報に例示されたＡＰＩリストまたはサービス関数リストなどに相応して、パッチ時ＯＳから呼び出される呼び出しリストを含むことができる。

Ｓ３０；比較ステップ
一般に、応用プログラムが動作するためには、ＯＳから提供するＡＰＩを呼び出さなければならないが、一般に、ＯＳに対する応用プログラムのＡＰＩ呼び出し内訳は、パッチ前後に大きい差がない。従って、パッチファイルが既存応用プログラムのＡＰＩ呼び出し内訳には確認できない新しいＡＰＩ呼び出しを行うと、前記パッチファイルを製造社２００から提供した正常なパッチであるか否かを確認すべき対象として分類する。例えば、ウイルスのようなマルウェアが他のプロセスのリソースを占有するために使う代表的なＡＰＩとして、ＣｒｅａｔｅＲｅｍｏｔｅＴｈｒｅａｄＯを挙げることができる。ＣｒｅａｔｅＲｅｍｏｔｅＴｈｒｅａｄＯは、他のプロセスから実行されるｔｈｒｅａｄを生成するＡＰＩ関数であるが、他のプロセス権限で実行しようとするときに使われる。また、ＣｒｅａｔｅＲｅｍｏｔｅＴｈｒｅａｄＡＰＩを介して他のＤＬＬに対するインジェクションも可能である。従って、ＣｒｅａｔｅＲｅｍｏｔｅＴｈｒｅａｄＯを利用して、他のＤＬＬに対する動作を迂回するとか無力化させることができる。これを基にして基準情報には、ＣｒｅａｔｅＲｅｍｏｔｅＴｈｒｅａｄＯＡＰＩが使用されていないが、パッチ情報で該当ＡＰＩが追加されたら、これは危険として分類され得る。また、ＭＢＲ（ｍａｓｔｅｒ ｂｏｏｔ ｒｅｃｏｒｄ）をアクセスするためには、ハードディスクをファイル単位でアクセスせず、物理的にディスクにアクセスするべきであり、この場合、ＣｒｅａｔｅＦｉｌｅ（"＼＼＼＼．＼＼ＰｈｙｓｉｃａｌＤｒｉｖｅＯ"、...）形態でＣｒｅａｔｅＦｉｌｅＡＰＩ呼び出しのパラメタが変わる。このようなシステムを破壊、感染重要ＡＰＩ、ＡＰＩ呼び出し時のパラメタ、ドライバー、サービス、ネットワークなどをすべて前記基準情報に含み、パッチファイルによるパッチ情報を前記基準情報と比較する。例えば、ある応用プログラムのパッチ比較のために、該当応用プログラムの歴代パッチ情報まで累積して分析した結果、基準情報（既存パッチファイル含み）では確認できなかったＣｒｅａｔｅＲｅｍｏｔｅＴｈｒｅａｄＯの呼び出しがパッチ情報に確認されると、該当パッチファイルは、製造社２００から提供した正常なパッチファイルではないものとして疑うことができる。

前述したように、比較モジュール１４０は、パッチファイル分析モジュール１３０が生成したパッチ情報を該当応用プログラムの基準情報と比較して、その差の可否を判断する。このために、比較モジュール１４０は、該当パッチファイル関連応用プログラムの基準情報を基準情報ＤＢ１１０から検索し、検索した基準情報を前記パッチ情報と比較する。

更に、ＡＰＩ及びサービス項目呼び出しに対しては、ディスアセンブラ(ｄｉｓａｓｓｅｍｂｌｅｒ）を介してパラメタを追跡し、応用プログラムの基準情報と比較することができる。例えば、パッチファイルのパッチ中から呼び出されるＡＰＩまたはサービス項目が該当応用プログラムの実行に必要なリソースではなく、基準情報では確認できなかった他の応用プログラムのリソースまたはシステムリソース（Ｓｙｓｔｅｍ Ｒｅｓｏｕｒｃｅ）にアクセスする場合には、基準情報と比較することができ、後の危険性判断ステップＳ４０でリソースの重要性に応じて‘危険’と見做すことができる。参考までに、システム重要リソース（Ｓｙｓｔｅｍ Ｃｒｉｔｉｃａｌ Ｒｅｓｏｕｒｃｅ）は、ＭＢＲなどのディスクに対する物理的Ｒ／Ｗ（ＲＥＡＤ／ＷＲＩＴＥ）と、デバイスドライバーロード、システムサービスロード、ＡＰＩ Ｍｅｓｓａｇｅ ＨＯＯＫ、ＨＯＳＴファイル変調、ネットワーク通信などが例示され得る。

以上説明したように、比較モジュール１４０は、パッチ情報が既存情報と異なる場合、この情報を結果報告書に記録する。

図３は、本発明による分析システムの他の実施例を示したブロック図であり、図４は、本発明によるパッチ進行過程を概略的に示したフローチャートであるところ、図２と共に参照して本発明による分析システム及び分析方法を説明する。

Ｓ４０；危険性判断ステップ
比較モジュール１４０でパッチファイル分析モジュール１３０が生成したパッチ情報が該当応用プログラムの基準情報と比較して、動作パターン情報が異なるとか、またはファイル形態が異なると判断された場合、危険判断モジュール１７０は、該当パッチ情報の危険度等級を危険知識ベース１６０から検索して、パッチファイルの危険度を出力する。参考までに、危険知識ベース１６０は、ＯＳに対する動作行為またはＯＳの動作行為を危険度に応じて等級化して格納し、危険判断モジュール１７０は、比較モジュール１４０が前記基準情報とパッチ情報を比較して確認した比較内容を前記危険知識ベース１６０の動作行為と比較して、該当する危険度を検索及び出力する。

例を挙げて説明すると、危険度等級に対する情報は、アクセスされるパラメータを把握して具体的な危険性を判断することができるが、システム全般のリソース（Ｓｙｓｔｅｍ Ｃｒｉｔｉｃａｌ Ｒｅｓｏｕｒｃｅ）は、 ＭＢＲなどのディスク（ＰｈｙｓｉｃａｌＤｒｉｖｅ０）に対する物理的Ｒ／Ｗ（ＲＥＡＤ／ＷＲＩＴＥ）と、デバイスドライバーロード、システムサービスロード、ＡＰＩ Ｍｅｓｓａｇｅ ＨＯＯＫ、ＨＯＳＴファイル変調、ネットワーク通信などのアクセスが例示され得る。すなわち、該当パッチ情報に基準情報では確認できない他のＩＰへのネットワーク通信が追加されたら、該当パッチは、‘危険’と見做すものである。また、ファイルにアクセスして読み取り／書き込みをする際に活用される関数であるＣｒｅａｔｅＦｉｌｅ関数のパラメータがＰｈｙｓｉｃａｌＤｒｉｖｅＯである場合には、システム起動に必要なＭＢＲ領域へのアクセスを意味するので、これも該当パッチは、‘危険’と見做す。また、該当ハッキングでウィンドウズ（登録商標）などのＯＳオペレーティングに使われる共用ファイル（ｅｘ、ＥＸＥ．ｄｌｌ、ｎｔｄｌｌ．ｄｌｌ、ｋｅｒｎｅｌ３２．ｄｌｌなど）と同一の名前のファイルを生成するとか、名前を変更するハッキング情報が確認されると、これも、基準情報と比較して、該当パッチは‘危険’と見做す。参考までに、ｎｔｄｌｌ．ｄｌｌなどのように、ＯＳ（ｅｘ、Ｗｉｎｄｏｗｓ）の共用ファイルは、すべての応用プログラムが動作するときに使われる構成要素であるが、このファイルが損傷されると、ＯＳ自体はもちろん、前記コンピュータに既にインストールされている応用プログラムは、正常な動作をすることができなくなる。

Ｓ６０：報告及び問い合わせのステップ
上のステップで導出された結果報告書に基づいて、管理者は、前記パッチファイルが該当応用プログラム製造社２００から提供した正常なパッチファイルであるか否かを製造社２００に問い合わせする。該当パッチファイルが製造社２００から提供された正常なパッチファイルとして確認されると、既存の方式でパッチを行い、該当パッチ情報を基準情報にアップデートする。もし、該当パッチファイルが製造社２００から提供されていない偽装されたパッチファイルの場合には、パッチを行わないように措置する。

先に説明した本発明の詳細な説明では、本発明の好ましい実施例などを参照して説明したが、該当技術分野の熟練した当業者または該当技術分野において通常の知識を有する者であれば、後述される特許請求の範囲に記載された本発明の思想及び技術領域から逸脱しない範囲内で、本発明を様々に修正及び変更させ得ることを理解することができるだろう。

Claims (5)

1. 応用プログラムに構成された設定情報を収集して基準情報として生成するプログラム分析モジュールと、
   前記基準情報を格納する基準情報ＤＢと、
   前記応用プログラムのパッチファイルを分析して、前記パッチファイルに構成された設定情報をパッチ情報として生成するパッチファイル分析モジュールと、
   前記パッチ情報に対応する基準情報を前記基準情報ＤＢから検索し、前記パッチ情報及び基準情報を比較する比較モジュールと、を含むことを特徴とする、パッチファイル分析システム。
2. 更に、動作行為を危険度に応じて等級化して格納する危険知識ベースと、
   前記比較モジュールが前記基準情報及びパッチ情報を比較して確認した比較内容を前記危険知識ベースの動作行為と比較して、該当する危険度を検索する危険判断モジュールと、を含むことを特徴とする、請求項１に記載のパッチファイル分析システム。
3. 前記基準情報は、前記応用プログラムのインストールの前後のＡＰＩ呼び出しリスト及びサービス関数呼び出しリストのうちから選択された一つ以上を収集して備えた動作パターン情報を含むことを特徴とする、請求項１又は２に記載のパッチファイル分析システム。
4. 前記パッチ情報は、前記パッチファイルのインストールの前後のＡＰＩ呼び出しリストとサービス関数呼び出しリストとのうちから選択された一つ以上を収集して備えたことを特徴とする、請求項３に記載のパッチファイル分析システム。
5. 前記基準情報は、応用プログラムのバイナリファイルから意味情報を抽出して確認した静的分析情報を含み、前記パッチ情報は、パッチファイルのバイナリファイルから意味情報を抽出して確認した静的分析情報を含むことを特徴とする、請求項４に記載のパッチファイル分析システム。