SSRF via TOCTOU DNS Rebinding

In the context of Server-Side Request Forgery (SSRF), DNS Rebinding is a TOC/TOU attack, wholly reliant on a domain controlled by the attacker and its DNS configuration, where the attacker manipulates the IP address resolution process performed by the vulnerable web application server.

An example public DNS Rebinding service is 1u.ms, offering a range of convenient configuration solutions along with a publicly accessible event log, that can be useful if you don't have a machine assigned an address from a public address space.

Let's imagine a hypothetical scenario for circumventing local IP address filtering using this technique:

  1. Suppose that the target web application's back-end server expects a URI within an HTTP request directed to a specific API endpoint. The server's objective is to retrieve the web page's content based on the provided URI and store its render in a database for subsequent client viewing.
  2. A protective function against SSRF has been implemented on the back-end server which is filtering IP addresses obtained from URIs, rejecting potentially dangerous addresses (e.g., the loopback interface address 127.0.0.1 or the "cloud localhost").
  3. The attacker, as part of a request to the target API endpoint, includes their server's domain name in the HTTP request. This domain is registered, hosted, and configured on a public DNS server as follows:
  • The domain has two records. Let's assume that one record points to an IP address in the public IP space, such as 1.2.3.4, and the other points to 127.0.0.1.
  • The configuration includes setting an extremely low Time-To-Live (TTL) value for the first IP's resolution response, preventing extended caching of the response on the receiving end.
  1. Consequently, the filtering function on the vulnerable server, when reaching out to the public DNS server to resolve the client-supplied domain name and apply filtering, obtains a "normal" IP address. Upon confirming the safety of the obtained address, it caches it for a very short duration. This cached record quickly becomes obsolete.
  2. Since the validating function has verified the safety of the obtained address, the request is passed to the executing function. However, due to the insecure configuration of this functionality on the back-end, instead of using the IP obtained by the validating function, the executing function queries the local DNS cache and, failing to find a record for the required host, makes another DNS request, assuming that the result will match what the validating function obtained. Nonetheless, the executing function receives a different IP address, pointing to the server's loopback interface.
  3. Consequently, when making a request to the local IP address, the server generates a response based on the components of the URI under the attacker's control, and the result of the request is displayed on the client side.

This scenario is presented here as an example and is far from exhaustive. The process of detection and exploitation heavily relies on the code and configurations on the target web server's side.