cloud-imds-ssrflisted

# SSRF → cloud metadata → IAM credential theft ## When it applies You have SSRF and the app runs on a cloud VM/container with an attached role. The metadata endpoint hands out temporary credentials to anything that can reach it from the instance. ## Why it works IMDS lives at a link-local IP (`169.254.169.254`) and trusts *network position*, not identity. SSRF gives you that position, so the app fetches the instance's role credentials for you — then you use them against the cloud API with the app's permissions. ## Method 1. **AWS IMDSv1** (no token): SSRF to `http://169.254.169.254/latest/meta-data/iam/security-credentials/` → role name → `.../security-credentials/<role>` returns `AccessKeyId`, `SecretAccessKey`, `Token`. 2. **AWS IMDSv2** (token required): needs a PUT to get a token, then a header on the GET — possible only if the SSRF can set method + `X-aws-ec2-metadata-token` header. Many SSRFs can't; note IMDSv2 as the mitigation if it blocks you. 3. **GCP**: `http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token` with header `Metadata-Flavor: Google` (needs header-setting SSRF). 4. **Azure**: `http://169.254.169.254/metadata/identity/oauth2/token?...` with `Metadata: true`. 5. **Use the creds** (in scope only): configure the CLI with the temp key/secret/token and run read-only calls (`aws sts get-caller-identity`, `s3 ls`) to prove impact — don't touch data. ## Gotchas - IMDSv2/`Metadata` header requirements def