A few months ago when I was first learning about ssrf vulnerabilities, I came across a few blogs and hackerone reports explaining different scenarios in which ssrf vulnerabilities can be leveraged to escalate the impact. I was able to apply this knowledge when looking through Google’s acquisition “Apigee”. This vulnerability was found on a test subdomain, which had a feature allowing users to make external http calls. The page containing this feature is shown below.
When testing its functionality, I could see it made http requests to external urls entered in the URI field and then displayed the resulting output. When altering the “URI” form parameter, I attempted several different uri handlers such as ftp, ssh, sftp, smtp, etc and also tried some php redirects to see if it would connect to my server, but it seemed that only http(s) would work. I then remember reading about querying AWS metadata via SSRF so I decided to try that, and entered the host http://169.254.169.254 in the URI parameter to query the AWS meta data instance.
This was the following output, demonstrating that the recovery of the aws meta data was possible through this SSRF vulnerability.
This vulnerability exposes the internal AWS meta data containing private server keys and other sensitive server information. I reported this along with an SQLi vulnerability to Google’s VRP found here: https://www.google.com/about/appsecurity/reward-program/ , but sadly both were marked as duplicates :(. Disappointing, however finding a new vulnerability is always exciting, and provides for a good learning opportunity.