In diesem Blogpost werden wir einen einfachen Informationsleak vorstellen, nämlich unautorisierte AXFR Anfragen. Diese können genutzt werden, um die DNS Informationen eines bestimmten Zieles auszulesen. Nicht selten werden so als intern/privat klassifizierte DNS Einträge aufgedeckt.
Wir haben die Alexa Top 1 Millionen Webseitenliste auf dieses Problem untersucht und sind dabei zu einem ernüchternden Ergebnis gekommen.
Was ist AXFR?
Asynchronous Xfer Full Range ist ein Mechanismus von DNS Systemen um DNS-Zonen von eingem sogenannten Master (primären) DNS-Server zu den Slaves (sekundären) DNS-Servern zu übermitteln. Dabei sendet ein Slave eine AXFR-Anfrage zu dem Master Server welcher mit den entsprechenden Informationen zu der angefragten DNS Zone antwortet.
Was kann dabei schief gehen?
Wenn der Master Server nicht kontrolliert, ob die Anfrage aus einer berechtigten Quelle stammt, so beantwortet er “blind” Anfragen. Bei einer Falschkonfiguration kann also jeder Anfragen stellen und damit beliebige Zonen herunterladen. Diese Zonen Informationen sollten allerdings, wie oben bereits erwähnt, nur den sekundären Servern zugänglich sein.
Nun könnte man meinen, dass DNS ohnehin offen abrufbar ist.
1 2 3 4 5 6 | |
Wir fragen zunächst Informationen über die Namenserver von google.com an. Es gibt vier Namenserver, welche jeweils für die Domain Anfragen entgegennehmen.
1 2 3 4 5 6 7 8 9 10 11 12 13 | |
Nun haben wir den vierten Namenserver (ns4.google.com) per Anfrage darum gebeten uns alle A (IPv4) Einträge aufzulisten. Diese Einträge verweisen allesamt auf google.com.
Das gleiche Vorgehen lässt sich auch auf andere Anfragemethoden von DNS (AAA/TXT/MX/CNAME/…) übertragen. Dazu ist jedoch stets die Kenntnis der DNS Einträge von Nöten. Es ist beispielsweise nicht möglich eine Anfrage wie: “Liste mir alle Subdomains von google.com in deiner Zone” auszuführen. Es gibt allerdings Tools, etwa Subbrute welche durch ausprobieren (bruteforcing) DNS Einträge erraten.
Aus dem Aspekt der Sicherheit sind die erlangten Informationen sehr viel wert, da dadurch mögliche Endpunkte gefunden werden können, die ungeschützt oder sogar verwundbar sind.
Zum Beispiel könnten Monitoring-Systeme unter der Subdomain “`monitoring.internal.server1.domain.tld““ oder jeder beliebigen anderen gefunden werden. Einige Admins gehen vielleicht davon aus, dass eine zusätzliche Schutzmaßnahme mittels Autorisierung nicht von Nöten sei, da niemand die Subdomain kennt, allerdings ist das, wie wir nun wissen, weit gefehlt.
Wenn einer der Namensserver falsch konfiguriert ist, kann der Angreifer eine AXFR-Anfrage schicken, die gesamten Zoneninformationen sammeln und dadurch möglicherweise Zugriff auf das Zielsystem erlangen.
Testen der Alexa Top 1 Million
Wir wollten wissen, wie viele falsch konfigurierte Namensserver sich wohl unter den Alexa Top 1 Million befinden und haben dazu ein kleines Pythonskript implementiert, welches auf GitHub zu finden ist.
Das Ergebnis war ein wenig erstaunlich:
- 132854 erfolgreiche AXFR Anfragen konnten durchgeführt werden
- 72401 einzelne Domain waren betroffen
- 48448 einzelne Namesserver waren betroffen
Einige Domains hatten sogar gleich mehere fehlkonfigurierte Namensserver, das ist möglich da Namesserver mehrere Domains verwalten können und umgekehrt auch eine Domain-Zone auf mehreren Nameservern (z.B. Master und Slave-Server) liegen kann.
Im Schnitt hat dennoch jede 20te Webseite der Alexa Top 1 Millionen einen fehlerhaft konfigurierten Webserver.
TLDs nach betroffenen Domains:
TLDs nach betroffenen Namensservern:
Wir waren sehr enttäuscht darüber, dass einige recht bekannte und auch weniger bekannte Webhoster und IT-Unternehmen fehlerhaft konfigurierte Namensserver produktiv betreiben. Einige zufällige Stichproben haben gezeigt, dass sowohl Informationen der Unternehmen als auch die der Kunden dadurch ohne weitere Autorisierung zugänglich waren. (Genau wie im oben beschriebenen Szenario).
Die sonstigen Webseiten wiesen verschiedene Themen auf, von einigen (großen) Nachrichtenseiten über Shopping Seiten bis zu hin kleinen privaten Webseiten war alles dabei.
Behebung der Schwachstelle
Der einfachste Weg diese Schwachstelle zu beheben ist eine Überprüfung der DNS Server Konfiguration. Es muss sichergestellt sein, nur sekundäre Nameserver vom primären Nameserver AXFR durchführen können und dass die ungeordneten Server keine AXFR erlauben.
Wenn Sie überprüfen möchten, ob ihre Nameserver falsch konfiguriert sind, dann können sie den folgenden Bash-Einzeiler nutzen:
1 2 3 4 | |
Wenn man die Bash nicht bemühen möchte, dann kann man auf die folgende Webseite zurückgreifen: https://hackertarget.com/zone-transfer/
Wir empfehlen jedem Admin der jetzt vielleicht etwas ins Nachdenken kommt es selbst einmal zu testen.
Wenn Sie für alle Nameserver folgendes als Ausgabe erhalten, dann sind Sie auf der sicheren Seite:
1
| |
Andernfalls sollten Sie die DNS-Konfiguration überprüfen. Falls Sie den weit verbreiteten DNS-Server BIND nutzen, dann lassen sich AXFRs wie folgt auf bestimmte IPs beschränken:
1
| |
Wobei 192.168.1.1 die IP des sekundären Servers ist.
Zusammenfassung
Es ist interessant und gewissermaßen erstaunlich, dass sich bis heute so viele fehlerhaft konfigurierte Server finden lassen. Da das Thema in den 1990er Jahren umfassend in der Fachwelt diskutiert wurde sind wir eigentlich davon ausgegangen auf kaum verwundbare Server zu stoßen.
Das Problem wurde vom US-CERT aufgegriffen, was zu einem von zwölf Alerts im Jahr 2015 führte.
Soweit so gut,
Das Team der Internetwache.org
Updates
- #1: 29/03/2015: URL des Webdienstes geändert. Behebungsmöglichkeit für den BIND hinzugefügt.
- #2: 08/01/2016: URL zum Alert des US Cert hinzugefügt