Server-Side Request Forgery (SSRF): Cloud Metadata Exploitation

Server-Side Request Forgery (SSRF) has evolved from a niche vulnerability to one of the most devastating attack vectors in modern cloud-native applications. Ranked prominently in the OWASP Top 10, SSRF occurs when an application fetches a remote resource without validating the user-supplied URL. An attacker can force the vulnerable server to make HTTP requests to its internal network or the cloud infrastructure it resides on.

In this deep-dive technical article, Cayvora Security investigates how SSRF is weaponized to exploit Cloud Instance Metadata Services (IMDS), bypass internal firewalls, and extract highly sensitive IAM credentials.

Mechanics of SSRF

Modern web applications frequently ingest URLs to fetch profile pictures, import data, or interact with webhooks. If the application server naively trusts the provided URL:

# Vulnerable Python Flask Endpoint
@app.route('/fetch_image')
def fetch_image():
    url = request.args.get('url')
    # No validation! The server naively makes a request to the provided URL.
    response = requests.get(url) 
    return response.content

If an attacker supplies http://localhost:6379/ (the default port for Redis), the web server will make a request to its own internal Redis database, completely bypassing external firewalls.

Cloud Metadata Exploitation (IMDS)

The most catastrophic consequence of SSRF in cloud environments (AWS, Azure, GCP) is the exploitation of the Instance Metadata Service (IMDS).

IMDS provides EC2 instances with information about themselves, including dynamic temporary credentials for the IAM role attached to the instance. The service is accessible via a fixed, non-routable IP address: 169.254.169.254.

AWS IMDSv1 Exploitation

If the application is running on AWS and uses IMDSv1, an attacker can extract credentials with a simple SSRF.

1. Finding the Role Name: The attacker submits the following URL to the vulnerable SSRF endpoint: http://169.254.169.254/latest/meta-data/iam/security-credentials/

The server responds with the name of the IAM role: S3-Admin-Role

2. Extracting the Credentials: The attacker appends the role name to the URL: http://169.254.169.254/latest/meta-data/iam/security-credentials/S3-Admin-Role

The vulnerable server fetches the metadata and returns the highly sensitive JSON response:

{
  "Code" : "Success",
  "LastUpdated" : "2025-03-10T14:00:00Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
  "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
  "Token" : "IQoJb3JpZ2luX2VjEJv...[TRUNCATED]...",
  "Expiration" : "2025-03-10T20:00:00Z"
}

The attacker now imports these credentials into their local AWS CLI and assumes the identity of S3-Admin-Role, allowing them to read/write S3 buckets, launch new instances, or delete infrastructure depending on the role's IAM policies.

Bypassing SSRF Filters

Developers often attempt to block 169.254.169.254 or localhost. Attackers bypass these blocklists using:

1. Alternative IP Encodings:
2. Decimal: http://2852039166/
3. Hexadecimal: http://0xA9FEA9FE/

4. Octal: http://0251.0376.0251.0376/

5. DNS Rebinding: The attacker registers a domain attacker.com. The first DNS lookup (done by the server's validation logic) resolves to a legitimate IP (e.g., 8.8.8.8). However, the DNS record has a TTL of 0. When the application library makes the actual HTTP request a millisecond later, the DNS resolves to 169.254.169.254.

6. Open Redirects: If the application follows redirects, the attacker can point the SSRF to an external URL they control, which responds with an HTTP 302 Redirect to http://169.254.169.254/.

Prevention and Hardening

1. Enforce IMDSv2 (AWS)

AWS introduced IMDSv2 to mitigate SSRF. It requires a specific custom HTTP header (X-aws-ec2-metadata-token) and relies on a session-based PUT request to obtain a token before querying metadata. Because a standard SSRF vulnerability rarely allows an attacker to control the HTTP method and inject custom headers simultaneously, IMDSv2 effectively neutralizes the threat.

Remediation: Enforce IMDSv2 on all EC2 instances via the AWS CLI:

aws ec2 modify-instance-metadata-options     --instance-id i-1234567890abcdef0     --http-tokens required     --http-endpoint enabled

2. Strict URL Validation

Never rely on blocklists. Implement a rigorous allowlist of acceptable domains. If fetching from arbitrary domains is a business requirement, use internal DNS resolution logic to ensure the resolved IP address does not fall within private IPv4 ranges (RFC 1918) or the link-local range (169.254.0.0/16).

3. Network Segmentation

Isolate applications that make outbound web requests into isolated VPC subnets without routing access to internal sensitive databases or APIs.

Conclusion

SSRF represents a catastrophic bridge between external application interfaces and deeply internal cloud metadata. By migrating strictly to IMDSv2 and carefully validating all outbound network requests, organizations can sever this attack vector. Ensure you also review our guide on XML External Entity (XXE) Injection, which frequently results in SSRF.