AWS EC2 のHDD解析（フォレンジック）
(この記事は2020年5月7日に公開されました。)
こんにちは、フォレンジック課の traoka です。
よく「フォレンジックってなんやねん」と、あまり馴染みがない言葉ということで、この度AWSの名前の力を借りて技術面も交えながら少しご紹介したいと思います。
フォレンジックとは
フォレンジックは法科学の一種で、事故・事件の痕跡や証拠を調査して原因究明を行うことを指します。調査の対象（事故現場）がコンピュータなどの場合、デジタル・フォレンジックと呼ぶ方が正しいのですが省略されることもしばしばあります。
デジタル・フォレンジックでは主にコンピュータ、ネットワークなどのセキュリティ事故（インシデント）や内部不正行為などを調査解析して事故原因や裁判で取り扱う証拠の特定などを行います。
分かりにくいので、ピンとこない場合は名探偵コナンにでてくる鑑識のトメさんみたいなイメージをもっていただければと思います。
インシデント対応との違い
Webサイトが改ざんされたり、PCがウィルスに感染してしまったりなど、何かしらのインシデントが発生した場合の対応をインシデント対応（レスポンス）と呼ばれますが、フォレンジックとよくごっちゃになることも多いです。
この違いについてはよく火事の現場でたとえられます。
インシデント対応はいわゆる消防活動のように、とにかく火を消すことを目的としています。
フォレンジック調査は消火後の焼け跡から事故の調査を目的としています。
目的も対応も異なるので少し注意が必要です。現在進行形でインシデントが起きているかで判断ができると思います。
ただ、実際のケースでは曖昧な面もあるので両者を合わせてDFIR （Digital Forensics and Incident Response ）という言葉もあったりします。読み方はディファーらしいですがディエフアイアールと呼んでる人もいるのでどっちでも通じると思います。
AWS EC2 インスタンスのHDDの解析
今回は AWS EC2インスタンスで構築されているWebサイトが改ざんの被害にあってしまったという架空の設定で、EC2インスタンスのサーバのHDDの調査を行ってみたいと思います。
EC2 インスタンスの調査にあたっては、クラウド上にあるデータをダウンロードしてローカルの解析機で調査を行う方法や、調査専用のAWS環境を作成して全てクラウド上で調査を行ったりする方法などがあります。今回は懐をあまり気にせず気軽に調査できるダウンロードしての調査を行ってみたいと思います。
調査の簡単な流れ
ややこしいので詳しいことは後述しますが、フォレンジック調査の場合は主に「侵害のあった環境の保全」 -> 「保全したデータの解析」 -> 「報告をまとめる」の順で行います。
今回はAWS EC2環境にあるサーバですので、以下の流れで行いたいと思います。
1.侵害のあったAWS EC2 のデータを調査用のAWS アカウントにもってきて保全する
2.保全したデータを手元のWindows パソコンにダウンロードする
3.Windows パソコンでデータを調査してみる
EC2 インスタンスのHDD データの保全
フォレンジック調査ではいきなりサーバをいじくるのではなく、まず調査対象のデータの保全作業を行います。
「いや、サーバを触った方が早い」と思われるかもしれませんが、フォレンジックの観点では基本的にNGです。例えば殺人現場があったとして、被害者の遺体をいきなり触ったり現場を踏み荒らしてしまうと、犯人の足跡や指紋などの手がかりが失われてしまう可能性があります。
これはデジタルでも同じことで、ファイルのタイムスタンプやログなどを上書きしてしまって手がかりが失われてしまうことに繋がります。
このため、まずは重要なデータが書き変わらないようにデータを保全する作業の必要があるわけです。
保全でよくあるのがHDDやメモリーを丸ごとコピーする方法です。（イメージングやフォレンジックコピーとも言われます）。
これは通常のファイルのコピーではなく専用の機器やソフトウェアを使用して行いますので、例えば削除されたファイルなども復元することができる方法です。
それでは 改ざんされたWebサイトのインスタンスのハードディスクをコピーしてみます。EC2の場合はボリュームがHDDに相当しますが、ここではスナップショットを利用してボリュームを復元します。
調査においては事故発生日時に近いスナップショットがあればより重要なデータが出てくる可能性が高いためです。
また、AWS EC2 ではインスタンスのスナップショットは他のAWSアカウントと共有することができます。
この機能を使って被害のあったインスタンスのスナップショットをフォレンジック用のAWSアカウントからアクセスできるようにします。（もしスナップショットを取っていない場合は事前にスナップショットをとっておきます。）
調査対象のAWSアカウントでコンソールにログインし、EC2サービスの「スナップショット」を開きます。当該のスナップショットを右クリックして「権限の変更」をクリックします。
すると権限の変更ポップアップが表示されるので「AWSアカウント番号」の入力欄にフォレンジック用のAWSアカウントの番号を入力します（アカウント番号はハイフンなしの数字でいけました）。追加できたら「プライベート」になっていることを確認して保存ボタンを押します。パブリックにしてしまうと誰でも使用できてしまうため、絶対に設定しないように注意してください。
設定ができたら今度はフォレンジック用のAWS アカウント側でコンソールにログインし、スナップショットが共有できているか確認します。同じように EC2サービスの「スナップショット」ページを開きます。共有できたスナップショットのName欄は空になるため、スナップショットIDを見て一致しているかをチェックします。
ちゃんと共有ができたことが確認できれば、このスナップショットからボリュームを作成します。当該のスナップショットを右クリックして「ボリュームの作成」を選択し、新規のボリュームを作成します。
ボリュームが作成できたら、次に調査にあたっての下準備を行います。
調査・保全用インスタンスの準備
作成できたボリュームを調査するために、新規で調査用のインスタンスを作成してボリュームをアタッチします。これにより調査用インスタンスから中のデータにアクセスできます。
フォレンジック用のAWS EC2で調査用のインスタンスを作成して起動します。OS の種類は使いやすいもので良いと思います。今回は Ubuntu を使用しました。
調査対象のボリュームサイズが小さい場合は、インスタンス作成時に別途大き目のストレージを追加しておくとデータの一時置き場所として利用できて便利です。今回は20GBのストレージを追加しました。
なお、このまま調査用インスタンスを使用することで完全にクラウド上でフォレンジック調査を行うこともできます。
※ 調査用のインスタンスのセキュリティには注意してください。
インスタンスの作成ができたら、スナップショットから作成した調査対象のボリュームをアタッチします。EC2 の「ボリューム」ページからボリュームを右クリックし、「ボリュームのアタッチ」をクリックします。
ポップアップが表示されるので、間違えないようにインスタンスIDをセットしアタッチをクリックします。
アタッチができたら、調査用インスタンス側にSSHログインして fdisk -l などのコマンドで認識できているか確認します。
一度マウントして内容を確認してみます。マウントする際は必ず読み込み専用にする必要があります。書き込みを許可してしまうとデータが変化してしまって証拠として信頼性を失う恐れがあるためです。
やり直しは効くので、間違えた場合は再度スナップショットからボリュームを再作成して試してください。
「mount -o ro,noexec,nodev -t ext4 /dev/xvdf1 /mnt/yarare-linux-root」みたいな感じでマウントすると、被害のあったサーバのファイルを確認できました。
調査対象のサーバが使用しているタイムゾーンが分かっていない場合は対象の「/etc/timezone」ファイルなどで確認しておくと良いです。
確認ができましたら umount コマンドでマウントを解除しておきます。
HDDイメージファイルの作成
それでは調査用インスタンスでHDDイメージファイルを作成します。Linux の場合は「dcfldd」とよばれるddの拡張版のコマンドが使用できるので今回はこれを使用してHDDのイメージファイルを作成してみます。もちろん「dd」コマンドでも代用可能です。
インスタンス作成時に一時置き場のストレージ （20GB） を作っておいたので、あらかじめフォーマットして「/mnt/hozen 」に書き込みありでマウントしておきます。「/mnt/hozen」に移動し、先ほどの「dcfldd」コマンドを使ってHDD イメージを作成します。保全対象のHDDのマウントを解除していない場合はコマンドが失敗するので注意してください。
「dcfldd」ではハッシュ計算も行えますので、作成ができたらmd5sumなどでハッシュを確認してHDDイメージファイルの整合性を確かめます。
「yarare-hdd.img.aa」としてHDDイメージファイルが無事作成できました。画像ではコマンドのオプションで分割ファイル指定をしていますが、 容量が少なかったため8GB の単一ファイルとなっています。不要であれば分割オプションは外しても問題ありません。
確認ができたらイメージの作成は完了です。
ローカルPC （Windows）で解析
HDDイメージファイルが作成できたので、 scp などの暗号化通信を使用して「yarare-hdd.img.aa」と「md5.txt」「sha256.txt」ファイルを手元のWindows PCにダウンロードします。ファイルがダウンロードができたら再度ファイルのハッシュが一致しているか確認してください。
ちなみに、ローカルのPCからSSH経由でdd コマンドを実行してローカルのPCに直接HDDイメージファイルを作成する方法もあります。ストレージ追加の必要がなくなりますが、途中で失敗した場合は最初からやり直しになるのでケースバイケースですね。
それではHDDイメージファイルの解析にとりかかりましょう。今回は 「Autopsy」というツールを使用します。フォレンジックのツールはシェアウェア（有償）のものが多いのですが、Autopsy はオープンソースですので誰でも自由に使えて便利です。開発者に感謝しながら下記のURLからダウンロードし、インストールします。
Autopsy : https://www.autopsy.com/download/
Autopsy を起動するとポップアップが表示されますので、「新規ケース」を選択します。
ケース名を適当に入力し、ベースディレクトリ（Autopsy がケースデータを保存する場所）を選択します。
ケース番号や調査員の情報を入力します。調査員の情報は未入力でも問題ありません。
調査対象を指定します。今回はHDDイメージファイルですので、「ディスクイメージまたはVMファイル」を選択します。
調査対象のHDDイメージファイル（yarare-hdd.img.aa）を指定します。ここではタイムゾーンの指定に注意してください。ローカルの PC のタイムゾーンではなく、調査対象が使用しているタイムゾーンを指定する必要があります。間違ったタイムゾーンを指定すると Autopsy で表示されるタイムスタンプがずれてしまいます。
インジェストモジュールについては全てチェックを外すことをおすすめします。Autopsy にはインジェストモジュールという便利な機能があって解析の手助けをしてくれるのですが、かなり処理が重いため、最初に実行してしまうと読み込みに非常に時間がかかってしまいます。インジェストモジュールは読み込んだ後でも実行できますので、ここでは全てオフにしておくとスムーズに解析に移ることができます。最後に問題がなければ終了をクリックします。
読み込みが完了したら画面が切り替わり、左のメニュー欄「データソース」からHDDイメージを選択すると右側で詳細を閲覧することができます。これでHDD内のデータを調査、解析を進めることができます。調査のアプローチは人によって様々ですが、侵害箇所を重点的に見たり、攻撃者が残した「Hacked!」などのダーティワードから手がかりを得て調査を進めます。
※文字列検索を行うにはメニューの「ツール」から「インジェストモジュールを実行」でキーワード検索を実行します。個々のフォルダ単位でも右クリックから実行可能です。
HTTP デーモン（サービス）ではApache が使用されており、設定を確認すると侵害のあった Blog はどうやら WordPress を使用しているようです。ドキュメントルートを確認すると、WordPress のシステムファイルがあるディレクトリに backdoor.php という非常に不審なものが設置されていました。このバックドアの内容をみてみると、外部から任意のコマンド実行ができるような処理が含まれていることが分かりました。
また、WordPress のテーマのテンプレートファイルのfooter.php に backdoor.php を生成するコードが埋め込まれていることが分かりました。テンプレートファイルはWordPress の管理画面から編集できるので、管理画面に不正にアクセスされた可能性も考えられます。
Apache のアクセスログも見てみると、WordPressに対する攻撃が多数あり、管理者の接続元IPとは異なる不審なIPアドレスから、管理画面にログインしているアクセスが記録されていることがわかりました。どうやら攻撃者は脆弱なWordPress アカウントを使って管理画面に不正アクセスし、バックドアを仕込んだようです。
また、この不信なIPアドレスは backdoor.php にアクセスしている記録がありました。記録から「/etc/passwd」ファイルなども漏洩してしまっているようです。
まとめ
以上、EC2インスタンスのHDD解析でした。結構省略した点もあるのですが、もし興味がありましたら一度試してみていただけると嬉しく思います。
クラウド環境の場合は完全にオンラインなのでどうしても作業の手続きが増えてしまいますが、スナップショットやGuard Dutyなどの他のサービス、API などから情報を引き出せる点は非常に有利と言えます。
今回は検証環境のため攻撃者の分かりやすい痕跡が残されていますが、実際の攻撃者はログが残らないように行動したり、痕跡の削除や改ざんしたりといった行動をとるため調査の難易度は高いです。
また機会があればインシデント対応なども盛り込んでお話ができたらと思います。
