How I Found A Full Read SSRF Leaking AWS EC2 Credentials Using Dorki.attaxa.com

SSRF is a vulnerability when you force the webserver to execute requests against a resource that you can control.

These types of vulnerabilities are most of the time very critical, especially when you can get the result of the call made by the server. As you can request internal assets or assets exposed only on the loopback of the host, you'll for sure hit sensitive endpoints.

Servers hosted on AWS -with basic configuration- are using a metadata service exposed on the local IP address 169.254.169.254 only accessible by the server. This metadata service allows the server to get some information about the type of instance he's running on, as well as its IP address, VPC configuration and credentials for this instance! These credentials can later be used to make API calls through AWS CLI.

That being said, let's see how I uncovered a hidden asset of the company redacted.com, did a basic recon of this new target and found a basic -yet critical- SSRF within 10 minutes.

Dorki.attaxa.com

First, I used dorki.attaxa.com to search for assets. I'm hacking on the company "redacted" with a wide scope, and I was looking for some news domains. Using the dork title:"redacted USA" intext:news, Dorki.attaxa.com found the following links (using the engine `seznam`)

The 6th link was very promising as I never saw this domain and it looked to be owned by my target.

The website

Using an old -but reliable- recon tool https://github.com/lc/gau against this target uncovered a few interesting resources.

The most interesting one was https://www.redacted.com/image-gallery.do. This resource provided a list of images to download. Once I've selected the images I wanted to download and clicked the download button, I was greeted with the following request:

My pentester instinct immediately told me to replace the URL with a burp collaborator to see how the app would behave.

Once I submitted the modified request, the collaborator tab flashed immediately with the following interactions:

You can see that the User-Agent that was calling me was Apache HTTPClient, which means that the server executing the request is most likely the webserver itself.

This request gave the following response:

This response includes a URL where the pictures (or the resulting HTTP responses) are zipped and stored to be sent to AWS s3. This URL is used later as an "ID" to fetch the final location of the file under a specific s3 bucket.

After this successful request, I used another call to the server to know what was the path of the resulting zip file, and which temporary AWS credentials/signature could be used to retrieve it:

Using this s3 link I can now retrieve the result of the HTTP request made by the server.

Now, by changing the URL to http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance and getting the resulting zip, we get a zip with a compressed file `ec2-instance`, and the AWS credentials in it.

Timeline

• 05/09 9h50 - New domain found with Dorki.attaxa.com

• 05/09 10h02 - SSRF found

• 05/09 10h10 - AWS EC2 credentials exfiltrated

• 05/09 13H00 - Report sent to the program

• ???