Skip to main content

SSRF leading to AWS keys leakage - Bug Bounty Writeup

This is a short article describing a critical vulnerability I recently found in one of India’s top travel booking website.

Quick info:
💡
SSRF allows an attacker to induce the server-side application to make requests to an unintended location. 
💡It is common when testing for SSRF vulnerabilities to observe a DNS look-up for the supplied attacker-controlled domain, but no subsequent HTTP request. Many production networks allow free egress of DNS queries, because they are essential for the normal operation of production systems. The application attempts to make an HTTP request to the domain, which causes the initial DNS lookup, but the actual HTTP request is blocked by network-level filtering.
💡Access Keys allow programmatic calls to AWS or to use the AWS Command Line Interface or AWS Tools for PowerShell. 
💡AWS metadata service is always hosted at 169.254.169.254, port 80. 

Moving on.. While testing one of the endpoints, I found Apache Mod_Proxy SSRF (CVE-2021-40438) vulnerability. The exploit for this was just a google search away, fairly quick and easy.  I appended my Burp Collaborator payload to the exploit and received a subsequent HTTP response, which confirmed the presence of SSRF on this endpoint.

Ref: https://github.com/projectdiscovery/nuclei-templates/blob/master/cves/2021/CVE-2021-40438.yaml


On searching further for how to increase the impact of this vulnerability, I discovered the possibility of interacting with internal AWS metadata endpoint through SSRF. I appended it to my initial exploit and then moved along the directory structure until I was able to access their AccessKeyId and SecretAccessKey!

Final exploit URL: http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance


Thanks for reading!