DNSpionage: Wenn der Registrar zum Angriffspfad wird
Zusammenfassung
Brian Krebs verfolgt die DNSpionage-Kampagne über passive DNS-Daten und zeigt, dass Angreifer Ende 2018 die DNS-Einträge von mehr als 50 Behörden und Unternehmen im Nahen Osten umlenkten. Der Weg führte über gestohlene Zugänge bei Registraren, mit denen die Angreifer per EPP Änderungen direkt an die Registries schickten. Netnod und Packet Clearing House schildern, wie weit DNSSEC sie schützte und wo es versagte.
Vom Registrar zum gültigen Zertifikat
Wer den Zugang zum Registrar hat, kann die Nameserver einer Domain ändern. Die Angreifer lenkten Mail- und VPN-Namen auf eigene Server in Europa und ließen sich kurz darauf Zertifikate bei Comodo oder Let's Encrypt ausstellen. Domainvalidierung prüft nur, wer die Domain gerade kontrolliert. Abgefangene Anmeldungen sahen für die Nutzer daher korrekt verschlüsselt aus.
Bei PCH lief jede Umleitung nur etwa eine Stunde. Das genügte, weil Smartphones ständig neue Mails abrufen und dabei ihre Zugangsdaten senden.
Was DNSSEC leistete und was nicht
Netnod erlebte drei Angriffe. Die ersten beiden trafen Server ohne DNSSEC. Beim dritten schalteten die Angreifer DNSSEC über den Registrar-Zugang kurz ab, holten sich Zertifikate und schalteten es wieder ein. Beim eigentlichen Umleiten vergaßen sie, es erneut abzuschalten, und der Angriff lief ins Leere.
PCH validiert DNSSEC auf der gesamten eigenen Infrastruktur, und daran scheiterte der Angriff fast vollständig. Erwischt wurden nur zwei reisende Mitarbeiter: Captive Portals in Hotels zwangen ihre iPhones auf fremde DNS-Server, und in dieser Zeit holten die Mailprogramme neue Nachrichten ab.
Die Reaktion der US-Regierung
CISA erließ am 22. Januar 2019 die Notfallanweisung ED 19-01. Bundesbehörden mussten binnen zehn Werktagen ihre DNS-Einträge prüfen, die Passwörter aller DNS-Konten ändern, dort Mehrfaktor-Anmeldung einführen und Certificate-Transparency-Logs auf nicht beantragte Zertifikate überwachen. SMS als zweiten Faktor empfahl CISA ausdrücklich nicht.
Ideen
- Gestohlene Registrar-Zugänge umgehen alle Schutzmaßnahmen auf den eigenen Servern.
- Über EPP gelangen Änderungen vom Registrar direkt in die Registry.
- Wer die Domain kontrolliert, erhält domainvalidierte Zertifikate ohne weitere Prüfung.
- Einstündige Umleitungen reichen, weil Mailprogramme ständig Zugangsdaten senden.
- Validierendes DNSSEC stoppte bei PCH fast den gesamten Angriff.
- Captive Portals zwingen Geräte auf fremde Resolver und umgehen so die DNSSEC-Validierung.
- Keiner von drei kommerziellen DNS-Überwachungsdiensten bemerkte die Umleitungen bei PCH.
Einsichten
- Die Domainverwaltung gehört zur Sicherheitsgrenze jeder Organisation.
- Ein gültiges Zertifikat belegt nur, wer die Domain bei der Ausstellung kontrollierte.
- DNSSEC schützt die Daten, aber nicht vor jemandem, der die Delegation beim Registrar ändern kann.
Zitate
- The two people who did get popped, both were traveling and were on their iPhones, and they had to traverse through captive portals during the hijack period. (Bill Woodcock)
- Luckily for us, they forgot to remove that when they launched their man-in-the-middle attack. (Lars Michael Jogbäck)
Fakten
- Cisco Talos beschrieb DNSpionage erstmals am 27. November 2018.
- Laut APNIC hatten damals nur etwa 20 Prozent der großen Netze und Websites DNSSEC aktiviert.
- PCH zählte vier Angriffe zwischen dem 13. Dezember 2018 und dem 2. Januar 2019.
- PCH fragt die eigene DNS-Infrastruktur seitdem mehrmals pro Stunde ab und alarmiert bei jeder Änderung.
- Netnod hatte zuvor nicht alle Domains mit einer Domain-Sperre beim Registrar gesichert.
Referenzen
- Brian Krebs: A Deep Dive on the Recent Widespread DNS Hijacking Attacks
- Cisco Talos: DNSpionage.
- FireEye und CrowdStrike: technische Indikatoren der Kampagne.
- Netnod und Packet Clearing House: betroffene Infrastrukturbetreiber.
- CISA: Emergency Directive 19-01, Mitigate DNS Infrastructure Tampering (2019)
- RFC 5730: Extensible Provisioning Protocol (EPP) (2009)
- RFC 4033: DNS Security Introduction and Requirements (2005)
- RFC 6962: Certificate Transparency (2013)
Kritik
- Krebs beschreibt DNSSEC so, als würden DNS-Anfragen signiert und ein Nameserver prüfe, ob ein Eintrag unterwegs verändert wurde. Tatsächlich signiert der Zonenbetreiber die Antworten, und ein validierender Resolver prüft die Signaturkette bis zur Root (RFC 4033). Genau deshalb half DNSSEC nicht gegen Angreifer, die beim Registrar die Delegation selbst ändern konnten.
Bemerkungen
- Die Zuordnung zu Iran stammt von Sicherheitsfirmen und Bill Woodcock; der Beitrag spricht von „suspected Iranian hackers“.
Empfehlungen
- Sichere Registrar-Konten mit phishingresistenter Mehrfaktor-Anmeldung und Registry Lock.
- Überwache NS-, MX- und A-Einträge selbst mehrmals pro Stunde statt einmal täglich.
- Lass dich über neue Zertifikate deiner Domains aus Certificate-Transparency-Logs benachrichtigen.
- Signiere Zonen mit DNSSEC und validiere auf den eigenen Resolvern.
Links zur Originalquelle und zum Webarchiv öffnen einen neuen Tab.