本サイトは、快適にご利用いただくためにクッキー（Cookie）を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
はじめに
皆さん、こんにちは！MBSDに所属する『とある診断員』の洲崎です。今年の10/18～12/6に開催されたセキュリティ・キャンプ2020全国大会にて、AWS環境におけるインシデントレスポンスをテーマとした以下の講義を行いました。
また、上記講義で作成した演習環境を利用した一般向けのセキュリティイベントを12/12にSecurity-JAWSさんと共催にて開催しました。こちらのイベントにはなんと130人以上の方が参加してくださいました！
これらの演習では、あらかじめ攻撃を行い、侵害されたAWS環境を演習環境として用意し、受講者にその環境を調査・解析してもらうことで、インシデントレスポンスを体験してもらうという内容になっています。今回のブログでは、本演習の概要と、演習環境を作りこむ中で色々苦労した点（主に私が担当した演習環境に行った攻撃のシナリオ作成など）について書こうと思います。
なお、本演習の資料は以下にて公開しています。
https://github.com/tigerszk/aws_sec_traning
また、演習環境の設計を担当いただいた講師の一人である臼田さんが本演習に関するブログを公開されていますので、よろしければそちらも是非ご覧ください。
https://dev.classmethod.jp/articles/review-security-camp-and-tigersecjaws-02/
どのような演習だったのか？
上述したように受講者の方に侵害されたAWS環境を調査していただくわけですが、ただ単に「では、早速調査してください。」という感じでは味気ないですよね。そのため、演習では「参加者はAWS環境を攻撃されてしまった会社のCTOから依頼を受けてインシデント調査を行う」という設定を設けていました。あらすじとして以下のようなものとなります。
『ある日某社のCTO宛に「貴社のAWS環境でコインマイナーが動作している」というAbuseレポートがAWSから届いた。調査を行った結果、AWS環境では見覚えないEC2が動作しており、仮想通貨をマイニングされていることを発見した。至急不正なEC2は停止したが、AWS環境がなんらかの攻撃を受けた可能性があり、現状では詳細が不明のため、同環境で提供しているWebサービスを一時停止している。「一刻も早くサービスを再開したいため、至急原因究明をしたい。是非とも君に調査をしてほしい！」かくして、CTOよりスーパーインシデントハンドラーのあなたにこの環境の調査が依頼されるのであった。』
某社の命運を丸投げされてしまっているなかなかひどい状況ではあると思いますが、参加者の方に楽しんでいただくために、このような設定を用意しました（笑）
調査を行うAWS環境は以下のような構成となっています。
図 1 AWS環境の構成
本環境では、Webサービスを提供しており、ALBの配下にWebアプリケーションが稼働するEC2が動作しています。そして、データベースはRDSを利用しているという非常にシンプルな構成の環境です。CloudTrailのログやWebサーバー（Nginx）のログはS3バケットに出力する設定としています。本演習ではリアルなAWS環境のインシデントレスポンスを参加者に体験してもらうというところにこだわっており、講師の一人である臼田さんが現実にありそうなAWS環境を色々検討されて設計・構築されました。そちらの詳しい内容については詳しくは臼田さんのブログをご覧ください。
また、このAWS環境では以下のような架空のWebサービスを提供しているという設定となっています。
図 2 セキュアなつぶやきを投稿できるSNS「Secutter」
このWebアプリケーションは講師の一人である角田さんが作りこんだ「Secutter」という名前のWebアプリケーションであり、ユーザーがつぶやきを投稿できるSNSサイトとなっています。もしかしたら「どこかでみたことがあるような…」と思われる方もいらっしゃるかもしれないですが、一応完全オリジナルのSNSサイトとなっています（笑）。
参加者の方が調査する環境は、インシデント発覚後の初動対応が完了した後の状態であるとしており、以下のような状態となっています。
図 3 演習時のAWS環境の状態
演習ではAWS環境におけるインシデント発生時に調査として良く行われると想定される以下の調査を体験します。
- 配布した調査用IAMユーザーを利用してAWS環境にログインし、リソースや設定状況について調査
- GuardDuty・DetectiveといったAWSが提供するセキュリティマネージドサービスを利用した調査
- Athenaを利用してS3上に出力した各種ログ（CloudTrail、Webサーバーのログ）について解析
- 攻撃を受けてしまったEC2のスナップショットより作成したEBSボリュームの中身を調査
ご覧の通り、この演習では、単体のシステムに関する侵害状況を調査するということではなく、AWS環境全体を調査の対象としています。また、AWSのマネージドサービスなどを駆使して調査を行っていくというところに主眼を置いており、実際にありそうな環境で、実際の現場で行われるような調査を行うことで、参加者にリアルなAWS環境でのインシデントレスポンスを体験してもらうことにこだわって作成しました。
上記のような調査を行い、判明した内容から以下項目について参加者に検討してもらうことが演習の課題となっています。
- 提供しているWebサービスへの影響有無について
- 不正なEC2が動作をしていた原因について
- サービスを再開するためには何をしなければならないか？
このAWS環境はどのような攻撃を受けてしまったのか？
さて、ここからはお題となったAWS環境が一体どのような攻撃を受けてしまったのかという種明かしをしていきたいと思います。以下はこのAWS環境で起こった攻撃の内容を図に表したものとなっています。
図 4 攻撃者の動き（管理者権限奪取まで）
まず、インシデントにおけるそもそもの発端は外部の攻撃者による「Secutter」サイトのWebアプリケーションに対する攻撃となります。攻撃者によって、Webアプリケーションに存在したSSRFの脆弱性を攻撃され、EC2にアタッチされていたIAMロールに紐づく認証情報を取得されています（図4中フロー1）。
その後、攻撃者は取得した認証情報を利用して、S3上のコンテンツの情報を収集し、配置してあったスクリプトコードを入手します。このスクリプトコードには別のIAMユーザーのアクセスキーがハードコードされており、攻撃者はこれによってさらに別の認証情報を取得しています。（図4中フロー2・3）。
攻撃者が新たに取得したIAMユーザーはLambda関数を作成・実行できるような権限を有していました。この権限とAWS環境に既に存在していた権限の高いLambda関数用のロールを悪用して、取得したIAMユーザーに管理者権限を付与するようなLambda関数を作成・実行し、攻撃者はAWS環境における管理者権限への昇格を成功させています（図4中フロー4・5・6）。
図5 攻撃者の動き（管理者権限奪取後）
管理者権限を奪取した攻撃者は、この後さらなる侵害を進めていきます。まずは手始めにバックドア用と思われるIAMユーザー及びアクセスキーを作成しています（図5中フロー7）。その後、「Secutter」サイトが動作するEC2サーバー内に侵入し、EC2内やRDS内に格納されていた機密情報を窃取しています（図5中フロー8）。そしてインシデント発覚のトリガーとなったEC2を作成し、仮想通貨のマイニングを実行していました（図5中フロー9）。
ということで、Webアプリケーションの脆弱性への攻撃を発端として、運用上の問題などを利用されてさらなる攻撃を受けた結果、最終的には管理者権限を奪取されAWS環境全体の侵害につながってしまうという恐るべきシナリオとなっていました。攻撃シナリオの細かい部分などが気になる方は講義資料の解説編のスライドにて細かく解説していますので是非ご覧ください。
なお、この演習について外部の勉強会で紹介した際に、「演習の攻撃シナリオをどのように作成したのか？」という質問をいただきました。折角の機会なので本ブログではそちらについて少し記載しようと思います。
攻撃シナリオを作成する際には、以下のようなものを参考にしました。
- 現実に起こったセキュリティインシデント
- 公開されているAWSセキュリティの教育コンテンツ
- ペネトレーションテストでの経験
まず１についてはやはり、現実にあった事例を組み入れた方がシナリオにリアリティがでると考えましたのでシナリオを作成する際に意識しました。例えば2019年にCapital One社で起きてしまった以下のセキュリティインシデントなどを参考にしています。
このインシデントはWAFの設定ミスにより存在したSSRFの脆弱性を攻撃され、S３バケットに格納されていた情報が漏洩してしまい話題となったものです。攻撃シナリオの最初の部分は、まさにこちらのインシデントを参考にして作成しています。それ以外にはインシデント発覚につながった「EC2インスタンス作成による仮想通貨のマインニング」も現実でよく起こるありがちなインシデント事例の一つとして組み込んでいます。
2については、筆者が勉強になったインターネット上で公開されているAWSセキュリティの教育コンテンツなどの内容を参考にして、現実にありそうな設定などを加えて作成しました。例えば攻撃シナリオの権限昇格の部分についてはCloud Goatで紹介されている手法を参考にして作成しています。
3については筆者が実際にペネトレーションテストの現場にて遭遇した事例を参考にしています。例えばシナリオ中の「認証情報がハードコードされているスクリプトコード」の問題についてはAWS環境だけではなく、様々な環境で非常によく遭遇する事例の一つです。また、シナリオ中で攻撃者がEC2内に侵入した際にAWS Secrets Managerを悪用してRDSの管理者権限を取得しているのですが、こちらについても実際の現場で筆者が遭遇した事例を参考に作成したものとなります。
このような感じで色々なパーツを組み合わせて、ウンウンうなりながらも楽しみながらシナリオを組み上げていきました。攻撃のシナリオを作成した本人が述べるのもなんですが、ご覧の通りこの攻撃者はこのAWS環境でかなりメチャクチャやっています。もしかしたら「これはあくまで演習でしょ？こんなの現実にはありえないでしょ？」と思われる方もいらっしゃるかもしれないですが、残念ながらそうとは限らないと思います。これは全く荒唐無稽というわけではなく、状況によっては十分現実に起きうる脅威だと考えます。このシナリオを作成するにあたって、AWSの認証情報が漏洩してしまった場合には、最悪これだけの被害につながってしまう可能性もあるため、注意しなければならないということを演習の参加者に理解していただきたいという強い思いもありました。演習を受講した参加者の皆さんにその思いが少しでも伝わっていれば幸いです。
なお、AWS環境における認証情報の漏洩やその対策などについては、過去JAWS DAYSで発表したこちらのスライドにもまとめてありますのでよろしければご参照ください。
演習の作成で苦労したこと
セキュリティ・キャンプの講義終了後に開催されたS-JAWSの勉強会で、本演習について発表させていただく機会があり、演習環境を作成する際の裏話について少しお話させていただきました。
上記スライド中で作成にあたって苦労した点を色々記載していますが、やはりその中でも今回のコンテンツを作成する際に、一番苦労したのは間違いなく「ログの作成」です。演習であるためには、ちゃんと参加者が解析できるように想定通りのログを残さなければなりません。しかも今回の演習では一つのサーバーというわけではなく、AWS環境全体にログや攻撃の痕跡を残す必要があり、またGuard Dutyなどにも意図したアラートを上げさせる必要がありました。そのため、ちょっとでも上手くいかなかった場合には、取得したログやアラートなどの情報をすべて破棄した上で、AWS環境自体を再構築してもう一回初めからやり直しとなります。
この作業は流石に手動ではやっていられません。そのため、AWS環境自体はCloudFormationで自動的に展開するなど、演習環境の作成に当たって当初より作業の自動化を意識していました。私が担当した攻撃の実行についても、一応今最初から最後まで、完全に作業を自動化できるようにしていました。ただそれでも、思うようにログが取れない事象が発生し、その度に原因究明を行いながら多分10回以上はリテイクしています…。
特に個人的にはGuard Dutyに思った通りにアラートを検知させることに非常に苦戦しました。当初はAWS環境側で攻撃用のサーバーを用意して、攻撃していたのですが、環境を運用し始めての期間が短いせいか、AWS環境からのアクセスではGuard Dutyが思ったように検知してくれなかったため、IPアドレスをAWSではなく、別クラウドのGCPで構築したサーバーから攻撃を行うことで検知せるように工夫したりしました。また、仮想通貨のマインニングについてアラートを検出させるために、AWS上で本物のコインマイナーを実行させて検出させるなどにも取り組んだりもしました。
まとめ
色々書きましたが、このように作成する側もトライ＆エラーの連続で大変でしたが、非常に色々勉強になり良い経験でした。もし、本演習に参加していただいた方がご覧いただいていればですが、演習に参加してどのように感じたのか、作成者側も非常に気になるため是非ともアウトプットしていただけると非常にうれしい限りです。また、本ブログが、もし同じように今後セキュリティ演習を作成される方の何かの参考になれば幸いです。
最後に、一緒に本演習を作成した臼田さん、角田さん、そしてセキュリティ・キャンプにて本演習を行うきっかけを与えてくれた中津留さん、本演習のイベント開催にご協力いただきましたS-JAWS運営の皆様、そして本演習に参加してくれた参加者の皆様に心から感謝したいと思います。
おすすめ記事
