Cloud security is often described as a chain—the strength of the entire system is determined by its weakest link. In this laboratory exercise, I investigated a critical vulnerability chain where a simple web application flaw escalated into full administrative control of cloud resources.
Executive Summary
This investigation confirms a critical vulnerability chain in a cloud-hosted web application. An attacker was able to exploit a Server-Side Request Forgery (SSRF) vulnerability to access the Instance Metadata Service (IMDSv1). This access led to the theft of temporary IAM credentials, lateral movement through S3 buckets, and eventual full compromise of a restricted Lambda function.
The blast radius extended from a single web application to the entire administrative control of specific Lambda resources, highlighting the dangers of IMDSv1 and overprivileged instance profiles.
The Attack Narrative: Step-by-Step Breakdown
The attack followed a linear progression, exploiting misconfigurations at each layer of the stack to escalate privileges.
Credential Discovery via Lambda
The attack began with the solus user credentials. Through enumeration of Lambda functions, environment variables were discovered containing hardcoded credentials for a second user, wrex.
Finding: Sensitive credentials (Access Keys) were stored in Lambda environment variables.
Security Group Modification
Upon identifying the target EC2 instance (IP: 100.27.209.41), initial connection attempts failed. Using the wrex credentials, the ingress rules were modified to allow traffic on Port 80 from 0.0.0.0/0.
Analyst Note: This highlights the danger of "Security Group Management" permissions; an attacker can open their own doors if the IAM policy is too broad.
Exploiting the URL Parameter
The web application was found to have a /?url= parameter. By bypassing filters, the analyst confirmed that the server would fetch and display content from internal addresses.
Exploitation Target: http://169.254.169.254/latest/meta-data/iam/security-credentials/cg-ec2-role-cgid... Vulnerability: IMDSv1 (No session token required)
Credential Theft & S3 Pivot
Using the stolen EC2 Role credentials, the analyst enumerated S3 buckets. A bucket named cg-secret-s3-bucket-cgid... was identified, containing a file named credentials.
Credential Pivot: This file contained the long-term credentials for the shepard user.
Lambda Compromise
The shepard user possessed the exclusive lambda:InvokeFunction permission. By invoking the "win" Lambda function, the analyst proved full control over the application's critical logic.
Technical Analysis of the Blast Radius
The "Blast Radius" in this scenario was significantly widened by three core failures in the security architecture.
⚠️ IMDSv1 Availability
If IMDSv2 had been enforced, the SSRF would have been neutralized. IMDSv2 requires a PUT request to generate a session token.
⚠️ Overprivileged Role
The EC2 instance had a role attached that allowed it to read sensitive files from S3 unrelated to its web-serving function.
⚠️ Secrets Management
Storing the shepard user credentials in a plaintext file on S3 created a "stepping stone" for the attacker.
Root Cause Analysis (RCA)
Each phase of the attack corresponds to a specific configuration failure. Addressing these root causes is essential for preventing similar chains.
Root Cause: Lack of input validation/allow-listing on the url parameter.
Root Cause: Use of IMDSv1, which lacks the session-oriented protection of IMDSv2.
Root Cause: Overprivileged IAM Role (the EC2 Role could access S3 secrets).
Root Cause: Storing administrative credentials (shepard) in a storage bucket.
Recommended Hardening & Mitigation
To break this vulnerability chain, controls must be implemented at multiple layers of the architecture.
- • Implement a "Strict Allow-list" for the
urlparameter. - • Only allow specific, pre-approved domains.
- • Block all requests to
169.254.169.254andlocalhost.
- • Disable IMDSv1 globally or on a per-instance basis.
- • Set
HttpTokens=requiredandHttpPutResponseHopLimit=1. - • This prevents the metadata service from responding to SSRF requests that cannot provide a fresh session token.
# AWS CLI Command to Enforce IMDSv2
aws ec2 modify-instance-metadata-options \
--instance-id i-1234567890abcdef0 \
--http-tokens required \
--http-endpoint enabled
- • Audit the EC2 Instance Profile.
- • Remove
s3:ListBucketands3:GetObjectpermissions from the EC2 role unless specifically required.
- • CloudTrail: Monitor for
GetCredentialsForEC2events where the sourceIPAddress is the instance's own private IP. - • AWS Config: Create a rule to alert if any Security Group is modified to allow
0.0.0.0/0on sensitive ports.
Reflection: The Chain of Security
This lab demonstrates that cloud security is a "chain." The SSRF was the entry point, but the IMDSv1 configuration was the catalyst that allowed the attacker to escape the web server and enter the IAM control plane.
Key Takeaway: Transitioning to IMDSv2 is the single most effective preventative control to stop metadata theft, even when an application-level SSRF exists. It adds a critical layer of defense that breaks the exploit chain at the host level.
📚 Educational Context
This security analysis was completed as part of ENPM665: Cloud Security at the University of Maryland. The scenario was created for educational purposes to develop practical skills in vulnerability chaining, EC2 security hardening, and IAM privilege analysis.