Amazon Web Services（AWS）とセキュリティをテーマに活動している「Security-JAWS」が2017年8月24日に実施した第6回勉強会のレポート。第二弾では、ラックの関宏介さんが行なった「AWS環境におけるフォレンジック」の内容を紹介する。オンプレミスで発生する不正侵入・情報漏えいやWeb改ざんと、AWSのようなクラウドサービスとでは傾向や原因に違いはあるのだろうか？
手軽に立ち上げられるがゆえの侵害もあるAWS
冒頭、関氏はMentimeterを用いて「サーバーが侵害された経験はありますか？」と来場者にアンケートを取りつつ、自身がいくつか目にしたAWSにおける侵害事例を紹介した。
ラック 関宏介さん
1つ目のケースは「数十TBの通信が発生し、請求された料金を見て驚いた」というものだ。原因は、DDoS攻撃用のボットが仕掛けられていたこと。調査を進めると、他にもWebシェルやRATをはじめ、さまざまなハッキングツールが仕込まれていたことも判明した。侵入原因は、ミドルウェアの管理画面が公開状態にあり、しかも容易に推測可能なアカウント・パスワードが設定されていたことだ。「オンプレミスでよくあるケースだが、AWSでもよくある」（関さん）という。
2つ目のケースでは、ある日、AmazonのAbuse窓口から「DDoS攻撃元になっていますよ」と連絡が入った例だ。「英語のメールだったので、最初はスパムだと思ってスルーしていたが、何度も来るのでよくよく見たら、うちのIPが攻撃元になっているという連絡だった」（関さん）という顧客からの連絡を受けて確認すると、これまたDDoS攻撃用ボットを仕込まれていたことが判明した。オンプレミスで運用していた古いシステムを検証用にAWSで動かしてみたところ、やられてしまったそうだ。主な原因は、使用していたソフトウェアのバージョンが古かったこと。その上、不要なポートが空いており、しかもデフォルトパスワードが弱いなど、攻撃者につけ込まれる要素が複数あったという。
悪いことに、DDoSボットがroot権限で動いていたことも分かった。「ソースからインストールし、それをrootでコンパイルしてインストールし、管理者権限で動いていたことが原因だった。これで被害が大きくなってしまった」（関さん）。達人級の管理者ならばソースからインストールしてもパッチ適用、バージョンアップ作業などの運用が適切に行なえるだろうが、「古い資産がこのソースしかないから」という理由でソースからインストールするのは「危険な香りがする」（関さん）という。
3つ目のケースは、原因不明の負荷増大でサービスが停止してしまったというもの。これも古いバージョンのソフトウェアが動いていたことが原因で、脆弱性を突かれ、Bitcoinマイナーがインストールされてしまっていた。
関さんによると、こうしたAWSのインシデント事例を目にして感じる傾向がいくつかあるという。「オンプレミスの環境では必ずといっていいほどあるSSHの不正ログインは不思議なくらい少ない。AWSの設定がかなりセキュアなことが要因だと思われる」（関さん）という。
一方で「検証用サーバーの被害が多い。AWSでは気軽に立ち上げられるがゆえに、検証用にちょっと立ち上げてそのまま、というサーバーがやられるケースが多いようだ。また、オンプレミスとは異なり、ファイアウォールによる一括制御がしにくいせいか、知らずに開けていたポート、意図しない公開ポートからの被害も多い」（関さん）という。
AWSのインシデント事例の傾向
オンプレミスとは異なるデジタル・フォレンジックのテクニック
万一侵害を受けた際に、被害範囲の特定や原因究明のために行なうのがデジタル・フォレンジックだ。いわばデジタル版「鑑識作業」と表現できる。「OSのAPIを使わずに、ファイルシステムやメモリを直接見るため、OS上からは見えない情報も見える。ルートキットなどに感染している恐れがあってOSが信用できない状況で、侵入原因などを調査できるし、より詳細な情報を把握できる」（関さん）。
もちろん、限界はある。「削除済みエリア」の復元が可能といっても、上書きされ痕跡がすべては残っていないこともあるし、ファイルレスマルウェアやpostメソッドでのアクセスのようにもともと痕跡が残らない攻撃については、追跡が困難だ。また、「OSはきれいになっても、バックアップのWebコンテンツが汚染されていることもあり、そのまま戻すと、Webシェルなどバックドアのコードが残っていたりして、ヤラレタ状態に戻してしまうこともある」（関さん）といい、ステージング環境を用意しておく方がよいという。
オンプレミス環境の場合は、ハードディスクのイメージコピーを取得してデジタル・フォレンジックを行なうのが定石で、そのための専用装置も提供されている。「だがAWSでは、HDDを抜いてきてコピーすることはできず、こういう方法が使えないので、ソフトウェアによるイメージコピーを使う」（関さん）ことになる。もしAWS上のインスタンスでインシデントが発覚したら、やられてしまったボリュームのスナップショットを作成し、それを調査用インスタンスにアタッチした後、ddコマンドを用いてイメージを取得することになる。あとは専門業者に任せるか、デジタル・フォレンジック用のソフトウェアを用いて解析を行なえばよい。
「だが、時間をかけてはいられないとき、あるいは調査用にマスターアカウントをもらえないときには、SSHで接続し、コマンドを続けて打つことでローカルにイメージ出力を吐く、あるいはライブイメージングという方法もあることを知っていてほしい」（関さん）。時間がかかるように思えるが、圧縮をかければ意外と早く処理できるという。これはまた、AWSに限らず他のクラウドサービスや、物理的に立ち入りができないデータセンターでも活用可能な方法だ。
