BIPI
BIPI

SSRF to AWS IMDSv1 vs IMDSv2: Credential Theft and Mitigation

Cloud Security

How SSRF still steals AWS instance credentials in 2024, how IMDSv2 changes the math, and the bypasses that still work against half-migrated fleets.

By Arjun Raghavan, Security & Systems Lead, BIPI · December 10, 2024 · 9 min read

#aws#ssrf#imds#ec2#pentesting

The SSRF to instance metadata pivot was the technique behind the Capital One breach in 2019. AWS introduced IMDSv2 to kill it, then spent five years asking customers to actually enforce it. On engagements in 2024, we still find IMDSv1 enabled on more than half of EC2 fleets, often because some legacy agent broke on the migration and nobody fixed it.

IMDSv1 vs IMDSv2 in one paragraph

IMDSv1 is a simple HTTP GET to 169.254.169.254. Any SSRF that can issue an outbound HTTP request can reach it. IMDSv2 requires a PUT first to obtain a token, then a GET with that token in the header. Most SSRF primitives cannot perform PUTs, and most cannot set custom headers, which is the whole point.

Finding SSRF in cloud workloads

  • URL parameters in image fetchers, PDF renderers, and webhook ingestion endpoints
  • Server-side OAuth callback handlers that follow redirect chains
  • XML and SVG parsers that resolve external entities
  • GraphQL resolvers that accept arbitrary URLs in mutation payloads

Exploiting IMDSv1

Once you have a GET-based SSRF and IMDSv1 is enabled, the payload is one URL. Hit /latest/meta-data/iam/security-credentials/, read the role name, then hit /latest/meta-data/iam/security-credentials/role-name to pull AccessKeyId, SecretAccessKey, and Token. Export them and use them from your own box.

Bypasses against half-migrated IMDSv2 fleets

  1. Default hop limit of 1 still allows a compromised container on the host to reach IMDS
  2. Mixed mode IMDS, where IMDSv1 is permitted alongside IMDSv2, leaves the old path open
  3. PUT-capable SSRF in HTTP libraries that follow 307 and 308 redirects with method preservation
  4. DNS rebinding against the metadata IP in environments without explicit blocks

Detection signals

  • GuardDuty UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration fires when role creds are used outside the EC2 they belong to
  • VPC flow logs show outbound 169.254.169.254 traffic from unexpected processes
  • CloudTrail correlation of role session source IPs against the EC2's public IP
IMDSv2 is not a feature, it is a baseline. If your audit cannot prove every instance enforces it, your audit is wrong.

Remediation

  1. Set HttpTokens required at the account default level via EC2 instance metadata defaults
  2. Run an audit query against ec2 describe-instances and fail any HttpTokens optional finding
  3. Use SCPs to deny RunInstances and ModifyInstanceMetadataOptions with HttpTokens optional
  4. Rotate any role used by an instance that ever served traffic in IMDSv1 mode
55%
of EC2 instances in fleets we audited still allowed IMDSv1 in 2024
1 request
is all an SSRF needs against IMDSv1 to steal a role

Closing

There is no good reason to allow IMDSv1 in 2024. If a legacy agent breaks under IMDSv2, replace the agent. The cost of leaving v1 enabled is one SSRF away from a credential exfiltration headline.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.