Introduction

Server-Side Request Forgery (SSRF) attacks manipulate server-side requests to gain unauthorized access to sensitive external resources. Standard SSRF techniques do not always succeed. In this article, we explore an efficient method using an intentionally vulnerable web application to bypass external authorization and access controls. First, let’s review some key concepts:

DNS
A Domain Name System (DNS) is a system that allows resolving hostnames and domain names to IP addresses. DNS acts as the internet’s directory, translating user-friendly domain names into numerical IP addresses for communication between computers. Additionally, each domain includes a Time To Live (TTL), which tells caching servers exactly how long they should store the domain information. The TTL is expressed in seconds.

Same-origin Policy

The Same-Origin Policy (SOP) is a browser security mechanism that restricts web pages from accessing resources of different origins. It enforces the rule that web content from different origins cannot interact unless the user or server allows it. Under the SOP, web pages can access only resources from the same origin, defined by the protocol, hostname, and port number. This restriction prevents malicious websites from accessing sensitive information or performing unauthorized actions on behalf of other users.

Explanation of The Attack

To perform this attack, control a DNS server that holds two IP addresses for a single domain with a low TTL (ideally one second). Using the online DNS rebinding service rbndr.us, you can efficiently provide one internal IP and one public IP linked to a well-known domain.

When attackers combine SSRF with DNS Rebinding effectively, they create a highly potent attack vector. Although this technique is less common today, it remains dangerous. In addition, it bypasses the Same-Origin Policy, which can lead to unauthorized access to internal resources. Therefore, web applications must implement strict validations to defend against this type of attack. From the browser’s perspective, the targeted server and the loopback address appear to belong to the same domain.

In the below screenshot, we will use the rebinder service and provide a loopback address as the left argument and the IP address of the Google DNS services as the right argument. As a result, it will be resolved into one domain name that we can use during the attack scenario.

Attack Scenario

The web application enables users to upload files and access them via a dedicated link. Each user is identified by long, random UUIDs, and access controls appear properly separated. The file upload mechanism works by submitting a full URL as user input, which triggers a request to the POST /api/v2/upload endpoint. Initially, we attempted to use an internal URL via the file_url parameter to access server resources. Nevertheless, the server blocked our attempts and immediately returned a 403 Forbidden message, clearly indicating that requests to localhost were not allowed.

ChatGPT said:

Despite multiple attempts, we could not bypass the blocklist, which therefore confirms it is properly enforced. As a result, our only remaining option is to combine SSRF with the previously discussed DNS Rebinding attack. Next, if the web server does not fully validate the user-provided domain, we can exploit this by using the previously generated domain as the file_url parameter. Furthermore, since DNS records refresh every second, each query quickly expires, thereby forcing the server to resolve the domain to a different IP. Consequently, each request should return two responses: first, 403 Forbidden, and then a successful internal server response.

With the necessary conditions in place, we then send a request to the upload API, and the provided URL subsequently resolves randomly to either 8.8.8.8 (Google DNS) or 127.0.0.1 (localhost).

It appears that the server has sent an HTTP 200 OK response on the second attempt, potentially indicating that we have gained access to its internal resources. This presents an opportunity to explore and access additional information.

To verify the vulnerability, we first searched for common endpoints on the server. Eventually, this search revealed an internal endpoint, /api/users, which exposes all users’ UUIDs.

The successful exploitation of the SSRF vulnerability in conjunction with DNS rebinding confirms that these attack techniques can effectively bypass the implemented authorization controls of the system.

With these fetched UUIDs, it was possible to carry on with the exploitation and access users’ personal files, as follows:

Mitigation

In these cases, Clear Gate advises performing the following actions to prevent SSRF attacks:

• Enable DNSSEC and validate domain records before making a connection.
• Implement proper restrictions on valid domain names on the application.
• Ensure all user data is validated against a known list of approved domains.
• Configure web servers to block outbound requests to private IP addresses.
• Return a generic error that does not reveals information that can be vital for the adversary.

References

• DNS-Rebinding-Online-Tool
• Docker-Lab
• DNSSEC