IMDSとセキュリティ ~SSRF攻撃から学ぶ、EC2メタデータの作り方~

Transcript

1. IMDS と セキュリティ SSRF攻撃から学ぶ、EC2メタデータの守り方 クラウド食堂 #8 ~クラウド初心者応援LT会~
2. @hiro_eng_ @hiro_217 自己紹介 Hiroto 所属　：金融事業部損保事業部 年次　：3年目 AWS歴：2年
3. 機能の設計と 画面の構成 IMDSとは何か？ IMDS：Instance Matadata Service 役割 ：EC2インスタンスが自分自身の情報を取得する内部エンドポイント エンドポイント：http://169.254.169.254/latest/meta-data/ リンクローカルアドレス（169.254.X.X）を使用 インターネットから直接到達不可能な設計 IAMロール紐付き時は一時クレデンシャルも取得可能
4. 機能の設計と 画面の構成 IMDSとは何か？ IMDSで取得可能な情報 カテゴリ 取得できる情報 リスク インスタンス情報 インスタンスID、AMI-ID 低 ネットワーク情報 IP、MAC、VPC-ID 中 IAMクレデンシャル AccessKey、Token 高 ユーザーデータ 起動時スクリプト 高 IAMロールがあればクレデンシャルは常に取得可能
5. 機能の設計と 画面の構成 IMDSv1には問題があった IMDSは単純なGETリクエスト1本でメタデータを取得できる IMDSv1のアクセス方法と問題点 認証なし、セッションなし、トークンなし サーバーが「代わりに」送れば即座に取得可能 SSRF攻撃と組み合わせると致命的な情報漏洩に繋がる
6. 機能の設計と 画面の構成 SSRFとは SSRF：Server-Side Request Forgery 役割 ：攻撃者がサーバーに「代わりにリクエストを送らせる」攻撃手法 攻撃者は直接内部ネットワークにアクセスできない 脆弱なサーバーを踏み台にして内部リソースに到達できる OWASP Top10 2021に単独カテゴリとして追加された重大な脆弱性 クラウド環境ではIMDSが主要な攻撃ターゲットとなる
7. 機能の設計と 画面の構成 SSRFとは 引用
8. 機能の設計と 画面の構成 Capital Oneの情報漏洩（2019） 2019年7月、米大手金融機関Capital Oneが史上最大規模の侵害を受けた 被害規模：米国 1億人以上、カナダ 600万人の個人情報が流出 流出情報：氏名、住所、電話番号、メールアドレス、与信情報等 原因　　：WAFの設定ミス+SSRF攻撃 の組み合わせ DevSecOps先進企業でも被害を受けた点が業界に衝撃を与えた 事件の概要
9. 機能の設計と 画面の構成 Capital Oneの情報漏洩（2019） WAFの設定ミスを起点に、クレデンシャルが窃取された ① WAFに ProxyRequests On の設定ミス（オープンプロキシ化） ② 攻撃者がWAF経由でIMDSへリクエストを送信 ③ WAFのIAMロールから一時クレデンシャル情報を取得 ④ S3から1億件越えの個人情報を窃取 攻撃の流れ
10. 機能の設計と 画面の構成 Capital Oneの情報漏洩（2019） DevSecOps先進企業が侵害された構造的な背景 なぜ防げなかったのか？ AWSの過度な信頼と責任共有モデルの理解不足 IAMロールに最小権限の原則が守られず過剰な権限を付与していた WAFが攻撃の入り口になるリスクを想定していなかった セキュリティ人材の恒常的な不足
11. 機能の設計と 画面の構成 IMDSv2で何が変わったのか v2では2ステップのフローでのみメタデータが取得可能に IMDSv2のセッション指向アクセス ステップ１：PUTリクエスト+カスタムヘッダでトークン取得 ステップ２：トークンをつけてメタデータを取得
12. 機能の設計と 画面の構成 PUTリクエストが必要：典型的なSSRF攻撃はGETのみ誘導できる 　　→PUTを強制送信できる脆弱性は攻撃難易度が大きく上がる カスタムヘッダーが必要：X-aws-ec2-metadata-token-ttl-seconds 　　→通常のSSRFでは任意ヘッダーを付与させることが困難 IMDSv2で何が変わったのか 2つの仕組みがSSRF攻撃を難しくしている IMDSv2がSSRF攻撃を緩和できる理由
13. 機能の設計と 画面の構成 aws-ec2-describe-instancesで確認すると、、 “HttpTokens” : “optional”　 → v1とv2の両方が有効 “HttpTokens” : “required”　→ v2のみが有効（v1は無効） 「v2を有効にするだけ」では不十分 IMDSの設定には「Optional」と「Required」の2種類がある 要注意：Optional設定ではv1が生きている “optional”になっていないかを必ず確認
14. 機能の設計と 画面の構成 カスタムヘッダーを付与できる高度なSSRF攻撃は存在する Open DirectとSSRFの組み合わせる迂回も可能 SSRF攻撃そのものをアプリ実装で排除することが根本対策 IAMロールの権限が過剰であれば、取得後の被害が拡大する 多層防御が重要 v2を強制しても、より高度な攻撃には対応できない場合がある IMDSv2は「緩和策」であり「完全な防御」ではない
15. 機能の設計と 画面の構成 多層防御が重要 多層防御でやるべき一例 レイヤー 対策 優先度 メタデータ IMDSv2のRequired化 高 IAM 最小権限の原則を徹底 高 アプリ SSRF脆弱性の排除 高 組織 SCPでv1起動を拒否 中 監視 Security Hub/GuardDuty 中
16. 機能の設計と 画面の構成 多層防御が重要 SCPによる組織全体でのv1有効化を禁止 v2必須化されていないインスタンスの起動を拒否
17. 機能の設計と 画面の構成 多層防御が重要 Security Hubによる継続的な監視 ルール：EC2.10 - IMDSv2を使用する必要がある IMDSがOptionalのインスタンスを即時検出 設定変更も継続的なモニタリング GuardDutyと組み合わせることで不審なアクセスも検知可能に FSBP(Foundation Security Best Practices)のルールでOptionalインスタンス を自動検出・通知
18. 機能の設計と 画面の構成 まとめ IMDSv2の全体像 IMDSv1は認証なし・SSRFと組み合わせると極めて危険 Capital Oneの情報漏洩はその典型例（1億人の情報流出） IMDSv2の「Required」設定でv1を完全に無効化する Optional設定のままではv1は生きていることを意識する SCP、IAM、アプリでの多層防御が重要 IMDSv2は入口。多層防御で本当の意味の安全を確保する。
19. 機能の設計と 画面の構成 Appendix AWS公式: Instance Metadata Service を使用してインスタンスメタデータにアクセスする 　　https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/configuring-IMDS-existing-instances.html AWS re:Post: インスタンスメタデータオプションの設定 　　https://repost.aws/ja/knowledge-center/ec2-configure-instance-metadata-tags クラスメソッド: IMDSv2でセキュリティを強化しましょう 　　https://dev.classmethod.jp/articles/use-ec2-imdsv2/ クラスメソッド: IMDSv2 のみの設定が反映されたか確認する方法 　　https://dev.classmethod.jp/articles/tsnote-ec2-imdsv1-imdsv2/ Krebs on Security: What We Can Learn from the Capital One Hack 　　https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/ AMImedia: 米国金融機関を襲った個人情報大規模流出事件の真相 　　https://www.amiya.co.jp/media/article/blaze23_special0101/ WebApp Testing: Webアプリケーションの脆弱性を利用した認証情報の窃取 　　https://webapppentestguidelines.github.io/newtechtestdoc/docs/cloudsec/cloud_credential/ Vectra AI: SSRF 2025年完全セキュリティガイド 　　https://ja.vectra.ai/topics/server-side-request-forgery
20. ご清聴ありがとう ございました! 今回のLTについて質問事項、指摘等ありまし たら、ご連絡いただけると幸いです！ @hiro_eng_