2010-06-28
■コンピュータフォレンジックの今後10年
Twitter 経由で流れていたのですが、ExFORENSICS の下記投稿がなかなか興味深いです。コンピュータ・フォレンジックの今後10年についての予測？内容となっていますが、2020年になっても Windows 7 を調べているに違いない！！っていうのは笑えます、確かにそうかもしれない。
Computer Forensics – The Next Ten Years
http://exforensis.blogspot.com/2010/06/computer-forensics-next-ten-years.html
まず最初の項目が、暗号化への対応とメモリ・フォレンジックが重要度を増すということになっています。FNG14 は丁度“メモリ・フォレンジック”のネタでしたけども、制限事項も OS やツールによって色々とあるので、使える手法を上手に活用していく必要がありますね。民間向けには提供していませんが、会社のほうで2日間の「Windows メモリフォレンジック I & II」というトレーニングを提供していたりします。
携帯デバイスのフォレンジック、とかクラウド方面はまぁそうなるでしょうねぇ。
項目 5 “Forensics will get harder, not easier”については悩ましい部分ですね。今後、フォレンジックはより難しくなり、簡単になることはない！という辺り、個人的には特に賛成です。
PBF（プッシュ・ボタン・フォレンジック）なんて単語もあり、ボタン一発で解析結果が出てくれれば確かに楽なんですけども、調査対象の OS が複雑化というか多機能化していく中、簡単にできる部分と、簡単にできない部分が色々と出てきますね。しかもサイズが巨大になってきてますし。
調査する側の人間にとっても、覚えるべきことが膨大になってきていて、トレーニングするにもどこから手を付けていけばよいのか？という辺りはありますね。基礎的な部分としては、まずはファイルシステムかなという気がしますが、フォレンジック屋さん向けなファイルシステムのトレーニングっていうと「フォレンジック・ファイル分析 (Windows編)」しか現状だと見当たらないですかね。うちの会社でもメニュー的にはファイルシステムありますが、そもそも基礎的な部分なので深いところはやらないし、フォレンジック屋さん向けの専用コースという位置付けではなく、システム管理者やIT担当者でも、ファイルシステムの基礎的な内容を知っておけば、何かあった時にホイミくらいは使えるようになるので便利でしょ！？、を目的としたコースなんですよねぇ。なので、スライムとかではなく竜王倒したい向きの人は専門コースのほうでお願いします。
■FNG14のまとめ
今回は @cci_forensicsさんに講師というか、教官というかをやっていただき、Honeynet Project Challenges の Banking Troubles というメモリフォレンジックな課題に挑戦してみました。まぁすでに回答が出ているので、回答を読みながらなんですけど（笑）
Challenge 3 of the Forensic Challenge 2010 - Banking Troubles
設問の内容と、メモリイメージ内の状況や時系列的に微妙なところがあったりもしますけど、まぁ演習課題という意味では、なかなか興味深い内容です。とはいえ、ネタバレになるところもありますので、これから挑戦を考えている方向けにあまりネタバレにならない範囲でメモっておきます。
■環境の準備
今回はメモリ・フォレンジックということで、主に The Volatility Framework を使うということになりそうでしたので、The Volatility Framework を利用できるようにします。とはいえ、Windows 環境だと Python 入れたりと何かと面倒ですよね！？。ということで、今回手元の環境では必要なツールが一式揃っている SANS Investigative Forensic Toolkit (SIFT) Workstation 環境を使うことにしました。
SANS Investigative Forensic Toolkit (SIFT) Workstation: Version 2.0
VMware環境で動作する Ubuntu ベースの環境ですが、SANS ポータルのサイトからイメージの ZIP ファイルをダウンロードして、圧縮ファイルを展開して起動すれば OK という、とても便利なのにお手軽な環境です。
ただ、SIFT を動かす PC はそれなりのスペックなコンピュータの方がよいですね。メモリもデフォルトでは 1GB が割り当てられていますが、もう少し増やした方がよさそうな気がします。ホスト側のメモリ搭載量が 2GB とかだと、SIFT で 1GB 喰いますので、同時に EnCase とかホスト側で使うと苦しい感じがします。
SIFT 以外には、EnCase 必要ですけど、MemoryForensicToolkit があると便利です。っていうか Ji2 の Web だと Ver1.4 までしか公開されていませんが、作者の Web で最新 Version 1.69 が公開されています。
http://cci.cocolog-nifty.com/blog/2010/03/encase-enscript.html
今回の FNG14 では、公開されていない Ver1.79 が使われていました（笑）、これもそのうち公開されるのではないかと思いますので期待して待ちましょう。
■SIFTの準備
特に必要ないというか、VMwareの設定でホスト側と共有するフォルダパスについて設定を変更 or 確認しておくくらいでしょうか。起動した段階でログオンパスワードがわからず一瞬悩んでしまいましたが、Web に SIFT Login/Password としてちゃんと書いてありました。
今回の課題を解くのに必要となる The Volatility Framework のプラグインは基本的にひと揃いインストールされているので、ログイン後に vltatility とコマンドを叩けばすぐに使えます。
その他に、ファイルリカバリ用に使うことになる Foremost も入っているので、これもそのままコマンドラインから foremost と叩けば実行できますが、不用意にそのまま実行したら抜け方がわからず焦りました。Ctrl + D キーで抜けられると教えていただき、一つ勉強になったということで(^^;;
■メモリイメージの確認
The Volatility Framework(Volatility-1.3_Beta) の解析可能なメモリイメージは Windows XP Sp2 or Sp3 でかつ 32bit 版という制限があります。MemoryForensicToolkit や商用製品である HBgary Responder は他の Windows 系 OS にも対応しているのですが、現状では Volatility Framework の解析対象はかなり限定されています。練習台としてはいいかもしれませんが、実際のケースで使うとなると HBgary Responder なり EnCase + MemoryForensicToolkit が必要になると思います。
WinDBG があるぢゃまいか！！、というお話もあるのかもしれませんが、今回の課題を WinDBG だけで解いた人っているんですかね？ぜひ手法を教えて欲しいです！！
Volatility Framework の場合には、IDENT コマンドでイメージの情報を確認することができますが、MemoryForensicToolkit の場合には、DllListコマンドを使うと CSDVersion で確認できるそうです。というか、どの OS から取ったメモリイメージなのか不明とかいうことは普通は無いと思いますけど。
以下、MemoryForensicToolkit の DllList コマンドの実行結果。
process dll modules in Honeynet_challenge.vmem PID: 644 Name: winlogon.exe Command Line: winlogon.exe CSDVersion: Service Pack 2
『あれ？ビルド番号がないなぁ』と作者が呟いていたので、期待値としてはビルド番号が入っているらしいのですが、いまは抜けているみたいです。
■プロセスリストの確認
インシデントの発生原因となったプロセスの状態を確認するというのが設問1ですので、メモリイメージ内のプロセスリストを取得します。
Volatility Framework の場合には、pslist と psscan、psscan2 がありますが、pslist コマンドの出力結果では、過去のプロセスや意図的になにかやられている場合には見つけられないので、psscan か psscan2 を使うことになるそうな。psscan と psscan2 は実装の違いということですが、通常は psscan2 を実行して、結果で何も表示されないとか比較したい場合とかに psscan も実行ということでしょうか。
Volatility Framework には他にも同じように connscan と connscan2 のように、(New）のマーク付きでコマンドが増えていたりしますが、説明が全然ないところがまた...
なお、終了しているプロセスが確認できる場合、MemoryForensicToolkit であれば次のように Time exited に値が入りますので、終了しているプロセスを識別することができます。
running processes in FNG_challenge.vmem PID PPID Time created Time exited Offset PDB Remarks 1264 628 2010/06/01/ 08:17:44 UNKNOWN 122d498 80c04c0 logon.scr 1008 324 2010/05/25/ 06:43:57 2010/06/01/ 08:07:30 12346b8 80c0460 filezilla.exe 2040 628 2010/05/25/ 06:54:03 2010/05/26/ 07:20:12 1237a18 80c0480 logon.scr 1952 324 2010/06/01/ 08:07:32 UNKNOWN 1241020 80c04a0 csxxkesj.exe 1072 628 2010/06/10/ 08:21:39 2010/06/10/ 08:57:24 13d47f0 80c00a0 logon.scr 1084 672 2010/06/01/ 08:25:35 UNKNOWN 16a13e8 80c0160 svchost.exe 628 348 2010/06/01/ 08:25:32 UNKNOWN 16b1988 80c0060 winlogon.exe
ちなみにこの FNG_challenge.vmem は、FNG14 の課題として作成されたメモリイメージなので、“せまっ！”と言われる私の世間の範囲では一般に公開はされてないと思います。
■通信状態の確認
インシデントのきっかけとなったプロセスに関連した、TCP/IP の通信状態を確認する作業ですが、Volatility Framework では connscan と connscan2 を使うことになります。加えて Volatility Framework には sockets コマンドあります。MemoryForensicToolkit には sockets コマンドに相当するものがないので、もしソケットの状態を知りたい場合には Volatility Framework で sockets コマンドなどを使います。sockets コマンドを使えば、プロセス毎の TCP/UDP ポートの利用状態を確認することができますが、相手先の IP アドレスとかはわからないですね。
$ volatility sockets -f ./Honeynet_challenge.vmem Pid Port Proto Create Time 4 0 47 Fri Feb 26 03:35:00 2010 1040 68 17 Sat Feb 27 20:12:35 2010 880 1185 6 Sat Feb 27 20:12:36 2010 4 1030 6 Fri Feb 26 03:35:00 2010 700 500 17 Fri Feb 26 03:34:26 2010 4 138 17 Sat Feb 27 19:48:57 2010 1244 1189 6 Sat Feb 27 20:12:37 2010 1040 1181 17 Sat Feb 27 20:12:35 2010 1100 1047 17 Fri Feb 26 03:43:12 2010 880 30301 6 Sat Feb 27 20:12:36 2010 4 445 6 Fri Feb 26 03:34:02 2010 1040 123 17 Sat Feb 27 19:48:57 2010 948 135 6 Fri Feb 26 03:34:07 2010 1752 1178 6 Sat Feb 27 20:12:32 2010 888 1168 6 Sat Feb 27 20:11:53 2010 1752 1177 17 Sat Feb 27 20:12:32 2010 1244 2869 6 Sat Feb 27 20:12:37 2010 1040 123 17 Sat Feb 27 19:48:57 2010
この辺りは、電源断をする前に netstat -nab などのコマンド実行の結果を記録しておくと、併用できて調査時点では便利だと思います。
Windows 7 ではこの辺りのメモリ内における構造が変わっているらしく、調べるのが大変なんだそうです。
TCP connections in Vista/7 memory images
http://cci.cocolog-nifty.com/blog/2010/06/tcp-connections.html
ただし、HBgary Responder は対応しているそうなので、HBgary Responder を持っていればあまり支障ないかもしれません。
■メモリ内からのファイル取り出し
今回の課題には、インシデント発生の原因となったファイルを抽出せよ！という問題があるので、メモリイメージ内から該当するプロセスのメモリ空間を抽出する必要があります。
例えば、メモリイメージ全体に対してファイルのリカバリを実行してしまうと、当然、メモリイメージ含まれている様々なプロセスのファイルが手当たり次第にリカバリされてしまいノイズだらけになってしまいます。この為、調査したいプロセスのメモリ空間からのみ、ファイルのリカバリを行なう必要があります。
今回の課題は Windows XP のメモリイメージだったので良かったのですが、例えば Windows 7 のメモリイメージから、指定したプロセスのメモリ空間だけを切り出すのは現状ではベストなツールが無い状況です。（HBgary Responderだと、メモリから .EXE なイメージを取り出すことは可能みたいですが、ファイルのリカバリ用に指定したメモリ空間を切り出すとかは出来ない様子です）
Volatility Framework では memdmp コマンドを使うことで指定したプロセスのメモリを抽出できます。これと同じことを Windows 7 のメモリイメージなどに対しても実行できればよいわけですが、なんかないですかねぇ、MANDIANT Memoryze とかも駄目なのかなぁ。
■えんとろぴー
今回の FNG14 では Ver1.79 の新たな機能として、PsEntropyPEB と PsEntropyVAD なる新しいモジュールがお披露目されていました。EnCase に搭載されたエントロピー機能を利用したもので、恐らく内容は 7/23 の 第二回 コンピュータフォレンジクス技術解説 無料セミナー の「Entropyの仕組みと近似ファイルの検出」で解説されると思います。残念ながらすでに募集は締め切っているんですけど、資料は後日公開されるのではないかと思います。
Ust とかちょっと興味はあるんですけど、やり方よくわかんないので今のところ予定は全然ないんですが、当日ひょっとしたら急に流してみるかも？でも画面見えないとたぶんわかんないよなぁ。
