AWS IMDSv2.

IMDSv2 は EC2 インスタンスメタデータサービスの第 2 版であり、Capital One 侵害やその他の SSRF を起点としたクラウド資格情報窃取への直接的な対応として、AWS が 2019 年 11 月に導入した。2019 年 7 月 19 日に公表されたこの侵害では、Paige Thompson（「erratic」）が、設定不備のあった Web アプリケーションファイアウォールのサーバーサイドリクエストフォージェリ（SSRF）の脆弱性を悪用し、リンクローカルエンドポイント http://169.254.169.254/latest/meta-data/iam/security-credentials/ に到達した。この WAF に付与されていた過剰な権限を持つ IAM ロール ISRM-WAF-Role が一時的な STS 資格情報を返し、彼女は 700 を超える S3 バケット（およそ 1 億 600 万件の顧客レコード）を一覧化しコピーすることができた。この事案は後に、Capital One に対する OCC からの 8,000 万ドルの制裁金と、1 億 9,000 万ドルの集団訴訟和解金という代償をもたらした。

IMDSv2 が SSRF を阻止する仕組み

IMDSv1 では、メタデータ IP への任意の GET が資格情報を返していたため、リフレクション型やサーバーサイドのリクエストフォージェリだけで十分だった。IMDSv2 はこのフローをセッション指向にする。すなわち、クライアントはまず X-aws-ec2-metadata-token-ttl-seconds ヘッダーを付けて PUT /latest/api/token を実行し、返されたトークンをすべての読み取りリクエストで X-aws-ec2-metadata-token ヘッダーとして送信しなければならない。単純な SSRF ではカスタムヘッダー付きの PUT を発行することは容易ではなく、また HttpPutResponseHopLimit: 1 を設定することで、ネットワーク的に 1 ホップ離れたコンテナがサービスに到達するのを防げる。

flowchart TD
  A[App with SSRF flaw] -->|GET 169.254.169.254| B{Metadata mode?}
  B -->|IMDSv1 optional| C[Returns IAM credentials]
  C --> D[Attacker exfiltrates S3 data]
  B -->|IMDSv2 required| E[Rejected: no session token]
  E --> F[PUT /latest/api/token + TTL header needed]
  F -->|SSRF cannot issue PUT| G[Credential theft blocked]

防御策

SCP またはアカウントレベルの instance-metadata-defaults 設定を通じて、組織全体で HttpTokens: required を強制し、ホップ制限を 1 に固定し、CSPM や Wiz の検出結果を活用していまだ IMDSv1 を許可しているレガシー AMI を探し出す。インスタンスロールの IAM ポリシーを最小権限に絞り込み、トークンが漏洩してもほとんど得るものがない状態にする。