?The Clean Theory????????
格言に曰く…
よく知られた格言として、こんな話があります。
樽いっぱいの汚水に、きれいな水を 1 パイント注いでも、残るのは樽いっぱいの汚水だ。では、樽いっぱいのきれいな水に、汚水を 1 パイント注いでみたらどうなるかといえば、そう、できあがるのはやっぱり樽いっぱいの汚水だ。
この話に出てくる、きれいな水を「論理的に真である文」に、汚水を「論理的に偽である文」に置き換えてみれば、この格言が論理学で使われるおなじみの原理を表すことがわかります。
AND 演算子（&）を使って、いくつか連鎖した偽の文（樽いっぱいの汚水）に真である文（1 パイントのきれいな水）を 1 つ追加すると、結果として全体の文は偽になります。いくつか連鎖した真の文に偽である文を 1 つ追加しても同じようになり、全体の文は偽になります。
この格言と論理学の原理は、シマンテックのセキュリティレスポンスエンジニア（SRE）にとっても有益です。SRE の大きな責務のひとつは、特定のファイルが配備先の環境にとって脅威となるかどうかを判定し、その脅威が現実のものとならないように必要な措置を講じることです。そのために SRE は、配備先の環境で望ましくない処理や、悪質な処理を実行しうる特定のコードシーケンスあるいはコマンドがないかどうかファイルを調べる必要があります。
前述の格言や論理学の原理と同じように、解析対象となる潜在的に悪質なファイルは、以下のような（長い）論理シーケンスとして表されます。
S = P1 & P2 & P3 & … & Pi & … & Pn
ここで、各 Pi はファイルの基本ブロック（1 単位の処理を実行する）を表し、論理学で言えば 1 つの文に当たります。実際には、この式に「IF/THEN」など他の論理演算子が含まれることもあります。いずれにしても、ファイル全体を評価するためには、Pi を 1 つずつ評価しなければなりません。
ここでは、一般形としてのファイルブロックを前提に話を進めています。現実的には、ファイルはタイプによって大きく異なるからです。ファイルタイプが異なれば、ファイルブロックの意味も異なります。たとえば、スクリプトファイルにおけるファイルブロックは、スクリプトのインタープリタによって 1 ステップで実行されるコマンドの 1 単位です。それに対して、ネーティブ実行可能ファイルにおけるファイルブロックは基本的なコードブロックと見なされます。つまり、複数のエントリまたは複数のエグジットを持つ命令のブロックです。
リストに 1 つでも偽の文があれば全体の文が偽となるように、いずれか 1 つのファイルブロックが脅威の原因と特定されれば、直ちにそのファイル全体が脅威と見なされます。ファイルが脅威と判定されれば解析はそこで停止し、その脅威に対する検出シグネチャが追加されます。
ファイル全体が悪質な意図で作成された場合（ほとんどのトロイの木馬が当てはまります）、脅威は簡単に特定できます。脅威の要素がいたるところで見つかるのに加えて、不明瞭化やポリモーフィズムも、ファイルに何か問題があることを示す格好の手掛かりになるからです。現在、シマンテックが解析対象として受け取るファイルのうち 4 つに 3 つ（75%）は脅威であると見なされ、検出のためのシグネチャが追加されています。
この作業の労力がいかに大きいかを感覚的にわかっていただくために、メモ帳のように単純なアプリケーションを考えてみましょう。メモ帳でさえ、ファイルブロックの数はおよそ 1,500 に及びます。攻撃者が悪質なブロックをいくつかランダムな位置に挿入した場合、1,500 もの正常なファイルブロックの中からそれを見つけ出すのは非常に困難です。まさに、干し草の中から針を 1 本探し出すようなものです。
脅威の動作を文書化するために詳しい情報が必要な場合には、ファイル全体について詳しい解析を実行する必要があります。こうした詳しい解析を実行するには、パズルの全ピースを埋めるために、SRE は正常なブロックから悪質なブロックまでファイルのコードブロックをほぼすべて調査します。たとえば Stuxnet（これまでに確認された最も複雑な脅威のひとつです）の場合には、シマンテックのシニアセキュリティレスポンスエンジニア 3 人によるチームで約 12,000 ものコードブロックを完全に解析するのに 4 カ月以上を要しました。
多くのバイナリで再利用されることが多い既知の正常なライブラリコードの識別を自動化したり、元の正常なファイルを見つけて悪質な可能性のあるファイルとの差分を比較したりすれば、このように膨大な量の情報でも処理時間を短縮することは可能です。しかし、ブロック数が大きくなれば必ず手作業での検査が必要になります。セキュリティに関して判断を下すための労力と時間は、ファイルに含まれる情報の量に正比例します。つまり、解析作業はファイルサイズにほぼ等しいという法則が成り立つのです。
作業の膨大さを考慮して、SRE は詳しい解析に進む前に特殊なツールを利用する場合もあります。たとえば、制御下の環境に配備したファイルが示す挙動に基づいて判断を下すビヘイビア分析などは有効なツールです。こうしたツールについての詳細は別の機会に譲ります。
意図
よく考えてみると、コマンドプロンプト（cmd.exe）や同等の機能を持つツールは、複数のファイルを削除できるコードブロックを少なくとも 1 つ持っており、しかもユーザーの介在なしにそれを実行できます。このような動作は、それだけでも悪質と見なされ、スタンドアロンのアプリケーションに単独で見つかった場合には（たとえば、実行されるとシステム上で見つけたファイルをすべて削除し始める実行可能ファイルなど）、トロイの木馬と見なされます。とは言っても、cmd.exe や類似のツールは実際には正常なファイルです。では、どうやって判断するのでしょうか。
論理学の場合と同様、真/偽の文と正常/不正なファイルとの類似性が、ここでも同じように働きます。破壊的なコードが実行されるのは、cmd.exe に特定のパラメータが渡され、別の外部パラメータによってユーザー操作が抑止される場合だけです。
基本的に、cmd.exe は以下のように動作します。
del コマンドを入力した場合には、指定されたファイルを削除します。サイレントパラメータを渡すと、確認メッセージは表示されません。
この 2 つの文は、以下のように表すことができます。
S = if P then Q
つまり、P が偽のとき S は真である、つまり正常であるということです。del コマンドがコマンドラインで入力されていない（P が偽である）場合には、cmd.exe によってファイルが削除されないのと同じで、つまりこれは正常な動作です。サイレントパラメータを省略した場合には、コマンドごとに確認メッセージが表示されるということでもあります。
P が真の場合には Q が評価され、それが真であれば S もまた真になります。同じように、ファイルの削除を指示されると cmd.exe は正常に動作します。大きい仕組みの一部である場合は別として、単独では正常です。包丁が、台所で使う道具である一方で犯罪行為に使われることもあるのと似ています。このように、SRE はコマンドを発行するファイルが（正常または悪質な）処理を実行する目的を調べ、その意図を解明します。
最近の脅威や攻撃では実際、相互に対話する複数のモジュールが使われています。ほとんどの場合そのモジュールは明らかに悪質な意図を持って作成されており、悪質であると断定することも比較的容易ですが、特定の脅威に実装されているモジュールの一部が、それ自体では正規のツールであるという場合もあります。
その一例が NetCat で、これはネットワーク管理者が高度なネットワーク接続に使うコマンドラインツールです。NetCat 自体は正常なツールですが、ハッキング攻撃にもきわめて有効であり、バックドア接続を開始する目的で多用されています。悪質な利用が広まったため、シマンテックは NetCat をセキュリティ上の脅威でもありセキュリティ評価ツールでもあると分類しています。NetCat が正当な目的で使われている場合、検出されても無視することができます。
信頼性
個々のファイルを解析する長いプロセスと、日ごとに増え続ける解析対象ファイルの量から、ファイルの発生元と信頼性を特定することが、プロセスで重要な要因になっています。
たとえば、正規の企業は、品質管理の定義に合致する高品質なコンテンツを作り出すのが普通です。デジタル署名やバージョン情報といった整合性データも必ず揃っています。このような情報を使ってファイルを作成者まで追跡すれば、そのファイルの信頼性も判明します。
既知の正規の企業によって作成されたファイルであれば、（既知の副作用がある、動作に疑わしい点があるなど、完全な解析を実行する明白な理由がある場合を除き）完全な解析プロセスを経なくても、一定範囲の確度で正常であると見なすことができます。
ファイルにフラグを設定するときにも、信頼性は適用されます。今日確認されている脅威ファイルのうち 83% は実際のペイロードに重ねて 1 つ以上のパッカーを使っていますが、正常なファイルのほとんどは簡単に解析できる傾向にあります。信頼できる作成元に由来しているように見せかけたファイルでも、不明瞭化の兆候やデジタル署名の不一致がある、あるいはカスタムパッケージを使っている様子がある場合には、95% 以上の確率でセキュリティ上の問題があるでしょう。通常、信頼できる作成元からの正規のファイルであれば、不明瞭化の手法やカスタムパッカーを使ったりはしないものだからです。
次のステップ
論理学が示すように、真理が指し示すのは真理だけです。同じように、正常なファイルはあらゆるレベルで正常でなければなりません。正常なファイルとは、評価の確かな既知の存在によって作成され、正規の明確な目的のために使われるものであり、正常なブロックのみで構成されるものであるべきです。こうした原則は、ファイルの判定に有用なだけではなく、他の分野にも応用できます。
現在使われている解析手法が（比較的）遅く、その一方で処理すべきファイルの数が日々増えている現状を考えれば、セキュリティベンダーは個々のファイルの詳しい解析を減らして脅威を解析できる新しい手法を生み出す必要があります。信頼性と意図の特定に重点を置く傾向は、今後も強くなっていくでしょう。
ミルチャ・チュボタリュ（Mircea Ciubotariu）著「The Clean Theory」（Virus Bulletin、2013 年 8 月）。著作権は Virus Bulletin Ltd が有していますが、Virus Bulletin の許諾により、このサイトでは個人的な使用に限って無償で公開しています。
* 日本語版セキュリティレスポンスブログの RSS フィードを購読するには、http://www.symantec.com/connect/ja/item-feeds/blog/2261/feed/all/ja にアクセスしてください。