The Discovery
During a bug bounty engagement, I was testing a webhook configuration feature that allowed users to specify callback URLs. The application would send test requests to verify the endpoint was reachable. This immediately caught my attention as a potential SSRF vector.
Initial Testing
I started by supplying the AWS metadata endpoint http://169.254.169.254/latest/meta-data/ as the webhook URL. The application made the request server-side and returned the response in the webhook test result. The IMDSv1 endpoint responded with the instance metadata, confirming the SSRF.
Escalation to Cloud Compromise
With access to the metadata service, I was able to retrieve IAM role credentials attached to the EC2 instance. These temporary credentials had overly permissive policies that allowed:
- Listing all S3 buckets in the account - Reading objects from sensitive data buckets - Describing EC2 instances and their security groups - Accessing AWS Secrets Manager secrets
Impact
This single SSRF vulnerability led to a complete cloud account compromise. The IAM role had far more permissions than necessary for the webhook functionality, violating the principle of least privilege.
Remediation
I recommended implementing IMDSv2 (requiring token-based requests), applying strict URL validation with an allowlist approach, and reducing the IAM role permissions to only what was necessary for the webhook feature.