During a penetration testing engagement with CyberAr, I focused on examining the security of a cloud service’s advanced features. I discovered a Server-Side Request Forgery (SSRF) vulnerability that allowed me to expose and access AWS credentials, leading to significant security risks.
The application provides an advanced automation feature aimed at helping users allowing the creation of custom workflows. This feature is tucked away in the advanced settings, It enables users to configure a series of actions, such as sending HTTP requests to specific URLs, based on predefined triggers like the creation of a new project or other key events within the application.
I was meticulously exploring the various functionalities of the application to identify potential vulnerabilities. While many of the features were straightforward, the automation feature in the advanced user settings stood out to me. The ability to send and test HTTP requests using different HTTP methods and to any URL of my choosing caught my interest because it offered a lot of flexibility—but also posed a potential risk if it wasn’t secure.
I recognized that this level of control could be a double-edged sword. Although the feature was intended to streamline workflows, it also opened up the possibility for abuse if the input parameters were not properly validated. This realization made it an obvious choice for further investigation, and I decided to focus on testing this particular aspect of the application.
First, I wanted to test whether the automation feature actually sends requests using the server or if it uses any type of crawler or URL filters. To do this, I sent a collaborator payload using Interactsh to see if the application would generate an HTTP request.
This helped me determine whether the feature sends HTTP requests or only performs DNS lookups to check URLs. I received a response from the server, which revealed an IP address that was not internal but was an Amazon IP address (in the range 3.22X.X.X).
Using IPinfo.io, I identified this IP as belonging to Amazon.
Knowing that the application interacts with Amazon services, I proceeded to craft SSRF payloads targeting AWS endpoints. I started with a payload of http://169.254.169.254/latest/meta-data, which successfully returned a response from the server.
For the final payload, I used:
http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance
This payload allowed me to retrieve sensitive IAM credentials directly from the instance. The application’s lack of restrictions on URL input made it possible to target internal resources, leading to the exposure of critical data. This demonstrated how easily unauthorized access could be achieved due to the vulnerability.
The SSRF vulnerability allows attackers to gain unauthorized access to sensitive information stored within the cloud infrastructure. In this case, the exposed IAM credentials could be used to assume roles within the AWS environment, potentially leading to unauthorized data access, privilege escalation, and further compromise of the cloud environment. This vulnerability not only compromises the affected instance but could also potentially cascade into wider network exploitation, putting additional resources at risk. The business impact is severe, as it threatens the confidentiality, integrity, and availability of cloud resources.
https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_(SSRF)/
https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf
https://medium.com/@Parag_Bagul/ssrf-attack-leading-to-aws-metadata-e95155fa6c6f