AWS Metadata Service Exploitation: Exposing IMDSv1 and Steal

SSRFと誤設定がIMDSv1を露呈させ、攻撃者にIAM資格情報とAWS全体へのアクセスを許す仕組み

クラウド革命はセキュリティ、スケーラビリティ、シンプルさを約束しました。しかし、AWSのインフラには一見何の問題もないサービスに見えながら、多くのクラウド侵害の鍵となっているものがあります。それがインスタンスメタデータサービス（IMDS）です。SSRF攻撃や誤設定を通じてIMDSv1を悪用すると、攻撃者にIAM資格情報やインスタンスのメタデータ、そして敏感なリソースへの無制限アクセスを提供してしまいます。

最も悪名高い例は2019年のCapital Oneの侵害です。1億以上の顧客記録が漏洩し、8000万ドルの罰金と計り知れない評判のダメージをもたらしました。攻撃は高度なものではなく、多くの組織が今も見落としているよく知られた脆弱性を悪用したものでした。

AWSインスタンスメタデータサービスとは？

IMDSは、AWS EC2インスタンス内からアクセス可能なAPIエンドポイントです。IPアドレス169.254.169.254で提供され、アプリケーションやサービスが正常に動作するために必要な情報を提供します。内容は以下の通り:

インスタンス詳細：ホスト名、インスタンスID、ネットワーク設定
IAMロールの資格情報：一時的なアクセスキーとセッショントークン
ユーザーデータ：カスタムスクリプトや設定情報
セキュリティグループ：ネットワークアクセスルール

このサービスはAWSの運用に不可欠です。アプリケーションはIMDSを使ってIAMロールに紐づく一時的な資格情報を取得し、AWSアクセスキーをアプリにハードコーディングする必要を排除します。正しく使えば大きなセキュリティ向上となります。

IMDSv1とIMDSv2のセキュリティ上の違い

AWSは2つのバージョンのIMDSを提供しており、その違いを理解することが重要です：

IMDSv1（レガシーバージョン）: - シンプルなリクエスト-レスポンスプロトコル - HTTP GETリクエストのみ必要 - 認証やセッション管理なし - SSRF攻撃に脆弱 - 多くのインスタンスでデフォルトで有効

IMDSv2（セキュアバージョン）: - セッショントークンを用いたトークン認証 - 初期のPUTリクエストでセッションを開始 - トークンはカスタムヘッダー（X-aws-ec2-metadata-token）に含める必要 - TTLによるネットワーク攻撃からの保護 - SSRF脆弱性を効果的に緩和

問題は、2023年11月以降、新規インスタンスのデフォルトがIMDSv2に移行しているにもかかわらず、2022年時点で約93%のEC2インスタンスがIMDSv2を強制していないことです。多くの組織がIMDSv1を使い続けており、Capital Oneの侵害を可能にした攻撃ベクトルに晒されています。

IMDS悪用攻撃の流れ

なぜIMDSv1が危険なのか理解するために、攻撃者がSSRF脆弱性を通じてどのように悪用するかを見てみましょう。

ステップ1：偵察

攻撃者はAWSインフラ上の脆弱なアプリケーションをスキャンします。対象は: - ユーザー入力を持つWebアプリ - 公開されているインスタンスとサービス - ユーザー提供のURLに基づいてHTTPリクエストを行うアプリ - Webアプリケーションファイアウォール（WAF）の誤設定

ステップ2：SSRF脆弱性の発見

サーバーサイドリクエストフォージェリ（SSRF）は、アプリケーションが意図しない宛先にHTTPリクエストを送るように仕向けられる脆弱性です。典型的な脆弱シナリオは:

URLパラメータ：ユーザー提供のURLからコンテンツを取得
画像処理：外部ソースから画像をダウンロード・処理
Webhook：ユーザー指定のエンドポイントにコールバック
PDF生成：WebコンテンツをPDFに変換
ファイルアップロード：外部参照を含むファイルを処理

ステップ3：メタデータサービスへのアクセス

SSRF脆弱性を見つけたら、次にメタデータエンドポイントにアクセスします:

# EC2インスタンス内から直接アクセス
curl http://169.254.169.254/latest/meta-data/

# 脆弱なアプリ経由
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

ステップ4：IAM資格情報の抽出

本当の狙いはIAMロールの資格情報です:

# 利用可能なIAMロール一覧
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# 特定ロールの資格情報取得
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

これにより、以下のJSONデータが返されます: - AccessKeyId: AWSアクセスキー - SecretAccessKey: AWSシークレットキー - Token: セッショントークン - Expiration: 資格情報の有効期限

ステップ5：盗用資格情報の利用

これらの資格情報を使って攻撃者は: - 機密データを含むS3バケットの一覧とアクセス - 暗号通貨マイニングやさらなる攻撃のためのEC2インスタンスの起動 - セキュリティグループやネットワーク設定の変更 - データベースや他のAWSサービスへのアクセス - データの外部流出 - 永続化の仕組み構築

実例：Capital Oneの侵害

2019年のCapital Oneの侵害は、IMDS悪用の破壊的な可能性を示しています。概要は:

攻撃の流れ: - 2019年3月22-23日: 元AWS社員のPaige ThompsonがCapital OneのWebアプリファイアウォールのSSRF脆弱性を悪用 - 脆弱性の内容: WAFの誤設定によりSSRF攻撃がメタデータサービスに到達 - 資格情報の盗取: 一時的なAWS資格情報をEC2のIAMロールから取得 - データアクセス: 700以上のS3バケットをリストし、約30GBのデータをダウンロード - 2019年7月19日: GitHubやIRCで自慢したことで発覚

被害内容: - 1億600万件の顧客記録漏洩（米国100M、カナダ6M） - 社会保障番号14万件漏洩 - 銀行口座番号8万件漏洩 - カナダの社会保険番号100万件漏洩 - 名前、住所、信用スコア、取引データなどの個人情報 - 80百万ドルの罰金 - 総コスト150百万ドル超（対応と信頼失墜含む） - 深刻な評判のダメージと株価下落

根本原因: 1. WAFのSSRF脆弱性 2. より安全なIMDSv2ではなくIMDSv1を使用 3. 広範なS3アクセス権を持つIAMロール 4. 暗号化されていないS3ストレージ 5. 監視不足による検知遅れ（4ヶ月遅れ）

最も問題なのは、この攻撃は高度な技術を必要とせず、理解されている脆弱性の悪用だけで成り立った点です。

最近の攻撃キャンペーンと新たな脅威

IMDSの悪用は過去の話だけではありません。現在も脆弱なAWSインフラを狙った攻撃が続いています:

2025年3月のキャンペーン

セキュリティ研究者は、EC2上のウェブサイトをターゲットにした新たなキャンペーンを検知しました。主に以下を悪用:

CVE-2017-9841: PHPUnitリモートコード実行（2位のCVEより15倍活発）
CVE-2024-4577: 活動の持続的な増加
CVE-2019-9082: 攻撃試行の増加傾向

攻撃はASN 34534（FBW NETWORKS SAS）のIPアドレスから発信され、フランスとルーマニアにインフラがあります。攻撃者はシンプルなSSRF技術でIMDSv1エンドポイントを問い合わせ、資格情報を抽出しました。

Pandoc CVE-2025-51591の悪用

2025年9月、セキュリティ企業Wizは、Pandoc（人気のドキュメント変換ツール）の脆弱性を悪用し、AWS IMDSを狙った攻撃を発見しました。攻撃者はiframeのsrc属性にメタデータサービスを指す要素を含めることができました。

最終的にはIMDSv2の施行により失敗しましたが、攻撃者は新たなSSRFベクターを積極的に模索しています。

UNC2903脅威グループ

2021年6月、UNC2903はAdminerデータベース管理ツールの脆弱性を巧妙なリダイレクト技術で悪用しました。リレー用のリダイレクトスクリプトを設置し、被害者サーバーに誤ったリダイレクトを追わせ、AWS API資格情報を含むエラーを返させました。これにより、被害者のAWSアカウントにアクセスできました。

なぜIMDSv1は依然として重大なリスクなのか

2019年以降IMDSv2が利用可能になったにもかかわらず、IMDSv1は依然として大きなリスクをもたらしています:

技術的脆弱性

認証不要: IMDSv1は認証なしのGETリクエストを使用し、SSRF脆弱性があれば簡単にアクセス可能

リクエスト-レスポンスの単純なパターン: 攻撃者はサーバーにHTTP GETリクエストを強制させるだけ

ヘッダー不要: IMDSv2と異なり、カスタムヘッダーは不要で、基本的なSSRFでも悪用可能

組織的課題

レガシーシステム: 長期間稼働しているインスタンスはIMDSv1のみ対応の可能性

認識不足: 多くの組織はIMDSv1とIMDSv2のセキュリティ差を理解していない

デフォルト設定: AWSは新規インスタンスのデフォルトをIMDSv2に変更しているが、既存のインフラは未対応のまま

複雑な環境: 大規模なAWS展開では数千のインスタンスがあり、完全な移行は困難

検出と識別

問題を解決する前に、IMDSv1がまだ使われている場所を特定する必要があります:

AWSコンソールを使う

EC2ダッシュボードに移動し、各インスタンスの”IMDSv2”属性列を確認します。”Optional”と表示されているものはIMDSv1が有効です。

AWS Configルール

ec2-imdsv2-checkというAWS Configルールを導入し、HttpTokensが”optional”に設定されているインスタンスをNON_COMPLIANTとしてフラグ付けします。

CloudWatchメトリクス

MetadataNoTokenメトリクスを監視し、IMDSv1呼び出しを追跡します。値がゼロならIMDSv2のみを要求している状態です。

AWS Security Hub

クロスリージョン・クロスアカウントの集約設定を行い、組織全体のIMDSv1対応インスタンスを特定します。

IMDSパケットアナライザ

AWSのIMDS Packet Analyzerツールを使い、どのソフトウェアがIMDSv1呼び出しを行っているかを特定し、アップデートの優先順位をつけます。

総合的な対策戦略

IMDSの悪用を防ぐには、多層的なアプローチが必要です:

1. IMDSv2の即時強制

新規インスタンス向け:

# IMDSv2を必須にして起動
aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.micro \
  --metadata-options HttpTokens=required,HttpPutResponseHopLimit=1

既存インスタンス向け:

# 既存インスタンスにIMDSv2を要求
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1

Terraform例:

resource "aws_instance" "example" {
  ami           = "ami-xxxxx"
  instance_type = "t3.micro"
  
  metadata_options {
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

2. IAMロールの最小権限原則

IAMロールには必要最小限の権限だけを付与します。基本方針:

インスタンスの機能に必要な最小権限だけ付与
ワイルドカードのリソースARNは避け、具体的なリソースを指定
IAM条件キーを使って資格情報の使用を制限
定期的な監査とAccess Advisorによる権限縮小

IAM条件キー例:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::sensitive-bucket/*",
    "Condition": {
      "StringEquals": {
        "ec2:RoleDelivery": "2.0"
      }
    }
  }]
}

このポリシーは、IMDSv2経由で取得した資格情報だけがS3バケットにアクセスできることを保証します。

3. IMDSの無効化（不要な場合）

IMDSアクセスが不要なインスタンスには:

# IMDSを無効化
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-endpoint disabled

4. ネットワークレベルの保護

WAF設定: - AWS WAFを導入し、SSRF攻撃を検知・遮断 - 入力検証を厳格化 - メタデータエンドポイントを狙った不審パターンを監視

VPCセキュリティ: - セキュリティグループでアウトバウンド通信を制限 - ネットワークのセグメント化 - AWSサービス用のVPCエンドポイントを設定し、インターネット経由を避ける

5. アプリケーションコードのセキュリティ

入力検証: - ユーザー入力を信用せずHTTPリクエストを行う - 許可されたドメインのホワイトリストを実装 - プライベートIP範囲（169.254.x.x含む）へのアクセスを拒否 - URLパラメータの検証とサニタイズ

URLパース例:

from urllib.parse import urlparse

def is_safe_url(url):
    parsed = urlparse(url)
    
    # プライベートIPとメタデータサービスをブロック
    blocked_ips = ['169.254.169.254', '127.0.0.1', 'localhost']
    if parsed.hostname in blocked_ips:
        return False
    
    # 許可されたドメインのみ許可
    allowed_domains = ['trusted-domain.com']
    if parsed.hostname not in allowed_domains:
        return False
    
    return True

6. 総合的な監視

AWS GuardDuty: - 異常な資格情報使用やIMDS資格情報窃盗を検知

CloudTrailログ: - EC2からの異常API呼び出し - 予期しない場所からの資格情報使用 - 大規模な外部へのデータ転送 - IAMロールやポリシーの変更

AWS Security Hub: - 複数アカウント・リージョンの結果を集約し、セキュリティ状況を把握

7. サービスコントロールポリシー（SCP）の実装

AWS Organizationsを利用している場合、組織レベルでIMDSv2を強制:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "StringNotEquals": {
        "ec2:MetadataHttpTokens": "required"
      }
    }
  }]
}

これにより、IMDSv2未対応のインスタンスの起動を組織全体で防止できます。

今後の展望：移行のベストプラクティス

IMDSv1からIMDSv2への移行は計画的に進める必要があります:

フェーズ1：評価（1-2週間）

全インスタンスのインベントリ作成
IMDSv1使用のインスタンスを特定
各インスタンスのアプリとサービスをドキュメント化
IMDSv2対応のソフトウェア互換性を評価

フェーズ2：テスト（3-4週間）

SDK、CLI、ツールをIMDSv2対応バージョンに更新
非本番環境でIMDSv2を有効化しテスト
MetadataNoTokenのメトリクスを監視
カスタムスクリプトのIMDSv1呼び出しを特定・更新

フェーズ3：段階的移行（5-8週間）

重要度の低いワークロードから開始
IMDSv2を有効化しつつIMDSv1はオプションに
数日間の動作確認
安定したら本番環境へ展開

フェーズ4：完全施行（9週目以降）

IMDSv2を必須に設定
SCPでIMDSv1の使用を禁止
継続的な監視と改善
運用手順書の更新

ソフトウェア互換性

最新のAWSツールはIMDSv2に対応しています: - AWS SDK（主要言語対応） - AWS CLI v2 - AWS Systems Manager Agent - Amazon ECS Agent - Amazon Linux 2023（デフォルトでIMDSv2のみ）

レガシーアプリには、コンテナ化や対応バージョンへのアップデートを検討してください。

AWS以外のクラウドも視野に

この資料はAWSに焦点を当てていますが、他のクラウドプロバイダーにも類似のメタデータサービスがあります:

Google Cloud Platform: - 169.254.169.254のメタデータサービス - Metadata-Flavor: Googleヘッダーが必要 - このヘッダーはIMDSv2と同様のSSRF保護を提供

Microsoft Azure: - 169.254.169.254のメタデータサービス - Metadata: trueヘッダーが必要 - APIバージョンはURLに指定

Oracle Cloud Infrastructure: - 強化された認証を持つメタデータサービス - 多層アクセス制御

これらのプロバイダーは、AWSよりも早くヘッダーによる保護を導入しており、深層防御の重要性を示しています。

結論：今すぐ行動を

AWSのインスタンスメタデータサービスは、組織が無視できない重要な攻撃対象です。IMDSv1は2012年に導入されて以来、クラウド運用の基盤でしたが、脅威の進化により時代遅れかつ危険なものとなっています。

Capital Oneの侵害は、SSRF脆弱性とIMDSv1の組み合わせが攻撃者にとって完璧な状況を作り出し、1億を超える顧客記録と1億5000万ドル超の損害をもたらした例です。最近の攻撃も、攻撃者が積極的にSSRF脆弱性を探し続けていることを示しています。

良いニュース：AWSはIMDSv2を通じて堅牢な対策を提供しており、包括的なセキュリティコントロールも整っています。

悪いニュース：多くの組織はこれらの対策を実施しておらず、他の被害例と同じ運命をたどる危険にさらされています。

緊急の呼びかけ：IMDSv1を使い続ける限り、クラウドの鍵を攻撃者に渡し続けることになります。2019年のCapital Oneの侵害から6年経ちましたが、IMDSv2の実装は待つ必要はありません。

今すぐ実行すべきアクション

今週：全EC2インスタンスのインベントリを作成し、IMDSv1の使用状況を確認
今月：AWS ConfigルールとSecurity Hubを導入し、継続的に監視
今四半期：全インスタンスのIMDSv2移行を完了
継続的に：新規インスタンスに対してSCPを使いIMDSv2を強制
継続的に：監視と監査を行い、IAMロールの権限を見直す

クラウドの鍵は、あなたの目の前にあります。攻撃者に見つかる前に守るのか、それとも次の警告例となるのか。今すぐ行動を起こしましょう。

追加リソース

キーワード：AWS IMDS、IMDSv1、IMDSv2、SSRF攻撃、EC2セキュリティ、AWSメタデータサービス、Capital One侵害、クラウドセキュリティ、IAM資格情報、インスタンスメタデータサービス、AWSセキュリティベストプラクティス、サーバーサイドリクエストフォージェリ、クラウドエクスプロイト、AWS脆弱性、EC2資格情報窃盗