Im folgenden Szenario wähle ich den klassischen DNS-Rebinding-Angriff, der eine Full-Bogon-Adresse (also ein Präfix, das im globalen BGP-Routing nie auftaucht) als Sprungbrett benutzt. Er illustriert exemplarisch, weshalb ein Resolver zwingend die Team-Cymru-Bogon-Liste oder wenigstens private-address:-Filter braucht.
| Phase | Abläufe im Detail | Warum es klappt (ohne Bogon-Filter) |
|---|---|---|
| 1) Domänen-Vorbereitung | Angreifer registriert evil-widget.com und setzt einen kurzen TTL (z. B. 30 s). Zunächst zeigt der A-Record auf einen legitimen, öffentlich routbaren Host (z. B. 203.0.113.42). | Der Resolver erkennt keinen Betrug; die Antwort ist tadellos signiert (DNSSEC) und wird weitergereicht. |
| 2) Opfer besucht Website | User klickt einen Phishing-Link oder eine Werbeanzeige. Browser lädt JavaScript von evil-widget.com. | Noch alles unauffällig, keine Endpoint-Alarmierung. |
| 3) TTL läuft ab – Record-Flip | Angreifer ändert den A-Record auf 10.0.0.1 (privates RFC 1918-Netz) oder auf 240.0.0.7 (historisches Class-E-Reservat, Teil der Fullbogons). | Der ungeschützte Resolver fragt erneut beim autoritativen NS an und erhält die neue Antwort. Ohne private-address:-Prüfung hält er sie für legitim. |
| 4) Same-Origin-Bypass | Das zuvor geladene Skript darf weiterhin XMLHttpRequests an evil-widget.com schicken (gleiche Origin). Jetzt verweist der Name aber auf 10.0.0.1 – oft die Management-IP des lokalen Routers oder ein internes API-Gateway. Browser leitet die Anfrage ins LAN. | DNS-Rebinding nutzt die mangelnde Trennung zwischen Namens- und Adressraum; Browser verlassen sich auf den Resolver. |
| 5) Seitwärtsbewegung / Exfiltration | Skript liest Konfig-Dateien des Routers, führt CSRF-Befehle aus oder tunnelt Daten über JSONP nach draussen. | Der Verkehr bleibt HTTP/HTTPS – alle klassischen IDS-Signaturen greifen zu spät; der Angriff fand im Kopf des Resolvers statt. |
| 6) Spurenverwischung | Nach wenigen Minuten setzt der Angreifer den A-Record wieder auf die ursprüngliche IP. Die nächste Prüfung wirkt sauber. | Forensiker sehen nur kurze Lebens-Signale zu einer privaten IP, häufig gar nicht geroutet oder geloggt. |
Ergebnis: Kein Paket mit der Bogon-Adresse muss je das Internet durchqueren; der Angriff spielt sich ausschliesslich im DNS-Antwort-Paket des autoritativen Servers ab. Genau deshalb genügt der ungeschützte Resolver als Einfallstor.
Varianten desselben Prinzips
| Technik | Nutzen für den Angreifer | Quellen |
|---|---|---|
| Source-IP-Spoofing mit Bogons | Botnet sendet DNS-Anfragen an offene Resolver, fälscht eine Fullbogon-Absenderadresse – Antwort flutet das Rückwegs-Interface und verschleiert Herkunft (DDoS-Reflexion). | NIST DDoS-Guideline (nvlpubs.nist.gov); Internet Society Spoofing-Paper (internetsociety.org) |
| Route Leak / BGP-Hijack | Fehlkonfigurierter ISP announced plötzlich 240.0.0.0/4, zieht riesige Traffic-Mengen ab; Resolver ohne Bogon-Liste könnte die Anomalie nicht detektieren. | Spoof-Detection-Studie (prichter.com) |
| DNS-Rebinding-Bypass-Toolkit | Frameworks wie Singularity tauschen A-Records spielerisch gegen 127.0.0.1 oder 169.254.169.254 (Cloud-Metadata-Service) aus – Bogon-Filter heben den Joker aus. | Rebinding-Bypass-Repo (github.com) |
Abwehrmöglichkeiten
private-address:-Stanzas in Unbound für alle Fullbogons (Team-Cymru-Feed) – Response wird verworfen, bevor sie den Client erreicht.response-ip:-Regeln für FireHOL-Netze – stoppt Wechsel auf aktuell missbräuchliche, aber routbare Subnetze.- RPZ oder AdGuard-Filter für ThreatFox-Domains – verhindert erste Kontaktaufnahme mit C2-Infrastruktur.
Wer Bogons aussperrt, versieht sein DNS mit einem integrierten Brennglas – Angriffe werden sichtbar, bevor sie Flammen schlagen.
Damit ist der Rebinding-Trick ebenso passé wie Spoof-basierte Reflexionen; der Resolver wird vom unscheinbaren Datenkurier zur ersten Verteidigungslinie.