Dns Rebinding Attack

Dns Rebinding is a network attack that exploits the trust relationship between browsers and local network services. The attack takes advantage of how browsers handle DNS caching and same-origin policies to bypass security controls that normally prevent web pages from accessing local network resources.

The attack unfolds in two distinct phases. First, the attacker serves a malicious web page that includes JavaScript code designed to communicate with a domain they control. When the victim's browser loads this page, it initiates a DNS request to resolve the attacker's domain to an IP address.

Here's where the deception begins. The attacker's DNS server responds with a public IP address during the first request, allowing the browser to establish a connection and begin executing the malicious JavaScript. This initial communication helps the attacker bypass browser security warnings that might alert users to suspicious activity.

During this first phase, the JavaScript running in the victim's browser establishes what appears to be a legitimate connection to the attacker's server. The browser caches this DNS resolution, believing it has properly identified the origin of the content it's interacting with.

The second phase is where the attack becomes dangerous. After a brief delay, the attacker's DNS server responds to a second DNS request from the same browser with a completely different IP address - typically a private IP address on the victim's local network, such as 192.168.1.1 or 10.0.0.1.

Because browsers implement DNS pinning with relatively short timeouts (usually 60 seconds or less), the cached DNS entry expires and the browser makes a new request. The attacker times this carefully to ensure the second request occurs after the initial connection is established but before any security mechanisms would normally prevent access to local resources.

When the browser receives the private IP address, it attempts to connect to what it believes is the same origin as before. However, this connection now targets a device on the victim's internal network - perhaps a router, smart TV, or IoT device that trusts connections from the local network.

The browser's same-origin policy, which normally prevents JavaScript from making requests to different domains, is effectively bypassed because the domain name hasn't changed - only the IP address has. This allows the malicious script to communicate directly with internal devices as if it were a trusted local application.

Common targets include home routers with administrative interfaces, network-attached storage devices, smart home controllers, and industrial control systems. Many of these devices have weak or default authentication, making them particularly vulnerable once network access is achieved.

Dns Rebinding attacks target APIs by exploiting the trust relationships between web applications and backend services. When APIs are designed to trust requests from specific origins or internal networks, they become vulnerable to this class of attack.

Consider a typical microservices architecture where frontend applications communicate with backend APIs. These APIs might implement origin-based authentication, allowing requests from specific domains while blocking others. An attacker using Dns Rebinding can circumvent these controls by making the browser believe it's communicating with a trusted origin while actually targeting internal API endpoints.

The attack becomes particularly effective against APIs that don't implement proper authentication for internal requests. Many organizations deploy APIs on internal networks with the assumption that network isolation provides security. However, Dns Rebinding eliminates this isolation by allowing external attackers to route requests through victims' browsers.

API endpoints that handle sensitive operations like user data retrieval, administrative functions, or payment processing are prime targets. An attacker could use a victim's browser as a proxy to access these endpoints, potentially extracting data or performing unauthorized actions.

Internal APIs often lack the same security controls as public-facing services. They might rely on IP-based restrictions, simple API keys, or no authentication at all. Dns Rebinding attacks can bypass IP restrictions entirely since the request originates from what appears to be a legitimate source - the victim's browser.

Modern web applications frequently communicate with multiple backend services, each potentially running on different internal IPs. An attacker who successfully rebinds a domain to a victim's network can systematically probe these services, looking for vulnerabilities or misconfigurations.

Cloud-based APIs aren't immune either. If an API service trusts requests from specific cloud instances or VPCs, and those instances have public interfaces that can be reached through a victim's network, Dns Rebinding could provide a path to exploitation.

The attack can also target APIs that use WebSockets or Server-Sent Events for real-time communication. These persistent connections might be established to internal services that trust the originating domain, creating opportunities for data exfiltration or command injection.

API gateways and load balancers that perform origin validation are also vulnerable. If they trust requests based on the apparent origin domain without verifying the actual source IP, Dns Rebinding can trick them into forwarding requests to internal services.

Detecting Dns Rebinding requires monitoring for unusual patterns in DNS resolution and network traffic. Security teams should watch for rapid DNS changes where a domain resolves to different IP ranges within short timeframes, particularly when those IPs switch between public and private ranges.

Network monitoring tools can flag requests that appear to originate from browsers but target internal IP ranges that shouldn't be accessible from the public internet. This includes requests to RFC 1918 private address spaces (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and localhost addresses.

API security scanners like middleBrick can help identify vulnerabilities that Dns Rebinding attacks might exploit. By scanning API endpoints without credentials, middleBrick tests the unauthenticated attack surface and can detect whether APIs improperly trust requests based on origin headers or lack proper authentication for internal operations.

Prevention strategies should focus on eliminating trust based on network location or origin headers. All API endpoints should require proper authentication tokens, regardless of where the request appears to come from. This prevents attackers from exploiting trust relationships even if they successfully route requests through a victim's browser.

Implementing DNS filtering at the network level can block responses that return private IP addresses for public domains. Many modern DNS providers offer security features that detect and prevent Dns Rebinding attempts by enforcing consistent responses for a given time period.

Web application firewalls and API gateways should be configured to validate the actual source IP of requests, not just the origin header. Requests that appear to come from browsers but target internal services should be blocked or require additional verification.

Rate limiting and anomaly detection can help identify Dns Rebinding attempts by flagging unusual request patterns, such as rapid succession of requests to different internal IPs that appear to originate from the same client.

For APIs that must be accessible from internal networks, consider implementing VPN requirements or mutual TLS authentication. This ensures that only properly authenticated clients can access internal services, regardless of how they appear to the network.

Regular security testing should include Dns Rebinding scenarios. Penetration testers can simulate these attacks to verify that APIs properly handle requests that appear to come from trusted origins but actually target internal services.

MiddleBrick's continuous monitoring capabilities can help organizations maintain security over time by regularly scanning APIs for vulnerabilities that Dns Rebinding could exploit. The platform's 12 security checks include authentication testing and input validation analysis that can identify weaknesses before attackers do.

Development teams should implement proper CORS policies that restrict which origins can access APIs, combined with backend authentication that doesn't rely solely on origin validation. This defense-in-depth approach makes Dns Rebinding attacks significantly more difficult to execute successfully.