Wie offene Zonentransfers Ihr internes Netzwerk offenlegen

Zusammenfassung: Ein DNS-Zonentransfer (AXFR) sollte eigentlich nur zwischen dem primären und den sekundären Nameservern einer Domain stattfinden. Bleibt er jedoch für jeden offen zugänglich, liefert eine einzige Abfrage eine vollständige Liste aller Hosts in dieser Zone. Bei aktuellen Untersuchungen stellte Red Sift fest, dass Zonen in mehreren Beständen interne Hostnamen, unverschlüsselte VoIP-Infrastruktur und vollständige Netzwerkkarten an jeden herausgaben, der danach fragte. Keine dieser Organisationen hatte vor, das offenzulegen. Es hat sich einfach so angesammelt.

Nicht verpassen: Unser erster Blogbeitrag dieser Reihe zum Umgang mit verwaisten DNS-Einträgen.

• Ein offener Zonentransfer liefert jeden Hostnamen einer Zone in einer einzigen Abfrage – ohne Scannen oder Raten erforderlich
• Übergeordnete Domains sind oft gut abgesichert, während eine delegierte Subdomain, häufig im Besitz eines anderen Teams, weit offen bleibt
• Was offengelegt wird, ist nicht abstrakt. Es handelt sich um SIP-Endpunkte, Entwicklungsumgebungen und interne Namenskonventionen, auf die ein Angreifer sofort reagieren kann
• Red Sift ASM entdeckt und überwacht diese Assets kontinuierlich, auch solche, von deren Existenz Ihr Team nichts weiß

Ein DNS-Zonentransfer, oder AXFR, ist der Mechanismus, mit dem ein primärer Nameserver seine vollständige Zonendatei an einen sekundären Nameserver repliziert. Das ist ein normaler, notwendiger Bestandteil des DNS-Betriebs. Zwei Server benötigen dieselben Einträge, also kopiert einer die gesamte Zone zum anderen.

Das Problem ist, dass AXFR nicht mit Blick auf das moderne Internet entwickelt wurde. Sofern ein Nameserver nicht explizit so konfiguriert ist, dass Transfers auf vertrauenswürdige IP-Adressen beschränkt werden, antwortet er auf eine Transferanfrage von jedem. Führt man dig axfr @nameserver domain.com gegen einen falsch konfigurierten Server aus, erhält man jeden Eintrag dieser Zone zurück. Jede Subdomain. Jeden internen Hostnamen. Jede IP-Adresse, die mit diesen Hosts verknüpft ist.

Man muss keine Subdomains per Brute-Force ermitteln oder IP-Bereiche scannen, um eine Karte der Infrastruktur eines anderen zu erstellen. Man fragt einfach danach.

Die meisten Sicherheitsteams, die sich überhaupt damit befasst haben, haben Transfers auf ihrer primären Domain abgesichert. Das ist die Zone, an die jeder denkt, wenn er sie überprüfen soll.

Was dabei übersehen wird, ist die Delegation. Wenn eine Domain eine Subdomain an einen anderen Nameserver abgibt – vielleicht für ein bestimmtes Produkt, ein regionales Büro oder eine Plattform, die einem anderen Team gehört –, läuft diese delegierte Zone mit ihrer eigenen Konfiguration. Niemand überprüft sie erneut anhand der Standards der übergeordneten Domain, weil niemand sie als separate Zone betrachtet. Sie ist einfach "Teil der Domain".

Der eigentliche Knackpunkt ist der Umfang. Unsere Analyse fand dasselbe Muster an Sicherheitslücken bei mehreren Organisationen. Nehmen wir ein Telekommunikationsunternehmen. Deren übergeordnete Nameserver waren sauber: Transfers eingeschränkt, Einträge aktuell, nichts zu bemängeln. Aber eine delegierte Subdomain, Jahre zuvor für eine Videokonferenzplattform eingerichtet, erlaubte weiterhin offene Zonentransfers für sechs Hostnamen.

Niemand hat das absichtlich so eingerichtet. Eine Subdomain wird für ein Projekt delegiert, das verantwortliche Team wechselt zu anderen Aufgaben, und die Konfiguration wird nie wieder überprüft. Es hat sich einfach so ergeben.

Ein einziges dig axfr gegen diese delegierte Zone lieferte:

• Die internen Hostnamen von Session Border Controllern, die an zwei getrennten Standorten liefen und über unverschlüsseltes SIP kommunizierten
• Eine Reihe interner Hostnamen, die direkt bestimmten Geschäftsfunktionen zugeordnet waren, wodurch die interne Namenskonvention sofort lesbar wurde
• Eine Entwicklungsumgebung, die sich innerhalb einer ansonsten produktiven Zone befand
• Eine SOA-Seriennummer, die zeigte, dass die Zone seit 2019 nicht mehr angefasst worden war

Nichts davon erfordert, dass ein Angreifer irgendetwas Cleveres tut. Es ist eine Zielliste, kostenlos übergeben. Unverschlüsseltes SIP verrät genau, wo man einen Anruf abfangen kann. Eine Entwicklungsumgebung innerhalb einer produktiven Zone verrät genau, wo die Kontrollen wahrscheinlich schwächer sind. Ein zuletzt 2019 aktualisierter Eintrag verrät, dass niemand mehr hinschaut.

Eine separate Untersuchung, diesmal bei einem SaaS-Unternehmen, zeigte eine andere Variante derselben Grundursache. Ein Netzwerktechniker hatte kürzlich die Verantwortung für eine Infrastruktur übernommen, die über Jahre unter verschiedenen Verantwortlichen gewachsen war. Er kannte einige der Probleme in dem Teil der Zone, den er geerbt hatte. Aber nicht alle.

Ein dig axfr lieferte fast 55 Hosts, jeder mit einer auflösbaren IP-Adresse, in einer einzigen Antwort. Das ist kein unvollständiges Bild. Das ist eine nahezu vollständige Karte eines bedeutenden Teils der Unternehmensumgebung, übergeben in einer einzigen Abfrage an jeden, der daran dachte, danach zu fragen.

Keiner der beiden Fälle beinhaltete einen ausgeklügelten Angriff. Beide beinhalteten eine standardmäßige DNS-Abfrage, die eigentlich hätte verweigert werden müssen – und es nicht wurde.

Ein offener Zonentransfer ist kein theoretisches Risiko, das nur in einer Compliance-Tabelle existiert. Es ist Aufklärung, für den Angreifer erledigt, ohne dass ihm Kosten entstehen.

Sobald jemand eine vollständige Liste Ihrer Hostnamen und IP-Adressen hat, muss er nicht mehr raten, wo er suchen soll. Er weiß, welcher Host was betreibt. Er weiß, wo eine Entwicklungsumgebung möglicherweise schwächer gepatcht ist. Er weiß, welche Infrastruktur den Sprachverkehr abwickelt und ob dieser verschlüsselt ist. Jedes in diesem Beitrag beschriebene Fehlerbild – ein uneingeschränkter Transfer, eine unüberwachte Delegation, ein veralteter Eintrag, den niemand mehr überprüft hat – weist einem Angreifer genau das Asset, das als Nächstes ins Visier genommen werden sollte.

Das ist auch der Grund, warum punktuelle Überprüfungen nicht ausreichen. Die Telekommunikationszone hatte vermutlich irgendwann eine Überprüfung durchlaufen. Die Delegation kam danach einfach nie wieder zur Sprache. DNS-Bestände stehen nicht still. Neue Subdomains werden delegiert, neue Teams übernehmen die Verantwortung, und Konfigurationen verändern sich schleichend, ohne dass jemand das bewusst entscheidet.

Testen Sie jeden Nameserver, für den Sie verantwortlich sind, mit:

Wenn eine vollständige Zonenliste zurückgegeben wird, statt die Anfrage abzulehnen, erlaubt dieser Server uneingeschränkte Transfers. Beheben Sie das, indem Sie Transfers explizit auf eine benannte Liste vertrauenswürdiger sekundärer IP-Adressen in Ihrer DNS-Server-Konfiguration beschränken – egal ob es sich um BIND, PowerDNS oder die entsprechende Einstellung Ihres DNS-Anbieters handelt.

Gehen Sie dann über die übergeordnete Domain hinaus. Listen Sie jede Subdomain auf, die an einen anderen Nameserver delegiert wurde, und testen Sie jede davon auf dieselbe Weise. Wenn Sie keine aktuelle Liste haben, was delegiert wurde und an wen, ist genau das der eigentliche Befund. Sie haben dann noch kein Zonentransfer-Problem, sondern ein Sichtbarkeitsproblem – und der Zonentransfer ist nur der Ort, an dem es zuerst zutage tritt.

Das ist schwer zu erkennen, wenn man nur gelegentlich die eigene Domain überprüft, denn die Sicherheitslücke liegt in der Regel nicht bei der Domain, die Ihr Team aktiv verwaltet. Sie liegt bei der, die vor drei Jahren delegiert wurde und dann leise vom Radar aller verschwunden ist.

Red Sift ASM entdeckt und inventarisiert kontinuierlich Ihre extern zugänglichen Assets, einschließlich derer, von deren Existenz Ihr Team noch nichts weiß, indem es sich direkt mit Ihren Registraren und verwalteten DNS-Anbietern verbindet, statt sich auf eine manuelle Liste zu verlassen. Es überwacht die DNS-Konfiguration in Ihrem gesamten Bestand fortlaufend, nicht als einmalige Prüfung, sodass eine delegierte Subdomain, die aus der Richtlinie herausdriftet, markiert statt vergessen wird. Und weil es Ihnen zeigt, was ein Angreifer von außen sieht, unterliegen Drittanbieter- und delegierte Infrastruktur derselben Kontrolle wie die Assets, die Ihr Team direkt eingerichtet hat.