SSRF and Cloud Metadata Services

Every major cloud provider exposes a metadata service: an HTTP endpoint reachable from any process running on a compute instance, returning instance identity, configuration, and temporary IAM credentials. The endpoint is on a link-local address, routable only from the instance itself. It requires no authentication by default. SSRF turns an application vulnerability into access to these credentials.

AWS Instance Metadata Service

AWS IMDS is available at 169.254.169.254. IMDSv1 responds to any HTTP GET without authentication. The path structure is documented: temporary credentials for the instance's IAM role are at:

http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

The response contains an AccessKeyId, SecretAccessKey, and Token. These are short-lived credentials for the IAM role attached to the instance. With SSRF against an application on that instance, an attacker retrieves these credentials and can make AWS API calls with the permissions of that role from any machine.

IMDSv2 was introduced in 2019 as a required-authentication variant. It uses a session-oriented approach: the client must first send a PUT request with a X-aws-ec2-metadata-token-ttl-seconds header to receive a session token, then present that token in subsequent GET requests. The PUT method requirement is the key control: most SSRF exploits use GET-only HTTP clients. An SSRF through a webhook or URL fetch that does not support PUT cannot complete the IMDSv2 handshake.

IMDSv2 is not retroactively enforced. Instances where HttpTokens is set to optional respond to both v1 and v2 requests. Enforcement requires setting HttpTokens: required at the instance or account level.

GCP Metadata Service

GCP's metadata server is at 169.254.169.254 or metadata.google.internal. It requires a custom HTTP header: Metadata-Flavor: Google. Requests without this header receive a 403 response. This provides protection against naive SSRF that does not control request headers, but SSRF through server-side HTTP clients that allow custom headers bypasses this.

Service account tokens are available at:

http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token

Azure Instance Metadata Service

Azure IMDS is at 169.254.169.254 and requires the header Metadata: true and a specific API version query parameter. Managed identity tokens for accessing Azure resources are returned at the identity endpoint. The same header requirement applies as GCP.

What Credential Access Enables

Temporary cloud credentials obtained through SSRF grant whatever permissions the instance's IAM role has. Over-privileged roles, a common misconfiguration, translate directly into over-privileged SSRF impact. An EC2 instance with an IAM role that has s3:GetObject on all buckets allows the attacker to read every object in S3. A role with EC2 or IAM permissions allows lateral movement and privilege escalation within the cloud account.

The credential retrieval itself is the detection point: CloudTrail logs the API calls made with the temporary credentials. Calls from an unusual source IP, at an unusual time, for resources the application does not normally access, are indicators.