DNS Rebinding Attack: How Malicious Websites Exploit Private Networks

Executive Summary

Web-based consoles are widely adopted by management software and smart devices to provide interactive data visualization and user-friendly configuration. This is gaining momentum as enterprises’ computer systems become more complex and more modern internet of things (IoT) devices are used at home. These web applications are usually located in internal environments or private networks protected by firewalls. Therefore, they usually have a high trust level for visitors. They typically assume all visitors are authorized and thus expose sensitive information or provide administrator privileges without strong application-level protection.

Although the web services in private networks are supposed to be isolated from the internet and the same-origin policy prevents arbitrary websites from interacting with internal servers, hackers can still take advantage of web-based consoles to exploit internal networks by abusing the domain name system (DNS) through a technique called DNS rebinding. This technique can expose the attack surfaces of internal web applications to malicious websites once they launch on victims’ browsers.

In this blog, we present the mechanism and severity of the DNS rebinding attack with penetration examples. After that, we introduce the mainstream mitigations against this attack and their limitations.

Palo Alto Networks has launched a detector to capture DNS rebinding attacks from our DNS Security and passive DNS data. Our system provides scalable detection for various DNS rebinding payloads and reduces the false discovery rate by 85.09% compared to the traditional IP filtering solution. It ingests the DNS data in real time to identify penetration activities as soon as possible.

Palo Alto Networks Next-Generation Firewall customers with DNS Security, URL Filtering, and Threat Prevention security subscriptions are protected against DNS rebinding attacks.

Mechanism of DNS Rebinding

Allowing arbitrary cross-origin requests is known to be extremely dangerous. Therefore most modern browsers block these requests. However, DNS rebinding provides a way to bypass this restriction. This section introduces the importance of the same-origin policy and how the DNS rebinding technique works.

Same-origin Policy

Web applications usually require various resources such as JavaScript, images and CSS to render web pages. A web page can obtain these resources from the same server as itself or from different origins. Requesting cross-origin resources enables an application to benefit from shared resources such as third-party script libraries. However, allowing a website to access resources from arbitrary origins can be a disaster. Without access control, a malicious web page can abuse the trust granted to a legitimate user and send unauthorized requests to a critical web application on that person’s behalf. This exploit is known as cross-site request forgery (CSRF).

Modern browsers enforce the same-origin policy to mitigate this threat. This policy forbids a script from reaching web resources from different origins. Under this policy, a web page can still load cross-origin resources in its HTML tags. For example, it can embed an iframe showing third-party advertisements. However, malicious websites can’t read the response content of cross-origin requests through scripts.

DNS Rebinding

The same-origin policy identifies different origins with the combination of URI scheme, hostname and port. Among these components, browsers rely on hostnames to recognize different servers on the internet. However, hostnames are not directly bound to network devices. Instead, they are resolved to IP addresses by DNS. Then, IP addresses bind to devices statically or dynamically. Since domain owners have complete control of their DNS records, they can resolve their hostnames to arbitrary IP addresses. The DNS rebinding attack abuses this privilege. After the victims’ browsers load the attacking payloads from the hacker’s server, attackers can rebind their hostnames to internal IP addresses pointing to the target servers. This allows attackers’ scripts to access private resources through malicious hostnames without violating the same-origin policy.

Figure 1 demonstrates the mechanism of a DNS rebinding attack with a hypothetical example. In this example, the victim, Alex, has a private web service in his internal network with IP address 192[.]0.0.1. This server contains confidential data and is supposed to be accessed by Alex’s computer only. On the attack side, Bob controls two servers: a DNS resolver (1[.]2.3.4) and a web server (5[.]6.7.8) hosting the malicious website. In addition, Bob registers a domain, attack[.]com, with its nameserver (NS) record pointing to 1[.]2.3.4.

When Alex opens attack[.]com in his browser, it sends a DNS request to Bob’s resolver and retrieves the address of the malicious server, 5[.]6.7.8. Once loaded in Alex’s browser, the malicious script in Bob’s website attempts to trigger another DNS resolution for its own domain. However, this time the resolver will return 192[.]0.0.1 instead. So attack[.]com is rebound to the target IP address. After that, the malicious script can keep sending requests to attack[.]com, which eventually reach the private server. Since Alex’s browser won’t recognize these requests as cross-origin, the malicious website can read the returned secrets and exfiltrate stolen data as long as it’s open on the victim’s browser.

DNS Rebinding in Real-World Attacks

Using DNS rebinding, attackers can abuse victims’ browsers as their proxy to extend the attack surface to private networks. This technique significantly increases the potential vulnerabilities exposed to hackers as more web applications launch on enterprise and home networks. In addition, the default trust level of internal service is high. Therefore, DNS rebinding can play a pivotal role in real-world attacks combining various penetration techniques and vulnerability exploits. This section demonstrates how it’s involved in practical penetration with Singularity, an open-source DNS rebinding platform.

Private Network Penetration With DNS Rebinding

The initial step of the DNS rebinding attack is the same as other web-based attacks: tricking victims into opening malicious websites through various social engineering techniques such as sending phishing emails and cybersquatting.

After launching malicious websites on victims’ browsers, hackers need to identify the private IP addresses and ports that host vulnerable services before executing the DNS rebinding attack. The attacking websites can scan the open web services in local networks with the WebRTC technique. Singularity implements a more straightforward strategy: directly send out cross-origin requests and measure how long it takes to receive error messages. If the requested server exists, the exception will be raised more quickly. Figure 2 shows how Singularity performs when scanning our experimental environment. It recognizes the internal services hosted on 10[.]0.0.6:80 and 10[.]0.0.6:8080 in seconds. This step exposes the available targets for DNS rebinding. Through the open ports, attackers can also infer what web applications are behind these IP addresses and whether they are vulnerable.

After locating the target services, the attacker’s website can perform the DNS rebinding attack in its iframe. The first request retrieves the rebinding payload from the malicious hostname. This attacking script will keep triggering repeated resolution for its hostname until it rebinds to the target IP address. Then the iframe can keep communicating with the internal service without the victim’s awareness.

In real-world attacks, one of the potential targets of DNS rebinding is network infrastructure devices with HTTP-based consoles. For example, personal routers could be vulnerable to the attack. Many of them are set up with default configuration and weak passwords. This means that would-be penetrators can easily guess their IP addresses and rebind malicious hostnames to them. After the attackers enter the network configuration panels, they could sniff the network packages in the victim’s network, perform denial of service (DOS) attacks and hijack the traffic.

Another kind of threat comes from smart devices, which are all around many homes and offices nowadays. Besides web-based consoles, DNS rebinding can target other Restful APIs and Universal Plug and Play protocols (UPnP) servers exposed to internal networks by modern IoT devices. These APIs are reserved for function implementation or maintenance. However, some of them lack enough protection against DNS rebinding. Once attackers compromise victims’ browsers and rebind their hostnames to the target IP address, these services provide them certain privileges such as network scanning, exfiltrating sensor data and remote control without any authentication. DNS rebinding vulnerabilities have been found on multiple smart devices of high-profile companies including Google Home, Sono WiFi Speaker and Roku. As shown in Figure 3, there has been at least one CVE record related to DNS rebinding each year since 2015. The number of related CVEs has increased significantly since 2018.

For enterprises, internal management web applications are critical. They host confidential information and provide system management capabilities to administrators. Therefore, it’s extremely dangerous having a DNS rebinding website running on a machine within company networks.

Here, we launch a DNS rebinding attack on our simulated environment to illustrate the risk. The target internal web application is an internal Hadoop web interface. As shown in Figure 4a, the victim can visit this UI with URL 10[.]0.0.6:8088/cluster and check the cluster status while it’s not available externally. Figure 4b shows the rebinding request triggered by the attacker’s website on the victim’s browser. In this experiment, the malicious hostname is s-54.183.63.248-10.0.0.6-1609933722-fs-e.dynamic.dns-rebinding-attack[.]com. The HTTP request to the hostname was actually sent to 10[.]0.0.6, and it received the successful status code. After this, the attacker can use the victim’s browser as a tunnel and directly interact with the target service. As shown in figure 4c, the attacker can obtain the same information that the victim can access from the Hadoop cluster through the malicious domain. Besides stealing information, the attacker also has the privilege to kill running jobs on the management page. As we saw in this example with Hadoop, many widely used development and management platforms could be exposed to threat actors equipped with DNS rebinding if not protected correctly.

Cross-origin Request Forgery Protection Bypass

Besides simply tunneling traffic for attackers, malicious websites can use the DNS rebinding technique to bypass token-based CSRF protection. While DNS rebinding hides the cross-origin traffic, CSRF directly sends cross-origin requests to take advantage of the target server’s trust for the victim. CSRF is a well-known threat, and many web applications have implemented defenses against it. One mainstream protection strategy embeds a unique token to the initial response page. All the following requests need to be sent with this token to be accepted by the server. This solution is based on the same-origin restriction, which prevents malicious websites from reading the response content of cross-origin requests. Since attackers can’t obtain the token from the response, they have no chance of sending out valid cross-site requests.

However, browsers won’t notice any cross-origin request under the DNS rebinding attack. This means they will allow malicious scripts to obtain the CSRF token from the initial responses and use it for follow-up request forgery.

We launched the remote command execution (RCE) payload of Singularity in our simulation environment to demonstrate this threat. This attack targets Rails, a web development framework written in Ruby. One of its reserved PUT APIs allows the requester to run arbitrary system commands on the server. Similar to the CSRF token, this API requires the visitor to generate the request URL with a dynamic session ID (the string marked in red in Figure 5), which is embedded on the main page. The web application will generate a new token on the fly and map one to each session. It’s impossible to predict the valid API endpoint without reading responses from the server. However, the Singularity RCE payload can obtain the token from the index page after executing DNS rebinding. In the demo, we let the malicious site print the stolen session ID to the browser console. Then it successfully constructed the desired URL and used the vulnerable API to execute an arbitrary command on the server-side, which displays a “Hello from rebinding test” message on the server terminals. After the Singularity team published this exploit, Rails enforced server-side mitigation to validate the host field of all incoming requests.

DNS Rebinding Protection

Various strategies attempt to mitigate the DNS rebinding attack in each related network component. In this section, we introduce different defense mechanisms and their limitations. After that, we will present the basic idea of our DNS rebinding detector and its advantages.

Browser-based Mitigation

Modern browsers such as Chrome and Firefox have implemented the DNS pinning technique to defend against the DNS rebinding attack. This strategy forces the browser to cache the DNS resolution results for a fixed period regardless of the DNS records’ time-to-live (TTL) value. Consequently, malicious websites can’t rebind their hostnames by making repeated DNS requests within this period. This protection is convenient because it can be implemented in browsers without changing any other network infrastructure. However, it can only effectively block the time-varying attack, which is a traditional implementation of the DNS rebinding attack. In this implementation, the attackers assign an extremely low TTL to the DNS record of malicious hostnames. After being loaded in the victim’s browser, the rebinding script waits for the record expiration and then sends a request to its hostname, expecting the browser to resolve it again and get the target IP address back. In this scenario, the DNS pinning technique ignores the low TTL and still uses the same result for the second request.

However, there are multiple ways to bypass DNS pinning protection. A simple way is to design the malicious script to send requests repeatedly until the browser cache expires. Then the malicious hostname will rebind to the target IP address. Then, the attacker’s website can receive the expected response from the target service.

A more sophisticated implementation called multiple A-records attacks can achieve DNS rebinding more stably and efficiently even with DNS pinning protection. Figure 6 presents the attacking procedures. In this case, the DNS behavior is different from the traditional attack: The victim’s browser only resolves the malicious hostname once. But both the attacker’s and the target’s IP address are returned. When the malicious script sends the second request, the browser will try the public IP address first. But the attacker’s web server remembers the victim’s IP address and blocks the incoming traffic by firewall. This request failure forces the victim’s browser to communicate to the private IP address and complete the DNS rebinding procedure.

DNS-based Mitigation

Another type of mitigation focuses on the DNS resolution stage. The secure DNS service, OpenDNS, drops the DNS responses pointing to RFC 1918 and loopback IP addresses. DNS caching software such as Dnsmasq and Unbound also implement similar filtering policies for private IP addresses.

This strategy is also a centralized protection solution, but it still has limitations. First of all, not all the secured DNS services have blocked the complete list of IP addresses pointing to private services. For example, the non-routable IP address 0[.]0.0.0 can represent the IP addresses of the local machine and can be targeted by a DNS rebinding attack. However, multiple filtering policies have missed it. Besides the private IP addresses, attackers can rebind their hostnames to internal hostnames with CNAME records. The victims’ internal resolvers or their machines will finish the resolution to private IP addresses for the attackers. For example, a malicious hostname can be rebound to localhost. Then all following traffic will reach the local service. In summary, IP-based filtering fails to protect against all types of DNS rebinding attacks.

Furthermore, filtering out all private IP addresses could cause many cases of blocking false positives. We observed that some legitimate services present similar DNS resolution behaviors as DNS rebinding. For example, some IoT services rely on hostnames to direct traffic within private networks. This means their hostnames are resolved to internal IP addresses only and can be mistakenly blocked by this solution. Besides, some benign hostnames also resolve to both public and private IP addresses that violate this protection policy. For example, public services could have mirror servers in the maintainers’ networks for continuous development and traffic optimization. Their hostnames have public A records pointing to public and private IP addresses. In these cases, the maintainers will talk to the internal server while the public server handles other traffic.

We measure the hostnames resolved to internal IP addresses in passive DNS data to quantify the impact of false blocking. In June 2021, 8.99% of total active hostnames pointed to private IP addresses. DNS-based mitigation would block all of their traffic. However, 99.84% of these hostnames never point to any public IP, which means they don’t present the complete DNS rebinding behavior and shouldn’t be blocked. The false discovery rate for DNS traffic of this mitigation is 85.09%.

Server-based Mitigation

Defenses on the web applications side can block DNS rebinding effectively. One of the solutions is implementing HTTPS communication on all private services. The HTTPS handshake stage requires the correct domain to validate the SSL certificate. During a DNS rebinding attack, browsers think they are communicating to the malicious domains while the SSL certificates from the internal servers are for different domains. Therefore, the attacking scripts can’t establish SSL connections to the target services. Alternatively, implementing authentication with strong credentials on all private services is also effective. With this application-level protection, even if attackers launch DNS rebinding successfully, they can’t access confidential information.

However, this kind of mitigation depends on the developer of internal services. This means it is not scalable. As third-party web applications populate in both home and enterprise environments, it’s more difficult for the network owners to enforce protection to all potentially vulnerable servers. Meanwhile, threat hunters keep digging DNS rebinding vulnerabilities from third-party web applications – such as the Rails console RCE exploit mentioned in the previous section.

Real-time DNS Rebinding Detection

As our DNS Security service monitors our customers’ DNS traffic to provide real-time protection, we have the opportunity to enforce sophisticated signatures to recognize the abnormal DNS query pattern of the DNS rebinding attack. We launched a detection system consuming DNS Security and passive DNS data to capture the indicators of compromise (IOCs) of ongoing rebinding attacks. The detector tracking DNS Security traffic can identify and deliver malicious hostnames in real time.

Our system aims to capture the sequential DNS resolution pattern instead of relying on isolated DNS responses. Its detection logic can identify DNS rebinding with high confidence while allowing hostnames that resolve to internal IP addresses only for legitimate usage. Besides the high detection accuracy, our system can cover all the varieties of DNS rebinding attacks mentioned previously, including time-varying, multiple A-records and CNAME-based attacks. Apart from attacks targeting internal IP addresses and localhost, it also recognizes malicious hostname rebinding to the internal hostnames of our customers.

Behind the detection module, we aggregate multiple layers of legitimate usage filters to prevent false positive detection. As mentioned above, many innocent hostnames could present similar resolution behavior as the DNS rebinding attack. It’s hard to differentiate them from malicious hostnames without additional information. Our filters combine external knowledge such as passive DNS traffic, WHOIS records and customer feedback to exclude customers’ internal hostnames and other benign services.

Conclusion

The DNS rebinding attack can compromise victims’ browsers as traffic tunnels to exploit private services. With this technique, attackers can steal confidential information and send forged requests to victims’ servers. Browsers, resolvers and web applications have applied various protection strategies to defend against it. However, there are advanced exploits that can bypass traditional defenses. In addition, it’s harder to enforce complete protection as the internal network environment becomes more complex.

At Palo Alto Networks, we have launched a DNS rebinding detection system to protect our customers. It can effectively identify various implementations of DNS rebinding that leverage multiple types of DNS records and present different resolution behaviors. The system’s filtering module can identify legitimate usage of internal IP resolution to prevent false blocking. After capturing potential penetration activities, our system will release the attacking hostname with the command and control category to Palo Alto Networks Next-Generation Firewall security subscriptions in real time.

Acknowledgments

Special thanks to Laura Novak and Daiping Liu for their help with improving the blog.

Source: https://unit42.paloaltonetworks.com/dns-rebinding/?web_view=true