セキュリティ Advent Calendar 2020の19日目の記事として、先日参加したインシデントレスポンス疑似体験の紹介と参加記録を書きます。
きっともっとハイレベル/詳細なwriteupは他の方から出ると思うので、参加したきっかけとか、その後どんな変化があったか、みたいなところを中止に書きたいと思います。
目次
イベント概要紹介
ということで、2020年12月12日(土)に開催された、とある診断員とSecurity-JAWS #2 に参加しました！
講義に使用された資料は
こちらに全部まとまっています。Youtube配信のアーカイブもあるので、AWS環境に入って色々調査する以外のことは体験できるようになっています👍
今回はAWS環境上に構築されたサービスのインシデントレスポンスを擬似体験する回ということで、抽選 & 土曜9:30-18:00 という普段だったら絶対スルーしてしまう条件でしたが、面白そうすぎて速攻申し込みしました。
午前中は主に座学。この後の攻撃解析のヒントになる内容があるかもというのもあり、普段より更に2段階くらいギアを上げて一生懸命聞いていました。こういうきっかけでinputしたものって、身につきやすい気がする。後日自分でも調査・検証してみたいなと思う攻撃方法も出てきて、とても内容の濃い講義でした！講義の資料も上記リンクにあるのでぜひ見てみてください。
運営の皆さんの振替襟記事はこちら！
- AWS環境における実践的なインシデントレスポンス演習の作成 | 調査研究/ブログ | 三井物産セキュアディレクション株式会社
- 「セキュリティ・キャンプ2020オンライン」と「とある診断員とSecurity-JAWS#02」で行った講義の資料を共有しつつ振り返ってみた | Developers.IO
参加のきっかけ
ちょくちょく参加しているSecurityJaws#19で「実践的なAWSセキュリティのインシデントレスポンス環境を作ってみた」というタイトルのLTが。あまり具体的な話が出てこず、「もっと話が聞きたいな〜」とか、これがseccampでの講義内容だったという話を聞いて「面白そう〜やってみたい〜！」と思っていたところにイベントの告知が。
その時のLT資料はこちら
ある日とあるWebサービスを提供している会社のCTOからAWS環境が侵害されてしまったとの連絡があなたのもとに届きます。
「AWSからAbuseレポートが届き、調査した結果、自社のAWS環境上でコインマイナーが動作していることを発見した。急いでコインマイナーは停止し、とりあえず提供サービスを一時停止した。サービス再開のために、このAWS環境の調査を君にお願いしたい！」
スーパーインシデントハンドラーの君に課せられた任務は、このAWS環境で一体何が起きたのかを解明することだ！
このページ好き(p13)。このノリ、もはやリアル脱出ゲームと言っても過言ではない。
更に、やられたサービスは
セキュアなつぶやき型SNS「secutter」
CMが良すぎた。子供達は夫に丸投げして参加する券（一年に4~5回使用可能）を使うやつだと判断し、相談もなしに参加をポチった。※ちゃんと朝早起きして週末の掃除・洗濯タスクや作りおきタスクはしたよ！
ちょっと真面目な話をすると、私は仕事では開発運用をメインにやっていて、もし何かしらのインシデントが起きた場合、始めにアラートを受け取る可能性が高い。セキュリティインシデントと判断がついたら即座にセキュリティ関連部署に連絡・解析を回すことになると思うので、実際の攻撃の詳細解析やレポートの作成まではやらないけども、初動対応と、そもそも検知・解析するのに何をやっておくべきなのかのヒントが得られるかもしれない、という思いもあり参加を決めました。
…というのは建前で、やっぱり一番の理由は「面白そう！」と思ったから。でも参加してみて、上記の視点でも参加してとても良かった。
現在仕事で関わっている案件はAzureメインだけど、対策の考え方やインシデントレスポンスの基本は活かせるかなと思って、そのとおりだった。
疑似インシデントレスポンス体験の記録と答え合わせ
午後の部は、上記紹介の通り、スーパーインシデントハンドラーになってAWS環境を直接覗いたり、WebServerのsnapshot imageを解析したりしました。
終盤で運営陣から「レポートDMしてくれてもいいで」という趣旨のコメントが有ったので
完全に欠落していることは承知の上で、時間内にどこまで解析できたか残すためにレポート送ったりしていました。今から tigerszk さんのコメント読んでみると「完全に理解した！という猛者の方は」って書いてありますね…💦
でもおかげでレポートへのコメント頂けたので結果オーライ（ありがとうございます！）
ちゃんとした解説は、冒頭の資料リンク先あるのでそちらをご参照ください。
以下、長いので畳んでおきます。
解析対象と答え合わせ
| 解析対象 | 自分の解析 | 解説 | 分かる内容 |
|---|---|---|---|
| Athena/Nginx log | ✓ | ・攻撃者のWebサイトへのアクセスログ ・からのSSRF攻撃の形跡 |
|
| Detective/GuardDuty | ✓ | ✓ | ・各環境構築・role作成などに携わったIAMと行動履歴・AccessKeyを奪取してからの犯人の行動 ・コインマイナーの挙動 ・etc... |
| IAM | ✓ | ・各IAMについている詳細なロール ・IAM・ロールのバージョン |
|
| S3 | ✓ | ✓ | ・UploadされてしまっているAccessKeyIDとSecretのセット |
| Athena/CloudTrail | ✓ | ✓ | ・各環境構築・role作成などに携わったIAMと行動履歴・AccessKeyを奪取してからの犯人の行動 ・etc... |
| Web service image | △ | ✓ | ・攻撃者の侵入形跡と実行コマンド ・流出した情報 |
| RDS | ✓ | ・インシデント発生期間のログやメトリクスは既に保持期限が過ぎてなくなっていたので、何も得られなかった |
Detectiveから解析に入ると良いよ、とのことでしたが、一段低レイヤのGuardDutyから見始めました。今回のインシデントは、なぜか()犯人がわかりやすい行動をしてくれていること、他のiamでの作業がかぶっていなさそうだったこと、対象時刻がかなり絞られていたことなどなどの有り難い状況が重なって、素のGuardDutyを時刻絞って見るだけでも十分だったのですが、時刻が絞り込め得ていなかったり、複雑なシステム・関係者の多いシステムだった場合はDetectiveである程度傾向を把握する・概要を推測するなどしてから挑むと良さそうです。
Athenaは、ちらっと見てCloudTrailと一緒だからいっか、とクエリをちょろっと試しただけで終わってしまいました。ここでnginxのログの存在に気づいて解析すべきだった。犯人のipアドレスまで割れてたのにな。
ここの解析が抜けていたことと、S3にクレデンシャルが上がっていること、これPublicじゃないけどこれが漏れたに違いないと早々に判断をしてしまったため、最初の攻撃のきっかけを見誤ってしまった。思い込みと雰囲気で動いては駄目だな。
imageについてはほとんど見る時間がなかったのと、コマンド実行履歴が残っているというところに目が行かず、「あー、imageフォルダにAWSクレデンシャルがあるなー、もしかしたらsecutterサイトからアクセスできちゃったかもなー」くらいしか確認できなかったのですが、
$ cd /mnt/victim_root/root $ less .bash_history
したらバッチリ操作が残っていました。
まとめると、自分は
主にCloudTrail, GuardDuty, IAM, S3 あたりを解析した結果
- 攻撃元のipアドレス（今回は有り難いことに固定だった）
- どの権限で操作したのか
- 何故その権限が奪取できたのか
- どの時刻にコインマイニング用のインスタンスを立ててクエリを送ったか
くらいのことがわかりました。
しかし、S3 bucketは公開状態ではなかったにもかかわらず何故その情報を取れたのか、そもそもAdmin権限が取れているのだからもっと色々できたはず(imageをもっと調査すべし)。というのと、DB(RDS)は無事か？(アクセス元になったimageを調査したらわかった)というのが調査・考慮漏れしていました。
提出したレポートのサマリと答え合わせ
1. Secutterサービスへの影響の有無について
インシデントによって、Secutterサービスは何か影響を受けているのか？
サービスへの直接の影響は見当たらなかった
-> ❌ Adminが取れている自体で影響はないというのはそもそもNGだった…
-> ❌ nginxリクエスト・imageの調査がてきていると、ソースコードや個人情報が窃取されていることがわかる
-> ❌ 更に、RDSへの接続情報も抜かれて、実際にserverからクエリを叩いた形跡があるので、同じDBにあったクレジット情報含めてデータが抜かれてしまっている
影響を受けていたのであれば具体的にどのようなものなのか？また、そう判断した根拠は何なのか？
-> 上で見当たらなかったと書いたので、ここは空白にして提出していた。
直ぐにサービスを再開しても良いのか？
クレデンシャルの露出・backdoorが仕掛けられている・漏洩しているクレデンシャル・特権があるため、塞いでからでないとNG
-> これは2.の対策をしてからじゃないと再開できないぞ、という意味ではOK。ただし、そもそも影響が全然見れていなかったのでNGですね。
2. 不正なEC2が動作していた原因について
いつ、誰によって作成されたのか？
- ip: xxx.xxx.xxx.xxx からのアクセス
- lambda-creator-user のクレデンシャルで作成された
- 2020/10/03 15:27:30 にinstance作成
-> ❌ SSRFの脆弱性を突いてWebサービスへのリクエストから攻撃を受けたのが最初
-> ❌ そこで最初に奪取されたのがread-s3-ec2-role
-> そのあとS3のbucketをreadの権限で見て、lambda-creator-userのAccessKey/Secretも窃取
そもそもインシデントが発生してしまった根本的な原因は何か？
- super-developerが、lambda-creator用のAccessKeyとSecretをPublicなS3 bucket serverless-codees-750218111169 にアップしてしまったため
- このクレデンシャルが漏洩・悪用された
-> ❌ 同上。SSRF。
-> 講義中に、そもそも super-developer が管理・統制の効いていない状態で好き放題リソース作ったりS3にクレデンシャル放り込んだりしたから、というのもあるよね、という話が。これは現場あるあるな気がするので、いくらスーパーなデベロッパーが来たとしても、ちゃんとガバナンスきかせないとこんな事が起こっちゃうかも。
3. サービス再開のための対策案について
サービスを復旧するために対応すべきことは何か？
- s3 bucketからのクレデンシャル情報の削除
- lambda-creator-userのAccessKey/Secretの剥奪 or ローテーション
- read-s3-ec2-roleのAccessKey/Secretの剥奪 or ローテーション
- backdoor用のIAM userのAccessKey剥奪・無効化
- sg-xxxxxxxx (evil-ec2) のsecurity group削除
- 直近で対応しなくてよいが、DBを分離すべき
-> 上記で上げたのの最後の2つ以外が「最優先で対応すべきこと」
さらに、
- パスワードハッシュを含むユーザーアカウント情報が漏洩しているので、ユーザーへのパスワード変更および同じパスワードを使いまわしているサービスのパスワード変更通知
- 利用者や関連機関に対する説明や謝罪（全然頭になかった！）
- 攻撃者によって作成されたAWSリソース・サーバー上のリソースの削除
- Secutter Web Appにおける脆弱性の対策
- RDSのパスワード変更
- IAM関連の見直しや各種AWSリソースの棚卸し
- IMDSv2の導入
といった対策が、サービス再開までに必要とのことです。説明や謝罪については、全く考えなかった。RDSについては口をふさいだのでアクセスできないようになるとはいえ、パスワードも使われちゃって漏洩してるので変更すべきということでしょう。
IMDSv2はSSRFに利用されてしまったEC2のメタデータサービスの代わりに利用出来るようになったもの。詳細は座学編のスライドのp39,p40参照。とある診断員とSecurity-JAWS#1のflaws編でも出てきました。
もっと細かいところや確認ポイントなどありますが、解説編スライドとレポート例に書いてあるので割愛。実際に自分で書いたレポートと解答を見比べるところで「いやーそんな気がしてたんだよねー」とふわっとわかってた気になるのを防げて良かったです(￣▽￣;)
その後、ちゃんと復習しましたよ報告。
Athenaでnginxリクエスト見てみたり
imageで気になるところを解析したり
この演習を受けて取った(取ろうと思った)行動
面白そうだからと参加してみたわけですけども、実際のインシデントレスポンスのイメージが付いたことや、具体的なツールを紹介していただいたおかげで、いくつか行動に移すことができました。
1. Abuseレポートの届き先の確認
- AWSは経験があったので大丈夫だけど、Azureは具体的にどの連絡先にどんなタイトルで来るのか知見がなかったため、いざというときに備えて確認しておきました。見逃したりしちゃうと大変なので。
2. IAM設計の見直し
- ちゃんと設計したつもりではあるものの、今一度見直さないとと思っています。とくに商用環境は顧客データなど機密度の高いデータがあることが多いので、super-developerみたいなIAMは、ユーザー向けシステム向け問わず作らないような設計になっているか再確認。
- システムに付いた権限を則る可能性もあるので、システム権限ガバガバになりがちだけどちゃんと絞らないと
3. 監査ログの取得と解析、アラートまでの流れを確認
- 「監査ログは出しとかなきゃねー」と思ってはいたものの、これもAzureでは実際何を設定したら何の記録を出してくれるのか細かいところまで見れていなかったので再確認。更に出すだけではなく、監視に組み込むためにアラートを上げるにはどうすればよいのか、どういうサービスが有るのかなどを確認しました。
4. git-secretsの導入
- 午前中の講義で出てきた
git-secrets、クレデンシャル情報をgithubにpushしてしまうのを防いでくれるツール- ちょうど13日のAdventCalendarで@Ken_Fujimotoさんが書いてくれていますね
- awslabsがメインで開発しているということで、Azureには対応してないんじゃないかと思ったけど、AzureにもGCPにも対応してた
実際は具体的な行動に起こせていないけど、ちょっと気をつけておこうというポイントも結構合ったりして本当に良かったです。ちょうど今新しいサービスの立ち上げ＆セキュリティ周りの対策中なので、タイミングとしてもとても良かった。
感想など
今回疑似体験したのは「あくまで1ケース」とは言え、インシデント発生時のイメージが付いてとても良かった。特に
- こういうインシデントを検知するための仕組みが我々にあるのか？
- Abuseレポート起因の場合はちゃんとAbuseを適切にハンドリングできるか？
- 解析・調査のための監査ログは取れているのか？
- 初動でimageのsnapshotを取るような手順になっているか？
あたりを考えるきっかけになったのが大きな収穫でした。
もともとさっぱり知見がなかった
- そもそもどのあたりから解析を始めるべきか
- 影響範囲の調査はどのように進めていくのか
みたいなところも、解説で丁寧にやっていただいて勉強になりました。
他の方も多数おっしゃっていましたが、こんな素敵なハンズオンを無料でやっていただいて感謝です！運用・監視に携わる人や、運用設計・DevSecOpsてきな人が受けても、めちゃめちゃ持ち帰るものの多いイベントだったと思います。
最後になりましたが、めちゃめちゃ安定した配信、chatでのサポートなどなど、企画・運用してくださった皆様ありがとうございました！
