クラウドメタデータエンドポイントの隠れた攻撃面

主要なクラウドプロバイダーはいずれも、自社のプラットフォーム上で動作する仮想マシンに対して、インスタンスメタデータサービスを提供しています。通常はリンクローカルアドレスの 169.254.169.254 で到達できます。インスタンス内部からこのアドレスに単純なHTTPリクエストを送るだけで、インスタンスの設定やネットワークの詳細が返ってきます。さらに、多くの既定の構成では、そのインスタンスに割り当てられたロールやIDに対応する一時的なセキュリティ認証情報まで取得できます。

SSRFと組み合わさったときに特に危険な理由

メタデータエンドポイントは、本来インスタンス自身からしか到達できないはずで、公開インターネットには公開されていません。ところが、サーバー側のプロセスをだまして、攻撃者が選んだアドレスにHTTPリクエストを送らせることができ（典型的なSSRFです）、そのアドレスがたまたまメタデータエンドポイントだった場合、攻撃者はサーバー自身にクラウドの認証情報を取得させ、レスポンスとして受け取れてしまいます。外部からメタデータエンドポイントへ直接アクセスする必要はありません。脆弱なサーバーが攻撃者に代わって取得を行ってくれるからです。

• 169.254.169.254 は、より広い 169.254.0.0/16 のリンクローカル範囲に含まれます。この範囲は、正当な公開DNS解決の対象として扱うべきではありません。
• 単純なSSRFへの対策として、トークンを必須とするバージョンのメタデータサービスへ移行したプロバイダーもあります。しかし、アプリケーション層でこのアドレスを完全にブロックするほうが、より堅牢な防御です。
• だからこそ、ユーザーが指定したドメインを解決するツールでは、リンクローカルアドレスをプライベート範囲やループバック範囲と同じブロックリストに入れる必要があります。これは別枠の、軽いリスクではありません。

実務上の要点

ユーザーに代わってURLを解決しリクエストを送るシステムは、169.254.169.254 と、それが属する広いリンクローカル範囲を、厳格にアクセス禁止として扱う必要があります。その確認は、実際にリクエストを送る時点で毎回行います。アドレスがどのように得られたかは関係ありません。直接入力された場合でも、そのアドレスを指すDNSレコード経由で到達した場合でも同じです。

特定のクラウドプロバイダーに限った話ではない

169.254.169.254 は、AWS、Google Cloud、Azureに共通する慣習です。しかし、その背景にあるパターン、つまりインスタンスのIDや認証情報をインスタンス自身にだけ公開するリンクローカルアドレスは、主要なクラウドやコンテナプラットフォームのほぼすべてに、何らかの形で存在します。同じアドレスの場合もあれば、プロバイダー固有のアドレスの場合もあります。Kubernetesクラスターでも、Pod内から到達できるメタデータに近い内部エンドポイントが一般的に存在します。主要なクラウドプロバイダーについては具体的なアドレスを覚えておく価値がありますが、本当に応用が利くのは一般原則のほうです。ユーザー指定のURLを解決して取得するものにとって、メタデータ系のエンドポイントは、動作しているプラットフォームを問わずアクセス禁止として扱います。

IMDSv2：単なるフィルターではない、実効性のある緩和策

長年にわたってまさにこの攻撃パターンが悪用されてきたことを受けて、AWSは第2版のメタデータサービスであるIMDSv2を導入しました。IMDSv2では、メタデータを読み取る前に、特別なPUTリクエストでセッショントークンを取得する必要があります。重要なのは、脆弱なコードパスの大半が実際に発行する、SSRF経由の単純なGETリクエストではこのPUTリクエストを再現できない点です。

これは意味のある改善ですが、後方互換性のために多くのアカウントでは任意の選択にとどまっています。また、保護されるのはメタデータエンドポイントだけで、SSRFが到達しうるそのほかのプライベートアドレスや内部アドレスには何の効果もありません。どのバージョンのメタデータサービスを使っていても、解決されたアドレスをアプリケーション側でフィルタリングする対策は引き続き必要です。