DNS Rebinding: Tools & Prevention

---

This section will introduce Singularity, a robust and versatile DNS rebinding attack framework. Moreover, we will explore techniques to prevent DNS rebinding.

---

DNS Rebinding Tools

Since DNS rebinding attacks are rather complex, we should avoid configuring everything manually. Luckily for us, there are useful tools we can use to help us in executing DNS rebinding attacks, such as Singularity, a powerful DNS rebinding attack framework. To install it, we can run the following commands:

[!bash!]$ git clone https://github.com/nccgroup/singularity
[!bash!]$ cd singularity/cmd/singularity-server
[!bash!]$ go build

Afterward, we can run the web interface, which we need to start on the same port as the web application we want to exfiltrate data from:

[!bash!]$ mkdir -p ~/singularity/html
[!bash!]$ cp singularity-server ~/singularity/
[!bash!]$ cp -r ../../html/* ~/singularity/html/
[!bash!]$ sudo ~/singularity/singularity-server --HTTPServerPort 80

Temporary secret: da4a821b782287813a5d366f476d5c0d406f3799
2023/05/14 10:40:26 Main: Starting DNS Server at 53
2023/05/14 10:40:26 HTTP: starting HTTP Websockets/Proxy Server on :3129
2023/05/14 10:40:26 HTTP: starting HTTP Server on :80

Next, we need to configure Singularity as the nameserver for our domain. In our example from the previous section, our domain is attacker.htb. For more details on configuring the DNS settings correctly, we can check out Singularity's setup guide.

After setting everything up, we can run the DNS rebinding attack discussed in the previous section using Singularity. To do so, we will simulate the victim, located in the same network as the internal web application targeted by the attack. Due to the default configuration of Singularity, the domain names and paths differ slightly from the previous section, but the attack methodology is the same.

First, the victim browses to http://rebinder.attacker.htb, which displays the singularity web interface where we can configure the attack. To match our example, we need to set the following settings (PUBLIC_WEBSERVER_IP is the public IP address of our Singularity server):

Afterward, we can click on Start Attack. This might take a couple of minutes to finish due to the DNS pinning implemented by the web browser. After succeeding, the fetched local resource is displayed in an alert popup:

Singularity does not exfiltrate the data to http://exfiltrate.attacker.htb:1337 as we did in the previous section. However, the alert popup proves that the origin http://rebinder.attacker.htb successfully accessed the local resource http://192.168.178.1, bypassing the Same-Origin policy using DNS rebinding.

For more details about how to configure Singularity's advanced options and fine-tune the DNS rebinding exploit, have a look at Singularity's wiki.

---

Prevention

SSRF Filter Bypasses

As we have discussed, preventing access to the internal network via SSRF filters is a challenging task. We must consider how different protocols, such as DNS and HTTP, interplay and what options an attacker has to make our application access the internal network. Generally, there are a few best practices we can apply to reduce the risk:

1. Resolve the domain name passed to the application before checking it; this ensures that we are working on an IP address in the format we expect, and we do not have to worry about domain names such as localtest.me, localhost or IP addresses in an unexpected format (such as hex or octal representations).
2. If possible, check the resolved IP address against a whitelist of allowed IP addresses. If this is impossible, block the entire private IP address range, i.e., 10.0.0.0/8, 172.16.0.0./12, and 192.168.0.0/16. Additionally, block all IP addresses that might resolve to the local machine, which include 127.0.0.0/8 and 0.0.0.0/8.
3. Consider redirects. If the application follows redirects, consider how the filter can be bypassed using HTTP or HTML redirects and implement application-dependent mitigations accordingly.
4. Most importantly: Implement firewall rules that prevent outgoing access from the system the vulnerable application runs on to the internal network. This prevents any access even if filters get bypassed.

Preventing SSRF filter bypasses via DNS rebinding can be achieved by not resolving the domain name twice. After resolving it in the SSRF filter, we need to fix the resolved IP address and reuse it when the application makes the actual request; the implementation of how to achieve this is application dependent.

DNS Rebinding

The danger of Same-Origin policy bypasses via DNS rebinding is that this technique enables attackers to access applications running in the victim's local network, thus circumventing security controls such as firewalls or NAT. System administrators often assume that the local network is trusted and that no additional authentication is required when accessing an application. For instance, if there is a printer on the local network, everyone who can connect to the printer can typically print without any authentication. However, as we learned, DNS rebinding breaches these faulty assumptions.

Because DNS rebinding vulnerabilities are not caused by a specific flaw in an application, we need to ensure the following best practices when designing our internal network:

1. Use authentication on all services in the internal network. DNS rebinding can only be used to access internal applications with the cookies of the corresponding domain name. If an attacker does not know credentials to the internal application to log in themselves, only unauthenticated access can be achieved. Thus, it is vital to protect sensitive information or functionality using authentication, even if it is only exposed within the local network.
2. Use TLS on all external and internal services. If an attacker uses DNS rebinding to access an internal service over TLS, there will be a certificate mismatch as the access uses an incorrect domain name. For more details about HTTPs and TLS attacks, check out the HTTPs/TLS Attacks module.

Additionally, there are a few hardening measures we can implement to prevent DNS rebinding attacks:

1. Refuse DNS lookups of internal IP addresses. Suppose the DNS server responds to any DNS request containing a domain name that resolves to an internal IP address with an NXDOMAIN response (i.e., a response indicating that the domain name does not exist). In that case, it becomes impossible to conduct DNS rebinding since internal IP addresses are not resolved.
2. Validate the HTTP Host header of incoming HTTP requests. Due to the nature of DNS rebinding, the resulting access to the internal network uses an incorrect domain name and, thus, an incorrect Host header. If the targeted application checks the Host header, it receives an unexpected value and should reject the request. For more details on the Host header and its attacks, check out the Abusing HTTP Misconfigurations module.