In this blog, I'll walk you through how SSRF can be exploited to access AWS EC2 metadata and why it poses a critical security risk.

First of all, let me explain what SSRF is for those who are new to this vulnerability.

What is SSRF?

SSRF (Server-Side Request Forgery) is a vulnerability where an attacker tricks a server into making requests to unintended locations, such as:

  • Internal systems
  • Localhost
  • Cloud services

Let's explore how this works in a real-world scenario.

While testing a web application for one of our clients, I began by reviewing the application as part of my assessment. During this process, I identified a tool within the application and decided to evaluate it after completing the overall testing.

Once the application testing was completed, I proceeded to assess the tool. It allowed users to select HTTP methods, input a URL and port number, and view the corresponding response. To better understand its functionality, I contacted the SPOC, who explained that it works similarly to Postman and is used for API testing.

During testing, I explored the possibility of SSRF by providing a localhost IP along with common ports such as 80, 22, and 21. Since successful responses can indicate SSRF behavior, I tested multiple ports and received valid responses for ports 80 and 22, suggesting a potential SSRF vulnerability.

For further exploit, I researched exploitation techniques and came across a blog on HackerOne. This helped me learn how SSRF can be leveraged to access sensitive EC2 instance metadata.

What is AWS EC2 Instance Metadata?

If an application is hosted on an EC2 instance, it can make requests to the internal Instance Metadata Service (IMDS), accessible at http://169.254.169.254/latest/meta-data/. This service does not require authentication by default and can expose sensitive information such as IAM credentials (Access Key, Secret Key, Token), instance ID, security groups, and network configuration.

While testing, I used Shodan for reconnaissance and confirmed that the application was hosted on an AWS EC2 instance. I then attempted to access the metadata by entering the IMDS URL into the tool and submitting the request. The application returned a successful response, exposing sensitive metadata including IAM credentials, instance ID, security groups, and network configuration. I captured screenshots as evidence and documented the finding in the report.

This demonstrates that if an application is hosted on an AWS EC2 instance and is vulnerable to SSRF attack, an attacker can exploit it to access the Instance Metadata Service and retrieve sensitive information.

Hope this blog added value to your knowledge, the same way this finding expanded mine. Until next time, stay curious and keep hacking.

Every vulnerability teaches something new.

None