DNS Rebinding - Same-Origin-Policy-Bypass via DNS - Definition & Erklärung

DNS Rebinding nutzt einen subtilen Fehler im Browser-Sicherheitsmodell: Die Same-Origin-Policy prüft Origin anhand des Hostnamens - nicht anhand der IP-Adresse. Ein Angreifer der seinen DNS-TTL auf Sekunden setzt, kann nach dem Browser-Lookup die IP-Adresse ändern. Der Browser sieht immer noch “attacker.com” als Origin, spricht aber mit einem internen Gerät.

Angriffsprinzip

Same-Origin-Policy (SOP) - Grundlage des Angriffs:

Die SOP erlaubt JavaScript auf http://attacker.com NICHT, Responses von http://victim.com zu lesen. Entscheidend: Die SOP prüft den Hostnamen, nicht die IP-Adresse.

http://attacker.com → 1.2.3.4       ← erlaubt (eigene IP)
http://attacker.com → 192.168.1.1   ← AUCH erlaubt?!
→ Browser sieht "attacker.com" in beiden Fällen!

DNS Rebinding Ablauf:

Opfer besucht http://attacker.com → Browser löst auf: attacker.com = 1.2.3.4 (echte IP) → JavaScript wird geladen, TTL ist kurz (5-10 Sekunden)
TTL läuft ab → Angreifer-DNS-Server ändert Eintrag: attacker.com = 192.168.1.1 (interner Router des Opfers!)
JavaScript sendet Request an attacker.com → Browser: “attacker.com ist Same-Origin, kein Problem!” → Neuer DNS-Lookup: attacker.com = 192.168.1.1 → Request geht an internen Router → Angreifer liest Response!

Voraussetzungen:

Opfer besucht Angreifer-Website (1-2 Minuten genug!)
Opfer hat interne Dienste ohne Authentifizierung
DNS-TTL kurz genug (Browser cachen DNS unterschiedlich lang!)

Angriffsziele

1. Home-Router-Admin-Interface

192.168.1.1:80 / 192.168.0.1:80
Standard-Interface ohne Auth oder Default-Credentials
DNS-Rebinding → Angreifer übernimmt Router
Kann: DNS-Server ändern (permanentes DNS-Hijacking!), Port-Forwarding, Firewall

2. Smart Home / IoT-Geräte

IP-Kameras: Videostream abrufbar!
Smart-TVs: DIAL-Protokoll (YouTube/Netflix App-Launch)
3D-Drucker: Drucker-Befehle senden (Prusa, OctoPrint auf 5000/TCP)
Philips Hue Bridge: Lampen steuern
Amazon Echo (lokale Befehle)

3. Entwickler-Workstations (localhost)

Lokale Entwicklungs-Server: localhost:3000, localhost:8080
Docker-Container ohne Bind-to-Localhost
Jenkins, Gitlab: oft auf localhost ohne Auth während Entwicklung
Kubernetes-Dashboard: localhost:8001 (kubectl proxy)
Cloud-Metadata: 169.254.169.254 (wenn auf Cloud-VM entwickelt wird!)

4. Cloud-Metadata via DNS-Rebinding

Wenn das Opfer auf einer Cloud-VM arbeitet:

Rebind zu 169.254.169.254
AWS IMDS: IAM-Credentials abrufbar!
GCP Metadata: alle Service-Account-Tokens!

5. Intranet-Webservices

HR-Systeme, Wiki, Ticketing ohne VPN-Anforderung
Interne APIs mit IP-Whitelisting statt Auth (“von intern darf jeder zugreifen” - falsch!)

Praxis-Exploit-Tools

Singularity of Origin (Joe Linn)

Automatisches DNS Rebinding Framework
GitHub: nccgroup/singularity
Beinhaltet: Manager-Server + DNS-Server + Angriffsserver
Konfigurierbare Rebinding-Strategie: Timing, Ziel-IP

rebind.it (Proof of Concept)

Online-Tool für einfaches DNS-Rebinding-Testing
Eigene Domain: <ip>.rebind.it → rebindet zu <ip>

DNS-Server-Konfiguration für Rebinding (Demo)

; Zone: attacker.com
; TTL: 5 ← Sehr kurz!

; Phase 1: echte IP
attacker.com. 5 IN A 1.2.3.4

; Nach Trigger wechseln zu:
attacker.com. 5 IN A 192.168.1.1

Nachweis im Pentest:

Zeigen dass interner Dienst über Angreifer-Domain erreichbar
Response-Inhalt (HTML, JSON) aus internem Dienst in Browser-JS lesen
Keine Credentials nötig wenn Dienst keine Auth hat!

Schutzmaßnahmen

1. DNS-Rebinding-Filter im Resolver/Router

Private IP-Bereiche in DNS-Antworten für öffentliche Domains blocken (RFC 5735: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).

# Pi-hole / AdGuard Home Konfiguration:
rebind-domain-ok=  # Leer = alle privaten IPs geblockt

# dnsmasq (Router-Firmware):
stop-dns-rebind
rebind-localhost-ok  # Nur 127.0.0.1 erlaubt ausnahmsweise

Fritz!Box: DNS-Rebind-Schutz ist standardmäßig aktiviert!

2. Browser-interne Schutzmechanismen

Chrome Private Network Access (PNA):

Blockiert Requests von öffentlichen auf private IPs (nach Zustimmung)
Preflight-Request mit Access-Control-Request-Private-Network Header
Interne Server müssen explizit mit Access-Control-Allow-Private-Network: true antworten
Status (2024): Progressiv eingeführt in Chrome

Firefox: private-network-access-respects-permission (experimentell)

3. Host-Header-Validierung auf internen Diensten

Interner Dienst prüft: kommt Anfrage von erwartetem Host? Wenn Host: attacker.com an internem Service → BLOCK!

server {
  listen 8080;
  if ($host !~ ^(localhost|192\.168\.1\.100)$) {
    return 421;  # Misdirected Request
  }
}

4. Authentifizierung auf ALLEN internen Diensten

Keine Dienste “weil intern = vertrauenswürdig” ohne Auth!
Selbst für interne Tools: Basic Auth, Token-Auth, OAuth
DNS-Rebinding mit Auth: Angreifer-JS kann keine Credentials mitschicken
Oder: SameSite=Strict Cookies + CSRF-Token

5. Netzwerksegmentierung

IoT-Geräte in separatem VLAN (192.168.10.0/24)
Büro-PCs können NICHT auf IoT-VLAN (Firewall-Rule)
DNS-Rebinding kann nicht direkt IoT attackieren wenn Firewall blockt

6. DNSSEC - nicht hilfreich hier

DNSSEC signiert Antworten vom autoritativen Server. Das Problem liegt aber beim angreifer-kontrollierten DNS-Server für seine eigene Domain - DNSSEC hilft hier NICHT gegen DNS-Rebinding!