Exploiting SSRF: Cloud Metadata Service Attacks

Hello! Welcome to the next lesson in our module on advanced server-side vulnerabilities.

In our last session, we established how to use a Server-Side Request Forgery (SSRF) vulnerability to pivot inside a target's network, scanning for internal services. Today, we're going to dramatically escalate the impact of that same vulnerability. Many, if not most, modern applications are hosted in the cloud, and these environments have a special, highly sensitive internal service that can often be reached via SSRF.

Our goal is to upgrade a basic SSRF to a more impactful attack by targeting cloud metadata services, specifically the AWS Instance Metadata Service (IMDS). Successfully exploiting this service can turn a simple SSRF into a full infrastructure compromise by allowing you to steal the cloud credentials assigned to the server.

1. The Target: Cloud Instance Metadata Services

Cloud providers like AWS, Google Cloud, and Azure provide a special service accessible only from within a running instance (like a virtual server). This is called the Instance Metadata Service (IMDS). It provides information about the instance itself—its ID, network configuration, and, most critically, temporary security credentials.

Applications running on the instance use these credentials to interact with other cloud services (like S3 for storage or RDS for databases) without needing hardcoded keys. The service is typically accessed via a special, non-routable IP address. For AWS, this "magic IP" is 169.254.169.254.

Because this IP is only accessible from within the cloud environment, an SSRF vulnerability provides the perfect gateway for an external attacker to query it.

2. The Classic Heist: Exploiting IMDSv1

The original version of the AWS metadata service, IMDSv1, is straightforward to exploit. It responds to simple, unauthenticated HTTP GET requests. If you have an SSRF, you can point it directly at the metadata endpoints to retrieve information.

The following video provides an excellent walkthrough of this classic attack.

As shown in the video, the attack follows a clear, two-step process:

1. Discover the IAM Role Name: First, you request the available security roles to find out the name of the role attached to the instance.

   • Payload: http://169.254.169.254/latest/meta-data/iam/security-credentials/
   • The server will respond with the name of the role (e.g., ec2-admin-role).

2. Retrieve the Credentials: Once you have the role name, you append it to the path to request the actual credentials.

   • Payload: http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-admin-role
   • The server will respond with a JSON object containing the temporary AccessKeyId, SecretAccessKey, and Token.

While we focus on AWS here, other cloud providers have similar metadata services. The Server-Side Request Forgery (SSRF) Attack Guide provides a useful list of endpoints for various providers.

3. The Defense: IMDSv2 and Its Protections

The simplicity of IMDSv1 made it a prime target. A famous example is the 2019 Capital One data breach, where an SSRF vulnerability was exploited to steal credentials from the metadata service. In response, AWS introduced IMDSv2, which is designed specifically to mitigate SSRF attacks.

IMDSv2 introduces a session-oriented approach. To get any metadata, you must first obtain a session token and then use that token in all subsequent requests.

The IMDSv2 process is:

1. Request a Token: Send a PUT request to http://169.254.169.254/latest/api/token with a header specifying the token's lifetime (e.g., X-aws-ec2-metadata-token-ttl-seconds: 21600).
2. Use the Token: The response will be a session token. You must then include this token in an X-aws-ec2-metadata-token header for all subsequent GET requests to the metadata endpoints.

This defense works because most basic SSRF vulnerabilities only allow you to control the URL for a GET request. They don't typically allow you to change the HTTP method to PUT or add custom headers, making it impossible to complete the IMDSv2 authentication handshake.

4. Cracking the Vault: Bypassing IMDSv2

Bypassing IMDSv2 is more complex, but it is possible if the SSRF vulnerability is flexible enough. To defeat IMDSv2, your SSRF vulnerability must allow you to:

1. Control the HTTP method (to send a PUT request).
2. Control request headers (to set the token lifetime and later provide the token).

This is less common, but features like webhooks, API testers, or PDF generators sometimes provide this level of control. A real-world GitHub security advisory for a tool called typebot.io provides a perfect case study of exactly such a vulnerability.

This advisory perfectly illustrates the advanced attack chain. It's no longer a single GET request, but a sequence of carefully crafted requests that leverage the full capabilities of the SSRF vulnerability to interact with the session-based IMDSv2 protocol.

Also, note the use of http://2852039166/. This is the decimal representation of 169.254.169.254. This is a common technique to bypass simple string-based filters that might be looking for "169.254" or "localhost". Your CS background gives you a great foundation for understanding and using these kinds of encoding and representation tricks.

5. Post-Exploitation: Using the Stolen Keys

Obtaining the credentials (AccessKeyId, SecretAccessKey, Token) is the "checkmate" moment. You now have the authority to act as the compromised server. You can configure the AWS Command Line Interface (CLI) on your own machine to use these temporary credentials and begin exploring the target's cloud environment.

Once configured, you can run commands like:

• aws s3 ls: List all S3 buckets.
• aws ec2 describe-instances: Get information about all EC2 instances.
• aws iam list-users: List IAM users in the account.

The extent of your access depends on the permissions granted to the IAM role you compromised. In a misconfigured environment, this can lead to a complete takeover.

Test your understanding!

You've found an SSRF vulnerability in a web application's image proxy feature: https://example.com/proxy?url=[USER_INPUT]. You suspect it's running on AWS. You try the payload http://169.254.169.254/latest/meta-data/ and the request times out. You then try http://169.254.169.254/ and get a 404 Not Found response.

What do these responses suggest about the IMDS version in use, and what would your immediate next step be, assuming the SSRF is a simple GET request with no header control?

Show answer

The timeout for a specific path but a 404 for the root suggests that the host 169.254.169.254 is reachable, but the endpoint /latest/meta-data/ requires something more. This behavior is characteristic of an instance configured to enforce IMDSv2. A simple GET request to a metadata path will fail without a valid token. The 404 on the root is also expected as there's no service there.

Given that you only have control over the URL in a GET request, your immediate next step would be to conclude that you likely cannot exploit the metadata service with this specific, limited SSRF vulnerability. You would then pivot your efforts to other internal targets (e.g., localhost, other private IPs) as we discussed in the previous lesson. Bypassing IMDSv2 requires more control than this SSRF provides.

Conclusion

You have now learned one of the most critical escalation paths in modern penetration testing and bug bounty hunting. What starts as a simple SSRF can become a "keys to the kingdom" vulnerability when targeting cloud environments.

Key Takeaways:

• Cloud metadata services are a high-value target for SSRF. The AWS IMDS, accessible at 169.254.169.254, can expose temporary credentials.
• IMDSv1 is trivial to exploit with a basic SSRF, requiring only a GET request to the correct endpoints.
• IMDSv2 is a hardened, session-based protocol designed to mitigate SSRF. It requires a PUT request to get a token, which must be passed in a header for subsequent requests.
• Bypassing IMDSv2 is possible but requires a more powerful SSRF vulnerability—one that allows you to control the HTTP method and request headers.
• Stolen cloud credentials can be used with tools like the AWS CLI to perform post-exploitation reconnaissance and further attacks on the cloud environment.

Next Lesson Preview:

As you've seen, SSRF payloads often contain specific IP addresses or keywords that security systems might try to block. Our next lesson will introduce the first line of defense you'll often encounter when launching these attacks: the Web Application Firewall (WAF). We will learn how to identify the presence of a WAF through response analysis and begin to understand how they work, setting the stage for learning how to bypass them.