flawopen.com/SSRF/クラウドメタデータとSSRF
SSRFはどのようにクラウドメタデータへ到達し、認証情報はいつ危険にさらされますか？
メタデータサービスを、クラウドマシン内にある施錠された窓口だと考えてください。SSRFはアプリをその窓口へ向かう使者にできますが、取得できる情報はプロバイダーのリクエスト規則、インスタンス設定、アプリのネットワーク経路で変わります。エンドポイントへ到達できるだけで認証情報が漏れるわけではありません。
メタデータエンドポイントが危険になり得る理由
AWS EC2、Azure、Google Compute Engineは、対応するVM環境から利用できるインスタンスメタデータサービスを文書化しています。169.254.169.254は一般的なリンクローカルアドレスですが、要求形式と制御は異なります。メタデータには機密性の高い情報が含まれることがあり、インスタンスプロファイルと要求経路が許せばAWSはロールの一時認証情報を返します。攻撃者がこのサービスへ届くサーバー側リクエストを操作できるとSSRFが問題になります。到達可能というだけでは認証情報を取得できる証拠になりません。必須ヘッダーやトークン、HTTPメソッド、プロキシ、ネットワーク位置、インスタンス設定が結果を左右します。
影響の連鎖が成立する条件
影響には複数の条件が必要です。入力がサーバー側リクエストに影響し、そのリクエストがメタデータサービスへ到達し、プロバイダーの制御下で受け入れられ、返された情報が有効な権限を与える必要があります。最終的な範囲はワークロードIDの権限によって決まります。固定宛先、厳格な送信制御、メタデータ保護、最小権限のIDで連鎖を断ちます。
よくある質問
いいえ。アドレス、ヘッダー、メソッド、トークン要件、取得できるデータは異なります。AWSではHttpTokensがrequiredの場合、IMDSv2のメタデータ取得にセッショントークンが必要です。AzureはMetadata: trueヘッダーを要求し、GoogleはMetadata-Flavor: Googleヘッダーを文書化しています。これらは一部のSSRF経路を抑制しますが、利用者が宛先を指定できない設計や不要な送信通信の遮断に代わるものではありません。VMとコンテナーの実設定を公式文書で確認してください。