Cloud Metadata Service Abuse: SSRF to Credentials

Cloud metadata service abuse turns a server-side request forgery (SSRF) vulnerability into full cloud account compromise by tricking a vulnerable server into fetching credentials from the cloud provider’s internal metadata endpoint (e.g., http://169.254.169.254/). An attacker who can make the server issue arbitrary HTTP requests can retrieve temporary access keys, tokens, or user-data secrets, then use them to access cloud resources outside the server. This article explains how the attack works, why it succeeds in modern web stacks, and how to defend against it.

Background: What Is the Cloud Metadata Service?

Every major cloud provider (AWS, Azure, GCP, Alibaba Cloud, etc.) runs a special HTTP service inside each virtual machine or container. It is reachable only from within the instance at a link-local IP address, most famously 169.254.169.254 (AWS and GCP) or 169.254.169.254 with a different header requirement on Azure. The service exposes instance metadata: hostname, network configuration, user-data scripts, and—critically—temporary credentials for the instance’s IAM role.

These credentials are short-lived (usually 1–6 hours) and are automatically rotated by the provider. The metadata service is not authenticated by a password; it trusts that any process running on the instance is allowed to read them. That trust model is the root of the abuse.

How SSRF Leads to Credential Theft

Server-Side Request Forgery (SSRF) is a vulnerability where an attacker can make the web application server send HTTP requests to arbitrary URLs. Typical entry points include:

• URL parameters that are fetched server-side (e.g., ?url= for image proxies or webhooks)
• XML parsers that support external entity resolution (XXE)
• PDF generators that fetch remote images or stylesheets
• Import features that download files from user-supplied links

When the server fetches http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS), it returns the role name. A second request to /latest/meta-data/iam/security-credentials/<role-name> returns a JSON document containing AccessKeyId, SecretAccessKey, and Token. The attacker now has valid credentials for the instance’s IAM role. On Azure, the endpoint is http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/ and requires the header Metadata: true. On GCP, the endpoint is http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token and requires the header Metadata-Flavor: Google.

Once the attacker has the credentials, they can use the cloud provider’s API to read databases, download object storage, create new instances, or pivot deeper into the network—all while appearing as the legitimate service.

Why Modern Web Stacks Are Especially Vulnerable

Modern web applications often run in containerized environments or serverless functions that rely heavily on IAM roles rather than static API keys. This is good security practice, but it means the metadata service is the only place where credentials live. If an SSRF exists, the attacker gets credentials directly—no need to crack passwords or find hardcoded secrets.

Additionally, modern frameworks often have features that make SSRF easier to trigger:

• GraphQL resolvers that fetch remote data
• Webhook integrations that let users specify a callback URL
• Server-side rendering that fetches user-supplied URLs
• Document converters (HTML to PDF, DOCX to PDF) that fetch external resources

Even with input validation, attackers can bypass filters using redirects, DNS rebinding, or IPv6 representations of the metadata IP (e.g., http://[::ffff:169.254.169.254]/).

Real-World Impact and Examples

This attack has been used in major breaches. In 2019, Capital One suffered a data breach affecting 100 million customers. The attacker exploited an SSRF in a web application firewall configuration to access the metadata service and retrieve temporary credentials for an IAM role that had overly broad permissions, allowing them to download S3 buckets. The role had permissions to list and read all S3 objects, which was far beyond what the application needed.

Another example is the 2017 Uber breach, where an attacker found hardcoded AWS credentials in a public GitHub repository. While not strictly SSRF, it shows how cloud credentials are the ultimate prize. In 2021, a researcher demonstrated SSRF in a popular PDF generator that allowed reading the metadata service of the hosting server, exposing credentials for the entire account.

Mitigation: How to Prevent Metadata Abuse

Preventing this attack requires a defense-in-depth approach:

1. Eliminate SSRF vulnerabilities: Validate and sanitize all URLs, block private IP ranges, and use allowlists for domains. Do not follow redirects blindly.
2. Restrict metadata service access: Use network policies (e.g., AWS Security Groups, Kubernetes NetworkPolicies) to block access to 169.254.169.254 from application pods, except for the instance itself.
3. Use IMDSv2 (AWS): AWS’s Instance Metadata Service Version 2 requires a PUT request to get a session token, which adds a layer of protection against simple SSRF because the attacker would need to make two requests and capture the token.
4. Least privilege IAM roles: Grant the instance role only the permissions it absolutely needs. If an attacker gets the credentials, the blast radius is limited.
5. Use service-specific credentials: For example, use AWS Secrets Manager or Azure Key Vault with short-lived credentials that are not stored on the instance.
6. Monitor and alert: Look for unusual API calls, especially from the metadata IP, and set up alerts for IAM role usage.

Common Misconceptions and Pitfalls

One common misconception is that the metadata service is only accessible from the instance itself, so it is safe. In reality, any process on the instance can access it, and SSRF makes the web server a proxy for the attacker. Another misconception is that blocking the IP address in the application’s outbound firewall is enough—but the SSRF might use a different network namespace or bypass the filter via redirects.

Another pitfall is relying on the Metadata: true header (Azure) as a security measure. While it blocks simple SSRF, an attacker can often add the header if the SSRF allows arbitrary headers. Similarly, GCP’s Metadata-Flavor: Google header can be spoofed if the SSRF lets you set headers.

Also, note that the metadata service is not just for credentials—it can expose user-data scripts that may contain secrets, and on some providers, it can be used to retrieve SSH public keys or other instance info.

Comparison: AWS IMDSv2 vs. Other Providers

AWS introduced IMDSv2 in 2019 to mitigate SSRF. It requires a PUT request to /latest/api/token with a header X-aws-ec2-metadata-token-ttl-seconds, which returns a token that must be included in subsequent requests. This prevents simple GET-based SSRF because the attacker would need to make a PUT request first, which many SSRF filters block. However, IMDSv2 is not a silver bullet—if the SSRF can perform PUT requests (e.g., via a webhook that supports custom methods), it can still be bypassed.

Azure and GCP do not have a similar token system; they rely on headers. Azure requires Metadata: true, and GCP requires Metadata-Flavor: Google. These headers are easy to add in many SSRF contexts, so they are weaker defenses.

Some providers, like DigitalOcean, allow you to disable the metadata service entirely. If your application does not need it, turn it off.

Alternatives to Metadata for Credentials

If you want to avoid the risk entirely, you can use a secrets management service that does not rely on the metadata endpoint:

• AWS Secrets Manager / Parameter Store: Store secrets encrypted, and have the application retrieve them using the instance role (which still uses metadata, but the secrets are not directly exposed via SSRF).
• HashiCorp Vault: Use Vault’s AWS auth method to get short-lived credentials, but this still requires the instance role to authenticate to Vault.
• Kubernetes Service Accounts: In EKS, GKE, or AKS, you can use workload identity to map a Kubernetes service account to an IAM role, and the credentials are injected as a projected volume (short-lived JWT), not via the metadata service.
• Environment variables: For non-production, you can pass secrets via environment variables, but this is not recommended for production due to management overhead.

These alternatives do not eliminate the need for some initial credential, but they reduce the attack surface by not exposing credentials through a simple HTTP GET.

Frequently Asked Questions

Can I block the metadata service with a firewall?

Yes, you can use host-based firewalls or network policies to block outbound traffic to 169.254.169.254 from application processes. However, be careful: the instance itself still needs access for other purposes (e.g., AWS Systems Manager). You can restrict it to only the root user or a specific process.

Does IMDSv2 completely fix the SSRF issue?

No. IMDSv2 adds a token requirement, but if the SSRF allows PUT requests or can set arbitrary headers, an attacker can still obtain the token. It is a strong mitigation but not a complete fix. Always combine it with network restrictions and least privilege.

What is the difference between user-data and instance metadata?

User-data is a script or configuration you provide when launching the instance. It is accessible at /latest/user-data and may contain secrets. Instance metadata includes network info, instance ID, and IAM role info. Both are accessible via the same endpoint and can be exposed by SSRF.

How can I detect if my metadata service has been abused?

Look for API calls from the instance that do not match normal behavior. Cloud providers offer audit logs (CloudTrail, Activity Logs, etc.). You can also set up alerts for when an IAM role is used from an unexpected IP or at unusual times.

Is this attack only possible on public cloud?

No. Private clouds or on-premises virtualization platforms (like OpenStack) also have metadata services. If your web app has SSRF and runs on such a platform, the same attack applies.

Can serverless functions (AWS Lambda) be affected?

Yes. Lambda functions have a metadata service at the same IP. If your Lambda function has an SSRF, an attacker can retrieve the execution role’s credentials. The mitigation is to use least privilege roles and avoid SSRF.

Related

• Compare Cloud Provider Climate Impact
• LG Phone Bumpers: How to Verify Your Model
• Samsung SM-T350 Firmware: How to Flash & Update