Finding Hundreds of SSRF Vulnerabilities on AWS

During our latest research project on Trickest, which involved uncovering IP addresses hidden behind proxies like Cloudflare we stumbled upon numerous IPs susceptible to SSRF via the Host header.

For those unfamiliar with SSRF, here's a definition:

Server-side request forgery (SSRF) is a web security flaw that enables an attacker to manipulate server-side applications into making HTTP requests to any domain the attacker chooses. SSRF can be exploited to access services and resources that are not meant to be reachable from external networks, bypass firewalls, perform internal network port scanning, access local or internal services (e.g. databases, mail servers), exploit server-side vulnerabilities, execute Denial of Service (DoS) attacks, extract data from internal networks, bypass authentication and authorization systems, and access sensitive data like environment variables and configuration files. SSRF can also be used to exploit various protocols, including Gopher, WSGI, Netdoc, and TLS-Poison. Attackers may use tools like Gopherus, SSRFTest, Bug-Bounty-Toolz, SSRF-Testing, SSRProxy, and SSRFire to aid their attacks, as well as SSRF bypasses such as URL bypasses, localhost bypasses, blind SSRF, video uploads, pdf rendering, SFTP, DOM XSS, and XSS to CSRF.

Accidentally Discovering Numerous SSRFs

During our research, we noticed that the website cloudflare.malwareworld.com could be accessed from hundreds of pages, which seemed quite unusual.

Upon further investigation, we found that some pages were redirecting to this domain via HTTP headers. While this vulnerability wasn't our focus, we realized that other domains were directly sending requests to cloudflare.malwareworld.com and returning the collected responses.

We also discovered that our research was limited to AWS-owned IP addresses.

By exploiting the SSRF vulnerability, we were able to access the metadata endpoint using a request like c url -k -H "Host: 169.254.169.254" "https://<IP>:443/" and verifying that the response contained 2022-09-24 and latest.

Next, we created a Trickest workflow to systematically scan all AWS URLs and identify vulnerable servers with access to the metadata endpoint via SSRF. In the end, we discovered over 550 IPs vulnerable to SSRF.

It's worth nothing that these steps took several days to complete, as we had to iterate on the workflow multiple times, with each run taking more than ten hours due to the nearly 13 million web servers under investigation.

The Workflows

Scan AWS Workflow

The start is a workflow to scan AWS IP Ranges.

SSRF Workflow

The workflow consisted of the following components:

• A node to collect the zipped output from the workflow above.
• Nodes to decompress the data and process it in batches of 55,000 URLs (out of almost 13 million URLs).
• An httpx node that sent the HTTP header Host: customer1.app.localhost.my.company.169.254.169.254.nip.io in the request, checking if the response came from a metadata service.

Executing this workflow took 12.5 hours to complete using 1 small, 3 medium, and 1 large machine. In total, 551 hosts were found vulnerable to metadata leakage via SSRF in the host header.

We also tested this workflow on GCP IPs, but only found a few vulnerable IPs.

Identifying the Companies

Upon discovering hundreds of vulnerable IP addresses, we were faced with the challenge of identifying their respective owners.

Initially, we attempted to access the associated web pages, only to discover that they were owned by a multitude of different companies. As a result, we decided to inspect the IAM role names (and not credentials) associated with the vulnerable IPs via the metadata endpoint, and found that over 500 of them were associated with the name AmazonLightsailInstanceRole.

Amazon Lightsail is a cloud computing service offered by Amazon Web Services (AWS) that provides low-cost virtual private servers and other resources. It is intended to be a user-friendly solution for small businesses, developers, and entrepreneurs looking to quickly get started with cloud computing, and provides access to the Container Service (Fargate), enabling users to deploy common web services within seconds via VMs (EC2) and containers.

It appears that the vulnerability may therefore be present within a Lightsail image that multiple companies are utilizing, potentially to host their websites via WordPress. To mitigate this issue, we reported the vulnerability to AWS, so they could address the issue and inform affected companies.

Despite this, we still encountered 26 IPs that were affected by SSRF and weren't related with Lightsail. These IPs had a different IAM role name attached to them, which was either related to EC2 or EKS, or no IAM role was attached at all. To determine the companies that these IPs belonged to, we utilized several methods, including:

• Examining the name of the IAM role: Some IAM roles had the company name in the title, which was helpful in identifying their ownership (although perhaps not ideal from a security standpoint).
• Analyzing the web page returned by the IP: Certain IPs either redirected to a domain name or provided the web page that they were hosting, which made it easy to identify the company hosting the web page.
• Reviewing the TLS certificate: While some IPs did not return any webpage, they had a relevant domain name in the CN field of their TLS certificate, which aided in identifying the true owners of the IP.

Despite these methods, some IPs were served by HTTP (with no TLS certificate) and returned no meaningful content in the response body or headers, which made it challenging to determine the owners of the server. We reported those ones also to AWS. (If you have other ideas to easily find the owners of this kind of servers let us know!)

Responsible Disclosure

Regarding the AWS case, we reported the vulnerabilities to the appropriate contact, which in this case was aws-security@amazon.com. After exchanging several messages with the AWS team, the root causes of the vulnerabilities were not fully determined, but it was verified that the latest versions of the Lightsail images are not vulnerable by default. Therefore, all Lightsail users are advised to update their images to the latest version and only allow IMDSv2 (metadata version 2).

For IPs that did not belong to AWS, we searched for relevant individuals working in the companies through LinkedIn and contacted them. We identified relevant personnel in four companies, and two of them responded and remediated the vulnerability within a week.

We also requested from AWS to contact the remaining vulnerable companies.

Wrapping Up

In conclusion, this fascinating journey into the accidental discovery of numerous SSRF vulnerabilities showcases the importance of vigilance and staying on top of the ever-evolving cybersecurity landscape. These findings serve as a strong reminder that businesses of all sizes must take a proactive approach to safeguard their digital assets, especially when leveraging cloud services.

Our mission was not only to explore this captivating world of vulnerabilities but also to ensure responsible disclosure to protect the affected companies and minimize potential harm. This experience highlights the immense value of fostering a strong cybersecurity community, where professionals work hand-in-hand to improve the overall safety and resilience of the internet.

For businesses utilizing cloud services, it is vital to take a proactive stance in securing their online assets. Perform regular security audits, keep instances and services up-to-date, and follow best practices for a secure cloud environment. By doing so, you'll not only protect your digital resources but also maintain a strong online reputation, ensuring that your company thrives in the fast-paced, interconnected world of today.

Sign up on Trickest today and run workflows from this blog post asap!