AWS Metadata Hack exploits a Server-Side Request Forgery (SSRF) vulnerability to trick an EC2 instance into revealing temporary IAM credentials via the local metadata service at 169.254.169.254. This allows attackers to assume the instance's identity, potentially accessing sensitive data and moving laterally within the AWS environment. For more information, visit Hacking The Cloud.
Reconnaissance & Discovery
The application features a "Content Fetcher" service designed to retrieve images or text from external URLs. While testing the url parameter, I noticed the server was performing outbound requests without strict validation of the destination.
Instead of pointing it at a legitimate image, I tested if I could force the server to talk to its own internal interface.
The Exploitation Path
In cloud environments (AWS, GCP, Azure), there is a metadata service reachable at a non-routable IP address: 169.254.169.254. This service contains sensitive information about the instance, including IAM Role Credentials.
The Initial Probe: I submitted a request to the Metadata endpoint: [http://169.254.169.254/latest/meta-data/](http://169.254.169.254/latest/meta-data/)
The "Aha!" Moment: The server responded with a directory listing of internal metadata. This confirmed that the application was vulnerable to Blind SSRF, allowing me to pivot into the internal network.
3. Extracting the Flag (The Payload)
Takeaways : Utilizing tools like Active scanner can be very useful and be used in your workflow. (Thanks to the team behind active scan !)
Links:
Access instance metadata for an EC2 instance
Join My Slack Server to Collab & learn bug bounty together!