概要
現代のクラウド環境では、設定ミスや安全でないコーディング慣行が、攻撃者にとって危険な入口を開いてしまうことがあります。重要な例の一つがサーバーサイド・リクエスト・フォージェリ（SSRF）で、攻撃者がサーバーを操作して意図しないリクエストを送らせることができる脆弱性です。SSRFがAWSのようなクラウド基盤に対して悪用されると、一時的なIAM認証情報を含む機密性の高いインスタンスメタデータが露出する可能性があります。
本ブログ記事では、EC2上でホストされるアプリケーションにおけるSSRF脆弱性が、AWS Instance Metadata Service（IMDS）へのアクセスにどのように悪用され、それがクラウドリソースの侵害につながり得るかを解説します。攻撃対象領域を整理し、悪用手順を示し、これらの脅威からAWS環境を防御する方法を議論します。
なぜこの攻撃が起きるのか
SSRFを悪用してAWSメタデータへアクセスできてしまうのは、安全でないアプリケーションロジックとクラウド基盤側の前提が組み合わさることで発生します。この攻撃が可能になる理由は次のとおりです。
1. 検証されていないユーザー入力を信頼している
多くのWebアプリケーションは、ユーザーがURLを指定し、サーバーが後でそのURLからデータを取得することを許可しています（例：画像取得、Webhook、外部APIなど）。この入力が厳密に検証されていない場合、攻撃者はそれを操作して任意の内部アドレスへリクエストを送らせることができます。
例：GET /proxy?url=http://evil.com
SSRFペイロード：GET /proxy?url=http://169.254.169.254/latest/meta-data/
2. メタデータサービスへのアクセスが無制限
AWSのInstance Metadata Service（169.254.169.254）は、EC2インスタンス内部からのみアクセスされることを想定しています。しかし、インスタンス上で動作する脆弱なアプリケーションがそこへリクエストを送ってしまうと（意図せずであっても）成功してしまいます。既定では資格情報やトークンは不要で、IMDSv2が強制されていない限り成立します。
3. 権限過多のIAMロール
EC2インスタンスに広範な権限を持つIAMロール（例：S3、DynamoDB、EC2へのフルアクセス）が付与されている場合、盗まれた一時的認証情報はAWSアカウント全体にわたって強力な操作に悪用され得ます。
4. ネットワークレベルの保護が欠如
既定では、EC2インスタンスは制限なくメタデータサービスへアクセスできます。追加のネットワークルールやメタデータアクセスフィルタがない場合、インスタンス上のあらゆるプロセス（脆弱なアプリを含む）が到達可能です。
攻撃対象領域の理解
1. EC2メタデータサービス（IMDS）
EC2 Instance Metadata Serviceは、内部のリンクローカルIPアドレス http://169.254.169.254 で利用できます。以下のようなインスタンス情報を提供します。
- インスタンスID、AMI、ホスト名
- 関連付けられたセキュリティグループ
- 一時的なIAMロール認証情報（IAMロールが割り当てられている場合）
EC2インスタンス内部からのみアクセスされる設計ですが、SSRFにより攻撃者が間接的に到達する経路が生まれます。
2. 公開されているアプリケーション
多くのEC2インスタンスは、フォーム、クエリパラメータ、ヘッダー、APIなどを通じてユーザー入力を受け取り、その入力を使ってリモートリソースを取得するWebアプリケーションをホストしています。適切な入力検証がないと、攻撃者がサーバーに任意のURL（内部URLを含む）を取得させるSSRFに脆弱となる可能性があります。
3. IAMロール認証情報
EC2インスタンスにIAMロールが割り当てられている場合、一時的な認証情報はメタデータサービス経由で次の場所から取得できます。
http://169.254.169.254/latest/meta-data/
これらの認証情報は、ロールのポリシーで定義された権限に基づき、AWSサービス（S3、DynamoDBなど）へアクセスするために使用できます。攻撃者がSSRF経由でこれらの認証情報を取得すると、インスタンスのアイデンティティを引き継ぎ、侵害されたインスタンスの代わりにAWSリソースへアクセスできてしまいます。
AWSメタデータサービスへのアクセス
-
メタデータエンドポイントを狙う
SSRF脆弱性をEC2メタデータサービス（169.254.169.254）へ向ける
エンドポイント：http://169.254.169.254/
-
インスタンスIDを特定 メタデータパスを照会してインスタンスIDを取得する、またはサービスデータを使用する
エンドポイント：http://169.254.169.254/latest/meta-data/
-
IAMロール名を抽出 メタデータ構造を辿り、インスタンスに割り当てられたIAMロール名を見つける
エンドポイント：http://169.254.169.254/latest/meta-data/
-
AWS認証情報を取得 セキュリティ認証情報エンドポイントへアクセスし、AccessKeyId、SecretAccessKey、SessionTokenを取得する
エンドポイント：http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-instance
AWSメタデータサービスは階層構造の情報を公開しています。SSRF脆弱性を通じてこの構造を段階的に辿ることで、より機密性の高い情報を順に抽出でき、最終的にはインスタンスのIAMロールに割り当てられた一時的なAWS認証情報に到達しました。
認証情報の抽出手法
攻撃者がSSRFを成功させてEC2インスタンスメタデータサービスへアクセスすると、インスタンスのIAMロールに割り当てられた一時的なセキュリティ認証情報を取得できます。これらの認証情報は正当なワークロードがAWSサービスと安全に連携するために設計されていますが、悪用されると強力な武器になります。
メタデータサービスからの応答には、認証付きのAWS API呼び出しに必要な要素がすべて含まれます。
- アクセスキーID
APIリクエストで認証情報を参照するために使用される、公開可能な識別子。 - シークレットアクセスキー
AWSリクエストを暗号学的に署名するために使用される機密値。このキーは秘匿する必要があり、アクセスできる者は誰でもロールの権限で操作できてしまいます。 - セッショントークン
認証情報が一時セッションの一部であることを証明する追加の認証要素。多くのAWSサービスで、アクセスキーとシークレットを使用する際に必要です。 - 有効期限
認証情報が無効になる時刻を示すタイムスタンプ。短命（通常は数時間）ですが、この時間枠でも攻撃者がリソースへアクセスしたり、データをダウンロードしたり、さらには権限を拡大したりするには十分な場合があります。
SSRF脆弱性の影響
サーバーサイド・リクエスト・フォージェリ（SSRF）は、一見すると単にサーバー側でHTTPリクエストを行うだけで無害に見えるかもしれません。しかしAWSのようなクラウド環境では、その影響は深刻かつ広範囲に及び得ます。
1. クラウド認証情報の窃取
攻撃者はSSRFを悪用して169.254.169.254のEC2Instance Metadata Serviceへアクセスし、一時的なIAM認証情報を取得できます。これによりインスタンスになりすましてAWSサービスとやり取り（例：S3データのダウンロード、EC2インスタンスの一覧取得）できます。
2. 内部ネットワークスキャン
SSRFは、公開されていない内部サービスやクラウドコンポーネントを探索するために使用されることがあります。例：
- 内部管理パネル
- Redis、Elasticsearchなど
- Kubernetesメタデータエンドポイント
これは横展開や権限昇格の助けになります。
3. 内部APIおよびサービスへのアクセス
多くの組織は、内部トラフィックを信頼する内部専用APIを運用しています。SSRFはその信頼境界を迂回し、攻撃者に次を可能にします。
- 不正な操作の実行
- 機密データへのアクセス
- 他の内部サービスの悪用
4. ファイアウォールおよびネットワーク制限の回避
SSRFはサーバー内部から発生するため、境界ファイアウォールで保護されたエンドポイントにも到達できます。これにより脆弱なアプリケーションが事実上プロキシとなり、攻撃者は次を行えます。
- IPホワイトリストの回避
- 本来到達できない内部資産への到達
5. ピボットと追加の悪用
高度な攻撃では、SSRFを足がかりにインフラのより深部へ侵入するためのピボットとして利用できます。
- クラウドメタデータエンドポイント（AWS、GCP、Azure）からトークンを窃取
- データベースや設定サービスへ到達
- 単純なWebアプリのバグからクラウド全体の侵害へエスカレーション
緩和策
1. IMDSv2を有効化
メタデータアクセスにセッションベースのトークンを要求するInstance Metadata Service Version 2（IMDSv2）を使用してください。これにより、インスタンスとメタデータサービスの間に認証の層が追加され、単純なSSRF攻撃が成功しにくくなります。
2. 厳格なURL検証を徹底
アプリケーションが外向きリクエストを行う前に、ユーザー提供URLをすべてサニタイズし検証してください。危険なパターンをブラックリスト化するのではなく、許可するドメインのホワイトリストを使用します。IPや内部リソースへの直接アクセスは決して許可しないでください。
3. ネットワークアクセスを制限
セキュリティグループとネットワークACLを使用して、明示的に必要な場合を除き、EC2インスタンス（またはその中のコンテナ）が169.254.169.254へアクセスできないようにブロックしてください。HTTPリクエストが必要なアプリについては、厳格な許可リストを備え、メタデータへアクセスできないプロキシ経由でルーティングしてください。
4. IAMロールに最小権限を適用
EC2のIAMロールには必要最小限の権限のみを付与してください。SSRFで認証情報が露出しても、権限を制限しておけば攻撃者のエスカレーション能力を低減できます。不要な権限がないか、IAMロールとポリシーを定期的に監査してください。
Resecurityは、以下のフェーズを含むOWASP Web Application Security Testing（WSTG）に従って、企業が詳細なアセスメントを実施することを推奨します。
4.1 情報収集
4.2 設定およびデプロイメント管理のテスト
4.3 アイデンティティ管理のテスト
4.4 認証のテスト
4.5 認可のテスト
4.6 セッション管理のテスト
4.7 入力検証のテスト
4.8 エラーハンドリングのテスト
4.9 脆弱な暗号のテスト
4.10 ビジネスロジックのテスト
4.11 クライアントサイドのテスト
4.12 APIテスト
当社の専門家は以下の業界資格を保有しており、Fortune 500の主要企業および政府機関との成功実績を豊富に有しています。
- CISSP
（Certified Information Systems Security Professional） - CEH
（Certified Ethical Hacker） - CISA
（Certified Information Systems Auditor） - GIAC
GCIH（Certified Incident Handler） - Offensive
Security Certified Professional（OSCP） - GIAC
Web Application Penetration Tester（GWAPT） - eLearnSecurity
Certified Penetration Tester eXtreme（eCPTX） - eLearnSecurity
Web Application Penetration Tester Extreme（eWPTXv2） - eLearnSecurity
Certified Professional Penetration Tester（eCPPTv2） - Attify
Certified IoT Security Pentester（ACIP） - eLearnSecurity
Mobile Application Penetration Tester（eMAPT） - Certified
Red Team Professional（CRTP） - CREST
Registered Penetration Tester（CRT） - CREST
Practitioner Security Analyst（CPSA）
いつでも[email protected]までお気軽にご連絡ください。
当社のスペシャリストが、Webアプリケーションセキュリティ、モバイルアプリテスト、APIテストについて喜んで支援いたします。ResecurityによるVAPT（脆弱性評価およびペネトレーションテスト）サービスの詳細については、こちらのページをご覧ください。
