SSRF to AWS Metadata Exposure: How Attackers Steal Cloud Credentials
Vulnerability Assessment and Penetration Testing
Description
In modern cloud environments, misconfigurations and insecure coding practices can open dangerous doors to attackers. One critical example is Server-Side Request Forgery (SSRF), a vulnerability that allows attackers to manipulate a server into making unintended requests. When SSRF is exploited against cloud infrastructure like AWS, it can lead to the exposure of sensitive instance metadata, including temporary IAM credentials.
This blog post explores how SSRF vulnerabilities in EC2-hosted applications can be leveraged to access the AWS Instance Metadata Service (IMDS), and how that can lead to the compromise of cloud resources. We’ll walk through the attack surface, demonstrate exploitation, and discuss how to defend your AWS environment against these threats.
Why This Attack Happens
The exploitation of SSRF to access AWS metadata is caused by a combination of insecure application logic and cloud infrastructure assumptions. Here's why this attack is possible:
1. Trusting Unvalidated User Input
Many web applications allow users to supply URLs that the server later uses to fetch data (e.g., fetching images, webhooks, or external APIs). When this input isn’t strictly validated, attackers can manipulate it to send requests to arbitrary internal addresses.
Example: GET /proxy?url=http://evil.com
SSRF payload: GET /proxy?url=http://169.254.169.254/latest/meta-data/
2. Unrestricted Access to the Metadata Service
The AWS Instance Metadata Service (169.254.169.254) is designed to be accessed only from within the EC2 instance. However, if a vulnerable application running on the instance sends a request there (even unintentionally), it will succeed — no credentials or tokens are required by default unless IMDSv2 is enforced.
3. Over-Privileged IAM Roles
If the EC2 instance has an IAM role with broad permissions (e.g., full access to S3, DynamoDB, or EC2), the stolen temporary credentials can be used to perform powerful actions across your AWS account.
4. Missing Network-Level Protections
By default, EC2 instances can access the metadata service without restrictions. Without additional network rules or metadata access filters, any process on the instance — including vulnerable apps — can reach it.
Understanding the Attack Surface
1. EC2 Metadata Service (IMDS)
The EC2 Instance Metadata Service is available at the internal, link-local IP address http://169.254.169.254. It provides information about the instance, such as:
- Instance ID, AMI, hostname
- Attached security groups
- Temporary IAM role credentials (if an IAM role is assigned)
While designed to be accessed only from within the EC2 instance, SSRF can provide an indirect path for attackers to reach it.
2. Public-Facing Applications
Many EC2 instances host web applications that accept user input—via forms, query parameters, headers, or APIs—and use that input to fetch remote resources. Without proper input validation, these applications may become vulnerable to SSRF, where an attacker forces the server to fetch arbitrary URLs, including internal ones.
3. IAM Role Credentials
If an EC2 instance is assigned an IAM role, temporary credentials are available through the metadata service at
http://169.254.169.254/latest/meta-data/
These credentials can be used to access AWS services (like S3, DynamoDB, etc.) based on the permissions defined in the role’s policy. If an attacker retrieves these credentials via SSRF, they can assume the instance’s identity and access AWS resources on behalf of the compromised instance.
Accessing AWS Metadata Service
-
Target the Metadata Endpoint
Direct the SSRF vulnerability to the EC2 metadata service at 169.254.169.254
Endpoint: http://169.254.169.254/
-
Discover Instance ID Query the metadata path to obtain the instance ID or use service data
Endpoint: http://169.254.169.254/latest/meta-data/
-
Extract IAM Role Name Navigate the metadata structure to find the assigned IAM role name for the instance
Endpoint : http://169.254.169.254/latest/meta-data/
-
Retrieve AWS Credentials Access the security credentials endpoint to obtain AccessKeyId, SecretAccessKey, and SessionToken
Endpoint : http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-instance
The AWS metadata service exposes a hierarchical structure of information. By methodically traversing this structure through our SSRF vulnerability, we were able to extract increasingly sensitive information, culminating in the temporary AWS credentials assigned to the instance's IAM role.
Credential Extraction Technique
When an attacker successfully exploits SSRF to access the EC2 instance metadata service, they can retrieve temporary security credentials assigned to the instance's IAM role. These credentials are designed for legitimate workloads to interact with AWS services securely, but in the wrong hands, they become a powerful weapon.
The response from the metadata service includes all the elements required to make authenticated AWS API calls:
- Access Key ID
A publicly visible identifier used to reference the credentials in API requests. - Secret Access Key
A sensitive value used to cryptographically sign AWS requests. This key must be kept confidential—anyone with access can act on behalf of the role. - Session Token
An additional piece of authentication that proves the credentials are part of a temporary session. It’s required for using the Access Key and Secret with most AWS services. - Expiration
A timestamp indicating when the credentials will become invalid. While short-lived (usually a few hours), this window is often long enough for attackers to access resources, download data, or even escalate access.
Impact of SSRF Vulnerabilities
Server-Side Request Forgery (SSRF) may appear harmless at first—just making server-side HTTP requests—but in cloud environments like AWS, its impact can be severe and far-reaching:
1. Cloud Credential Theft
Attackers can exploit SSRF to access the EC2 Instance Metadata Service at 169.254.169.254, retrieving temporary IAM credentials. This allows them to impersonate the instance and interact with AWS services (e.g., download S3 data, list EC2 instances).
2. Internal Network Scanning
SSRF can be used to probe internal services or cloud components not exposed to the public, such as:
- Internal admin panels
- Redis, Elasticsearch, etc.
- Kubernetes metadata endpoints
This can aid in lateral movement or privilege escalation.
3. Access to Internal APIs and Services
Many organizations run internal-only APIs that trust internal traffic. SSRF can bypass that trust boundary, allowing attackers to:
- Perform unauthorized actions
- Access sensitive data
- Exploit other internal services
4. Bypassing Firewalls and Network Restrictions
Since SSRF originates from within the server, it can reach endpoints protected by perimeter firewalls. This effectively turns the vulnerable application into a proxy, allowing the attacker to:
- Bypass IP whitelists
- Reach otherwise unreachable internal assets
5. Pivoting and Further Exploitation
In advanced attacks, SSRF can be used to pivot deeper into the infrastructure:
- Steal tokens from cloud metadata endpoints (AWS, GCP, Azure)
- Reach databases or config services
- Escalate from a simple web app bug to full cloud compromise
Mitigation Strategies
1. Enable IMDSv2
Use Instance Metadata Service Version 2 (IMDSv2), which requires a session-based token for metadata access. This prevents simple SSRF attacks from succeeding by adding a layer of authentication between the instance and the metadata service.
2. Enforce Strict URL Validation
Sanitize and validate all user-supplied URLs before the application makes outbound requests. Use a whitelist of allowed domains instead of trying to blacklist dangerous patterns. Never allow direct access to IPs or internal resources.
3. Restrict Network Access
Use security groups and network ACLs to block EC2 instances (or containers within them) from accessing 169.254.169.254 unless explicitly required. For apps that must make HTTP requests, route them through a proxy with a strict allowlist and no access to metadata.
4. Apply Least Privilege to IAM Roles
Assign the minimum required permissions to EC2 IAM roles. Even if credentials are exposed via SSRF, limiting privileges reduces the attacker's ability to escalate. Regularly audit IAM roles and policies for unnecessary permissions.
Resecurity recommends that businesses perform an in-depth assessment according to OWASP Web Application Security Testing (WSTG), which includes the following phases:
4.1 Information Gathering
4.2 Configuration and Deployment Management Testing
4.3 Identity Management Testing
4.4 Authentication Testing
4.5 Authorization Testing
4.6 Session Management Testing
4.7 Input Validation Testing
4.8 Testing for Error Handling
4.9 Testing for Weak Cryptography
4.10 Business Logic Testing
4.11 Client-side Testing
4.12 API Testing
Our experts hold the following industry
certifications and have an extensive track record of successful work
with the leading Fortune 500 companies and government agencies:
- CISSP (Certified Information Systems Security Professional)
- CEH (Certified Ethical Hacker)
- CISA (Certified Information Systems Auditor)
- GIAC GCIH (Certified Incident Handler)
- Offensive Security Certified Professional (OSCP)
- GIAC Web Application Penetration Tester (GWAPT)
- eLearnSecurity Certified Penetration Tester eXtreme (eCPTX)
- eLearnSecurity Web Application Penetration Tester Extreme (eWPTXv2)
- eLearnSecurity Certified Professional Penetration Tester (eCPPTv2)
- Attify Certified IoT Security Pentester (ACIP)
- eLearnSecurity Mobile Application Penetration Tester (eMAPT)
- Certified Red Team Professional (CRTP)
- CREST Registered Penetration Tester (CRT)
- CREST Practitioner Security Analyst (CPSA)
Please don't hesitate to contact us anytime at contact@resecurity.com. Our specialists will be happy to assist you with web application security, mobile app testing, and API testing. For more information about VAPT (Vulnerability Assessment and Penetration Testing) services by Resecurity, you may review the following page.
