Introduction

Server-Side Request Forgery (SSRF) is a type of attack that manipulates requests sent to a targeted system by exploiting server-side components, allowing attackers to gain unauthorized access to sensitive resources externally. However, standard techniques for exploiting SSRF attacks may not always be effective. In this article, we will explore an interesting and efficient method (through an intentionally vulnerable web application) for bypassing external authorization or access control validations commonly used to protect against SSRF attacks. First of all, we need to familiarize ourselves with several concepts:

DNS
A Domain Name System (DNS) is a system that allows resolving hostnames and domain names to IP addresses. DNS functions as an internet directory structure and is responsible for translating user-friendly domain names into the numerical IP addresses computers need to communicate with each other. Each domain name also has a Time To Live (TTL) which is used to tell caching servers how long the domain name should be stored. 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 principle that web content served from different origins should not interact with each other unless explicitly allowed by the user or the server. Under the SOP, web pages can only access resources from the same origin, which is defined as the combination of 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, we must control a DNS server that holds a record of two different IP addresses, which will be associated with a single domain name and a low TTL (preferably one second). Using an online DNS rebinding service called rbndr.us, it is possible to achieve this action efficiently. It can be done by providing two different IP addresses to its input – one should have an internal IP address, and the second should have a valid public IP address associated with a well-known domain.

When SSRF and DNS Rebinding are used effectively, they can pose a powerful combination. While not a commonly used attack vector nowadays, it can still result in dangerous outcomes as it bypasses the Same-Origin Policy. This is because, from the perspective of the browser, the targeted server and the loopback address exist in 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 values known as UUIDs, and the access control appears to be adequately separated between users. Furthermore, the file upload mechanism operates by providing a complete URL as the user input, which then triggers a request to the POST /api/v2/upload API endpoint.
Given the behavior of the file upload mechanism, we initially considered using an internal URL to access server resources, which involves passing the file_url parameter in the request. However, our attempts were unsuccessful as we received a 403 Forbidden message from the server indicating that requests to localhost are not permitted.

Despite many attempts to circumvent this implementation, none have been successful, indicating that the blocklist has been appropriately implemented and cannot be bypassed. As a result, the only remaining option available to us is to attempt the combination of SSRF with the DNS Rebinding attack that was previously mentioned.

Assuming that the web server does not completely validate the user-provided domain name, we can exploit this vulnerability by using the previously generated domain as the file_url parameter value. As mentioned, the DNS records for this URL refresh every second, causing the query to expire and forcing the targeted server to request a new query that will be resolved to a different IP address. With each request sent to the web server, we are expecting to receive two responses: the first is the original 403 Forbidden message from the previous request, while the second is an HTTP message that preferably indicates a successful response from the internal server.

With the necessary conditions established, the next step is to send a request to the upload API again, and the provided URL will be randomly resolved 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 indeed exist, we searched for common endpoints that may be available on the server. Ultimately, our search led us to discover an internal endpoint, namely /api/users, which discloses all the 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