ADMIN

2023

07

2023-06-29T12:00:00

Optimiertes Rechenzentrum

PRAXIS

056

Security-Tipp

Sicherheit

Cyberangriffe

Klau von Subdomänen verhindern

Domain auf Abwegen

von Dr. Matthias Wübbeling

Veröffentlicht in Ausgabe 07/2023 - PRAXIS

Das Domain Name System ist vergleichbar mit einem Adressbuch und damit das Rückgrat der heutigen Kommunikation im Internet. Während IT-Administratoren die IPv4-Adressen ihrer wichtigsten Server noch auswendig kannten, ist DNS mit IPv6 obligatorisch geworden. Im Security-Tipp diesen Monat zeigen wir Ihnen, wie Angreifer alte DNS-Einträge dazu missbrauchen, Teile Ihrer Domain zu übernehmen, und wie Sie sich davor schützen.

Das Domain Name System (DNS) ist in sogenannte Zonen unterteilt, die jeweils in verschiedenen Verantwortlichkeiten liegen, etwa von Ihrem Unternehmen, wenn Sie sich selbst darum kümmern. Neue Einträge sind dabei schnell angelegt, viele Projekte führen dann mitunter zu sehr großen Zonen-Files. Und wie so häufig bleiben Reste von Testsetups oder Projekten in der Zone enthalten, obwohl diese gar nicht mehr verwendet werden. Im Zusammenwirken mit externen Diensten, etwa externe Hoster oder Cloudservices, bergen veraltete Einträge durchaus Gefahrenpotenzial.
Subdomain-Übernahmen
Als einfaches Beispiel an dieser Stelle kann einfach ein vergessener A- oder AAAA-Eintrag einer Subdomain auf die IP-Adresse eines Cloudproviders dienen. Das bedeutet, dass zum Ende eines Projekts alle kostenpflichtigen Dienste gekündigt werden und der Cloudserver anschließend nicht mehr zur Verfügung steht. Der Eintrag im DNS verursacht in den meisten Fällen keine expliziten Kosten, sodass eine Löschung in vielen Fällen vergessen wird. Der Eintrag zeigt damit noch immer auf die IP-Adresse des Providers. Dieser wird damit zu einem sogenannten Dangling Record, also einem in der Luft baumelnden Eintrag, zumindest solange die Ressource nicht erreichbar ist. Erhält nun ein potenzieller Angreifer die wieder freigewordene IP-Adresse für seinen eigenen Server, ist dieser auch unter der Subdomain Ihres Unternehmens erreichbar. Die angebotenen Dienste oder Inhalte stehen dann natürlich nicht mehr unter Ihrer Kontrolle.
Wenn Sie für die Ressourcen Ihrer Projekte die Angebote von Cloudprovidern verwenden, erhalten Sie dort eigene Subdomains aus der Zone des Providers. Für den Zugriff auf Ihre Dateien steht Ihnen dann eine generische Domain wie "xyz. example.com" zur Verfügung. Natürlich könnten Sie nun die IP-Adresse auflösen und diese als A-Eintrag etwa für "cloud. it-administrator.de" in Ihrem DNS hinzufügen. Da Ihr Provider in der Regel aber ein Content Delivery Netzwerk (CDN) betreibt, gibt es eben nicht nur diese eine IP-Adresse, unter der Ihre Dateien erreichbar sind, sondern noch viele andere und diese sind auch nicht immer konstant.
Das Domain Name System (DNS) ist in sogenannte Zonen unterteilt, die jeweils in verschiedenen Verantwortlichkeiten liegen, etwa von Ihrem Unternehmen, wenn Sie sich selbst darum kümmern. Neue Einträge sind dabei schnell angelegt, viele Projekte führen dann mitunter zu sehr großen Zonen-Files. Und wie so häufig bleiben Reste von Testsetups oder Projekten in der Zone enthalten, obwohl diese gar nicht mehr verwendet werden. Im Zusammenwirken mit externen Diensten, etwa externe Hoster oder Cloudservices, bergen veraltete Einträge durchaus Gefahrenpotenzial.
Subdomain-Übernahmen
Als einfaches Beispiel an dieser Stelle kann einfach ein vergessener A- oder AAAA-Eintrag einer Subdomain auf die IP-Adresse eines Cloudproviders dienen. Das bedeutet, dass zum Ende eines Projekts alle kostenpflichtigen Dienste gekündigt werden und der Cloudserver anschließend nicht mehr zur Verfügung steht. Der Eintrag im DNS verursacht in den meisten Fällen keine expliziten Kosten, sodass eine Löschung in vielen Fällen vergessen wird. Der Eintrag zeigt damit noch immer auf die IP-Adresse des Providers. Dieser wird damit zu einem sogenannten Dangling Record, also einem in der Luft baumelnden Eintrag, zumindest solange die Ressource nicht erreichbar ist. Erhält nun ein potenzieller Angreifer die wieder freigewordene IP-Adresse für seinen eigenen Server, ist dieser auch unter der Subdomain Ihres Unternehmens erreichbar. Die angebotenen Dienste oder Inhalte stehen dann natürlich nicht mehr unter Ihrer Kontrolle.
Wenn Sie für die Ressourcen Ihrer Projekte die Angebote von Cloudprovidern verwenden, erhalten Sie dort eigene Subdomains aus der Zone des Providers. Für den Zugriff auf Ihre Dateien steht Ihnen dann eine generische Domain wie "xyz. example.com" zur Verfügung. Natürlich könnten Sie nun die IP-Adresse auflösen und diese als A-Eintrag etwa für "cloud. it-administrator.de" in Ihrem DNS hinzufügen. Da Ihr Provider in der Regel aber ein Content Delivery Netzwerk (CDN) betreibt, gibt es eben nicht nur diese eine IP-Adresse, unter der Ihre Dateien erreichbar sind, sondern noch viele andere und diese sind auch nicht immer konstant.
Damit Sie nicht immer hinterher sein müssen, wenn sich die zugrundeliegende Infrastruktur bei Ihrem Provider ändert, verwenden Sie daher keine A-Einträge, sondern einen CNAME-Eintrag, der direkt auf "xyz.example.com" zeigt. Ähnlich wie eine Verknüpfung im Dateisystem, ändert sich damit die Namensauflösung für Ihre Subdomain, wenn sich die Einträge von "xyz.example.com" ändern. Damit können Sie natürlich von der Dynamik Ihres Cloudanbieters profitieren, ohne dass Sie sich selbst um die Namensauflösung kümmern müssen. Bei der tatsächlichen Verwendung Ihres eigenen Domainnamens merken Sie nicht einmal einen Unterschied, der auflösende Nameserver kümmert sich hier nämlich um alles und gibt Ihnen lediglich die IP-Adresse zurück, die Sie dann für den Zugriff auf die Dateien benötigen.
Namenszuordnung in der Cloud
Natürlich liegen Ihre Daten in der Cloud speichertechnisch neben den Daten der anderen Kunden Ihres Providers. Damit dieser beim Zugriff der Daten unterscheiden kann, welche Informationen ausgeliefert werden sollen, wird der übermittelte Hostname aus der Anfrage ausgewertet. Dieser Hostname lautet nun aber natürlich nicht mehr "xyz.example.com", sondern es handelt sich um den Namen Ihrer Subdomain, der durch den CNAME-Eintrag auf die IP-Adresse von "xyz.example.com" aufgelöst wurde.
Haben Sie nun das Projekt beendet und die Ressourcen bei Ihrem Provider wieder freigegeben, verschwindet auch die Zuordnung zu Ihrer Subdomain aus dem System des Providers. Mit dem Hostnamen Ihrer Subdomain ist nun also kein Zugriff mehr möglich. Der für die DNS-Zone verantwortliche Admin wird in vielen Fällen allerdings nicht informiert, sodass der CNAME-Eintrag erst einmal weiter besteht – die Subdomäne "xyz" Ihres Providers ist so lang und zufällig gewählt, dass diese vermutlich niemandem ein zweites Mal zugeteilt wird.
Hat nun ein Angreifer mitbekommen, dass Sie Ihren Cloudprovider über den CNAME-Eintrag Ihrer Domain anbinden – etwa, indem er die IP-Adresse aus der Auflösung Ihrer Subdomain Ihrem Provider zuordnet –, könnte er versuchen, für seinen eigenen Account bei demselben Provider den ursprünglich verwendeten Hostnamen aus der Subdomain Ihres Unternehmens zu hinterlegen. Je nachdem, welchen Provider Sie verwenden, findet nämlich keine Überprüfung statt, ob der hinterlegte Name auch tatsächlich genutzt werden darf, eine Nutzung ist ja faktisch nur dann möglich, wenn ein CNAME-Eintrag im DNS hinterlegt ist.
Angriff über Bande
Natürlich erhält der Angreifer für seine Projekte nicht dieselbe Subdomain "xyz. example.com", wie Sie für Ihre Projekte, sondern vielleicht "zyx". Tatsächlich gab es aber für Ihren Eintrag "xyz" auch nie einen richtigen A-Eintrag in der DNS-Zone Ihres Providers. Über sogenannte Wildcard-Einträge (*.example.com) werden einfach alle angefragten Subdomains auf die verfügbaren IP-Adressen des CDNs Ihres Providers aufgelöst. Die eigentliche Zuordnung zu den Daten geschieht bei Ihrem Provider wie zuvor dargestellt über den mitgelieferten Hostnamen der Anfrage – und dieser ist nun eben für den Account des Angreifers hinterlegt.
Mit den im Projekt des Angreifers verfügbaren Daten, die natürlich über Ihre Firmendomain abzurufen sind, kann der Angreifer nun Informationen im Namen Ihrer Firma verbreiten, aber auch gezielt Ihr Unternehmen oder Ihre Kunden angreifen, indem er etwa über eine Schwachstelle in einer Webanwendung manipulierte Inhalte von dieser Domain einbindet. Durch die Verwendung Ihrer Subdomain geben bei diesem Setup nämlich auch die Same-Origin-Policies moderner Webbrowser grünes Licht, sodass mögliche aktive Inhalte im Kontext Ihres Webangebots ausgeführt werden.
Neben den auf hinterlegten Dateien basierenden Angriffen können dieselben Techniken natürlich auch für den Zugriff durch andere Dienste zum Einsatz kommen. CNAME-Einträge lassen sich ja für beliebige Arten von Servern anlegen, also auch für die hinterlegten Namen von NS- oder MX-Einträgen. Damit kann ein Angreifer dann sogar einen ganze Subdomain kontrollieren oder für den Versand und für den Empfang von E-Mails eine Subdomain Ihres Unternehmens verwenden.
Gegenmaßnahmen ergreifen
In einer idealen Welt würden die Administratoren der DNS-Zone natürlich unmittelbar nach Beendigung des Projekts von den Kollegen informiert und entfernen daraufhin den CNAME-Eintrag. Damit wären Sie bereits auf der sicheren Seite. Doch leider stellt sich die Realität meist anders dar. Damit Sie als IT-Verantwortlicher die aktiven und passiven Einträge überprüfen können, stehen Ihnen glücklicherweise einige Tools zur Verfügung.
Ein oft referenziertes und auch heute noch aktiv gepflegtes Open-Source-Werkzeug ist der dnsReaper [1] von PunkSecurity. Sie können die Software aus dem verlinkten Git-Repository herunterladen und auf Ihrem System installieren. Die Macher bieten aber auch ein fertiges Image für die Nutzung im Docker-Container an. Dann müssen Sie sich nicht selbst um die Laufzeitumgebung und etwaige Abhängigkeiten kümmern, sondern können dnsReaper direkt verwenden. Um die möglichen Optionen von dnsReaper anzuzeigen und dabei das Docker-Image schon einmal herunterzuladen, verwenden Sie einfach das folgende Kommando:
docker run -ti --rm punksecurity/dnsreaper --help
In der Ausgabe können Sie sich schon einmal etwas orientieren und mögliche Argumente für Ihren Anwendungsfall identifizieren. Natürlich benötigt dnsReaper eine Möglichkeit, aller existierenden Einträge in Ihrer Zone zu überprüfen. Eine sogenannte Blackbox-Überprüfung, also ohne weiteres Wissen über den Aufbau Ihrer DNS-Zone, ist damit also nicht möglich. Zwar gibt es Techniken, unterschiedliche Einträge im DNS zu ermitteln, dabei werden Sie aber nicht alle tatsächlichen Einträge erhalten.
Für eine umfassende Prüfung exportieren Sie also bestenfalls Ihre gesamte Zone vom DNS-Server und stellen dnsReaper diese zur Verfügung. Wenn diese in einem Bind-DNS kompatiblen Format verfügbar ist, kann die Software diese direkt nutzen. Um die Zonendatei mit dem Namen "domain.zone" im Docker-Container zu verwenden, müssen Sie diese als Volume in das Image einbinden. Starten Sie diesen nun wie in folgendem Kommando:
docker run -it --rm -v ./domain.zone:/domain.zone punksecurity/dnsreaper bind --bind-zone-file /domain.zone
Alternativ können Sie auch von dnsReaper unterstützte Provider wie AWS oder Azure verwenden, indem Sie Ihre Zugangsschlüssel beim Aufruf mit übergeben. Auch ein direkter Zonentransfer von einem DNS-Server ist möglich, benötigt aber Eingriffe in die Konfiguration des Servers, um den Zonentransfer zu erlauben.
Fazit
Schlecht gepflegte DNS-Einträge sind gefährlicher, als es zunächst den Anschein haben mag. Angreifer können sogenannte Dangling Records dazu verwenden, um im Namen Ihres Unternehmen schadhafte Aktionen durchzuführen. Mit dnsReaper haben Sie ein Werkzeug an der Hand, das Sie bei der Beobachtung Ihrer DNS-Einträge unterstützt.
(dr)
Link-Codes
[1] dnsReaper: https://github.com/punk-security/dnsReaper