Spoofing von DNS-Datensätzen durch Exploit bei dynamischen Updates von DHCP DNS
Zusammenfassung
Forscher von Akamai haben neue Angriffe auf Active Directory-Domänen, die DHCP-Server (Dynamic Host Configuration Protocol) von Microsoft verwenden, entdeckt.
Diese Angriffe könnten dazu führen, dass Angreifer vertrauliche DNS-Datensätze fälschen. Die Konsequenzen reichen vom Diebstahl von Anmeldedaten bis hin zur vollständigen Gefährdung der Active Directory-Domäne. Die Angriffe erfordern keine Anmeldedaten und arbeiten mit der Standardkonfiguration des Microsoft DHCP-Servers.
Die Anzahl der betroffenen Organisationen kann erheblich sein. Der Microsoft DHCP-Server ist sehr beliebt. Er wurde in 40 % der von Akamai überwachten Netzwerke ausgeführt.
Wir haben Microsoft unsere Ergebnisse mitgeteilt, aber eine Problembehebung ist nicht geplant.
Dieser Blogbeitrag beinhaltet die folgenden Themen: Beschreiben der Best Practices für die Konfiguration des Microsoft DHCP-Servers auf eine Weise, die diese Angriffe abwehrt, und ein Tool freigibt, das für die Nutzung durch Systemadministratoren und blaue Teams zur Erkennung riskanter Konfigurationen gedacht ist.
In einem zukünftigen Blogbeitrag werden wir technische Details zur Implementierung dieser Angriffe aus der Sicht eines Angreifers vorstellen.
Einführung
Die Möglichkeit, DNS-Datensätze zu fälschen, ist für Angreifer sehr attraktiv, da dies verheerende Folgen haben kann. Dazu gehören die Offenlegung vertraulicher Daten, die Kompromittierung von Anmeldedaten und sogar die Ausführung von Remote-Code.
In diesem Blogbeitrag untersuchen wir eine Angriffsfläche in DNS, die selten erforscht wurde und durch eine scheinbar harmlose DHCP-Funktion zugänglich gemacht wird. Als wir sie nutzten, fanden wir verschiedene Möglichkeiten, wie Angreifer DNS-Datensätze auf Microsoft DNS-Servern fälschen konnten, einschließlich eines nicht authentifizierten, willkürlichen Überschreibens von DNS-Datensätzen.
Neben den Angriffsabläufen beschreiben wir auch ausführlich die Funktionsweise eines Microsoft DHCP-Servers, seine Interaktion mit DNS und Active Directory und wie diese Schnittstellen ordnungsgemäß gesichert werden können. Obwohl es online viele verstreute (und ungenaue!) Ressourcen zu DHCP gibt, glauben wir, dass dieser Blogbeitrag eine genaue und umfassende Ressource zu diesem Thema ist, in der alle wichtigen Informationen für Verteidiger an einem Ort präsentiert werden.
DNS und Active Directory
Unser Weg beginnt mit Active Directory (AD). AD ist für seine Vorgänge sehr auf DNS angewiesen. Jede Domain benötigt einen DNS-Server, der eine spezielle DNS-Zone mit der Bezeichnung Active Directory Integrated DNS (ADIDNS)-Zone hostet (Abbildung 1). Diese Zone wird zum Hosten von DNS-Datensätzen für alle mit der Domain verbundenen Rechner und die verschiedenen Dienste in AD verwendet.
Abb. 1: Der Standard-ADIDNS
Datensätze in ADI-Zonen werden mit einer DNS-Funktion verwaltet, die Dynamic Updatesheißt. Mit dieser Funktion kann jeder Client für seinen eigenen Datensatz verantwortlich sein. Wenn er seinen DNS-Datensatz erstellen oder ändern muss, sendet er eine spezielle DNS-Anfrage, die die Daten enthält, die auf dem Server geändert werden müssen (Abbildung 2). Wenn der DNS-Server diese Anfrage empfängt, werden die Datensätze des Clients entsprechend geändert.
Abb. 2: Ein Beispiel für den Inhalt eines DNS-Updates
Eine der wichtigsten Funktionen von DNS Dynamic Updates ist Secure Updates, die steuert, wer die DNS-Datensätze in der Zone ändern kann. Ohne sichere Updates gehorcht der DNS-Server blind jeder Aktualisierungsanforderung, sodass Angreifer vorhandene Datensätze einfach überschreiben können. Mit dieser Funktion werden standardmäßig nur sichere Updates vom DNS-Server für ADI-Zonen akzeptiert (Abbildung 3).
Abb. 3: Standardeinstellungen für DNS Dynamic Updates
Bei Verwendung von Secure Updates werden alle vom Server empfangenen Aktualisierungsanforderungen authentifiziert und autorisiert. In ADI-Zonen wird dies mit Kerberos durchgeführt. Wenn ein Update an den Server gesendet wird, enthält es ein Kerberos-Ticket, das zur Authentifizierung des Nutzers verwendet wird (Abbildung 4). Weitere Informationen zum Kerberos-Authentifizierungsprozess über DNS finden Sie in der Studie von Dirk-Jan Mollema zum Weiterleiten von Kerberos über DNS.
Abb. 4: Ein Kerberos-Ticket innerhalb eines DNS-Updates
Jeder DNS-Datensatz ist durch eine Zugriffskontrollliste (ACL) geschützt, die die Zugriffsrechte für jeden Prinzipal festlegt. Diese Zugriffsrechte werden bei der ersten Erstellung des Datensatzes festgelegt: Wenn ein Client einen DNS-Datensatz durch Senden eines dynamischen DNS-Updates erstellt, wird das Konto des Computers, der den DNS-Datensatz erstellt hat, automatisch als Eigentümer des Datensatzes zugewiesen. Es erhält dann die entsprechenden Berechtigungen. Normalerweise verwendet jeder DNS-Client sein eigenes Gerätekonto-Ticket, um DNS-Aktualisierungen durchzuführen. Um eine Aktualisierungsanforderung zu autorisieren, überprüft der DNS-Server die ACL des Datensatzes mit dem authentifizierten Prinzipal.
In Abbildung 5 sehen Sie die ACL für den DNS-Datensatz des Hosts „PC.aka.test“. Dieser Datensatz wurde vom Computerkonto erstellt und hat daher die Berechtigung, ihn zu ändern.
Abb. 5: Standard-ACL eines DNS-Datensatzes
Andere Prinzipals (mit Ausnahme einiger integrierter starker Gruppen) sollten keine Berechtigungen für den Datensatz haben. Wenn ein anderer Prinzipal versucht, einen DNS-Datensatz zu ändern, dessen Eigentümer er nicht ist oder für den er keine Berechtigungen hat, lehnt der Server die Aktualisierung ab.
ADIDNS-Zonen können für Angreifer sehr interessant sein. Frühere Forschung von Kevin Robertson NETSPI hat einige interessante Angriffe auf diese DNS-Zonen hervorgehoben. Wir wollten diese Angriffsfläche erweitern und untersuchten weitere verwandte Funktionen, die uns zu einer interessanten Funktion führten – DHCP DNS Dynamic Updates.
DHCP DNS Dynamic Updates
DHCP ist ein Netzwerkverwaltungsprotokoll, mit dem Clients automatisch IP-Adressen und andere Netzwerkoptionen zugewiesen werden. Wenn ein Client einem neuen Netzwerk beitritt, versucht er, einen DHCP-Server zu erreichen, indem er eine Broadcast-Nachricht sendet und Netzwerkkonfigurationen anfordert. Wenn ein DHCP-Server diese Anforderung empfängt, antwortet er mit einer zugewiesenen IP-Adresse an den Client.
DHCP ist ein sehr gängiges Protokoll, das in den meisten Unternehmensnetzwerken verwendet wird, und insbesondere der Microsoft DHCP-Server ist eine sehr beliebte Option – wir haben gesehen, dass der Microsoft DHCP-Server auf 40 % der Rechenzentrumsnetzwerke ausgeführt wurde, die wir überwachen.
Obwohl moderne Windows-Clients (Windows 2000 und höher) normalerweise ihre eigenen Datensätze erstellen, indem sie dynamische DNS-Updates senden, ist dies nicht immer der Fall. DNS-Datensätze können auch mit einer DHCP-Funktion erstellt werden, die DHCP DNS Dynamic Updatesheißt. Diese Funktion ermöglicht einem DHCP-Server die Registrierung von DNS-Datensätzen im Namen seiner Clients. Wenn ein Client vom DHCP-Server eine IP-Adresse erhält, kann dieser den DNS-Server kontaktieren und den DNS-Datensatz des Clients aktualisieren. Zur Durchführung dieser Updates verwendet der DHCP-Server (Überraschung!) DNS Dynamic Updates.
Die Namensähnlichkeit kann ziemlich verwirrend sein, lassen Sie uns also klarstellen:
Funktion |
Protocol |
Zweck |
|---|---|---|
NS Dynamic Updates |
DNS |
DNS-Clients erlauben, DNS-Datensätze auf dem DNS-Server zu erstellen oder zu ändern |
DHCP DNS Dynamic Updates |
DHCP |
Dem DHCP-Server erlauben, DNS-Datensätze im Namen seiner Clients zu erstellen oder zu ändern – die Aktualisierungen werden mit DNS Dynamic Updates durchgeführt. |
Der DHCP DNS Dynamic Update-Prozess ist in Abbildung 6 dargestellt.
Abb. 6: DHCP DNS Dynamic Update-Prozess
Der DHCP-Client erhält eine IP-Adresse vom DHCP-Server und informiert ihn über seinen FQDN (Fully Qualified Domain Name).
Der DHCP-Server sendet eine dynamische Aktualisierungsanforderung an den DNS-Server.
Der DNS-Server validiert die Anfrage, erstellt einen relevanten Datensatz und informiert den DHCP-Server über das Ergebnis einer Dynamic-Update-Antwort.
Der Client muss explizit angeben, dass ein DNS-Datensatz in seinem Namen erstellt werden soll (Abbildung 7). Dies erfordert die Standardkonfiguration, und es gilt selbst, wenn die Funktion DHCP DNS Dynamic Updates aktiviert ist.
Abb. 7: DHCP DNS Dynamic Updates Standardkonfiguration
Um dies festzulegen, muss der Client eine dedizierte DHCP-Option senden. DHCP-Optionen (Abbildung 8) sind zusätzliche Felder, die einem DHCP-Paket hinzugefügt werden können und von Client und Server zum Austausch von Informationen verwendet werden.
Abb. 8: Ein Beispiel für DHCP-Optionen
In unserem Fall schickt der Client die FQDN-Option, angegeben in RFC 4702. Mit dieser Option kann der DHCP-Client den Server über seinen vollqualifizierten Domainnamen (FQDN) informieren und angeben, ob er einen DNS-Datensatz im Namen des Clients registrieren soll. Dazu kann der Client das Server-Flag verwenden, das Bestandteil der FQDN-Option ist. Wenn Sie den Wert auf 1 setzen, wird dem Server mitgeteilt, dass er einen Datensatz basierend auf dem angegebenen FQDN erstellen soll (Abbildung 9).
Abb. 9: DHCP-Anfrage mit der FQDN-Option
Nach Erhalt dieser Anforderung sendet der DHCP-Server ein DNS Dynamic Update und erstellt den angeforderten Datensatz (Abbildung 10).
Abb. 10: ADI DNS Zone mit unserem neuen Datensatz
Diese Funktion ist nützlich, wird aber heute selten verwendet (wie bereits erwähnt, erstellen die meisten modernen Windows-Clients einfach ihre eigenen Datensätze). Trotzdem ist diese Funktion in Microsoft DHCP-Servern standardmäßig aktiviert, d. h., der DHCP-Server registriert einen DNS-Datensatz für jeden Client, der ihn anfragt.
Beachten Sie, dass DHCP DNS Dynamic Updates keine Authentifizierung durch den DHCP-Client erfordern. Jeder im Netzwerk kann eine IP-Adresse von einem DHCP-Server leasen, sodass ein Angreifer im Wesentlichen den DHCP-Server verwenden kann, um sich selbst beim DNS-Server zu authentifizieren. Dadurch wird dem Angreifer Zugriff auf die ADIDNS-Zone gewährt, obwohl er keine Anmeldedaten hat.
Microsoft scheint sich der potenziellen Risiken dieser Funktion bewusst zu sein und erkennt einige von ihnen an. Angreifern und Verteidigern ist diese Angriffsfläche jedoch noch weitgehend unbekannt
In den folgenden Abschnitten werden die Angriffe beschrieben, die durch Missbrauch von DHCP DNS Dynamic Updates ausgeführt werden können.
DHCP DNS-Spoofing
Zuvor beschriebene ADIDNS-Spoofing-Angriffe nutzten ADIDNS, um den klassischen LLMNR/NBNS-Spoofing -Angriff zu verbessern. Nachdem ein Angreifer erfolglose Versuche zur Namensauflösung („tote Hosts“) identifiziert hat, registriert er den Namen in der ADI-Zone. So verweisen zukünftige Versuche zur Namensauflösung auf den Computer des Angreifers.
Dieser Angriff könnte sehr wirkungsvoll sein, aber er hatte eine wichtige Voraussetzung: gültige Domain-Anmeldedaten. Durch die Verwendung des DHCP-Servers können wir diese Anforderung umgehen und ohne Anmeldedaten arbeiten. Wir können einfach ein DHCP DNS Dynamic Update für jeden FQDN senden, der nicht in der ADI-Zone vorhanden ist, und der DHCP-Server erstellt sie für uns. Wir nennen diese Variante des Angriffs DHCP DNS-Spoofing. Über diese Technik wurde auch in einem Blogbeitrag von Hans Lakhan von TrustedSec berichtet.
Welche DNS-Namen könnten wir für diesen Angriff verwenden? Wir beziehen uns wieder auf Robertsons Forschung.Manche offensichtliche Kandidaten würden nicht funktionieren.
Der berüchtigte WPAD -Hostname würde von der Liste der lobalen Abfrageblöcke (GQBL) auf dem DNS-Server blockiert werden.
Der Platzhalterdatensatz („*“) kann nicht über dynamische DNS-Updates erstellt werden und kann daher in diesem Szenario nicht missbraucht werden.
Ohne diese beiden Kandidaten haben wir die Möglichkeit, tote Hosts zu identifizieren, die ausschließlich im Netzwerk vorkommen. Wir können sie identifizieren, indem wir das Netzwerk nach Übertragungen zur Namensauflösung über Link-Local Multicast Name Resolution (LLMNR) oder NetBIOS Name Service (NBT-NS) durchsuchen. Nachdem wir einen potenziell toten Host identifiziert haben, können wir einen übereinstimmenden DNS-Datensatz erstellen, indem wir ein DHCP DNS Dynamic Update senden (Abbildung 11).
Abb. 11: DHCP DNS Dynamic Update verwenden, um tote Hostnamen zu fälschen
Ein Host im Netzwerk versucht, den Namen „PC.aka.test“ aufzulösen und sendet dem DNS-Server eine Abfrage.
„PC.aka.test“ ist dem DNS-Server unbekannt, und er antwortet daher mit „kein derartiger Name“.
Der Host sendet dann einen LLMNR-Multicast, um zu versuchen, den „PC.aka.test“ in seinem LAN zu finden.
Der Angreifer identifiziert diesen Versuch und fordert einen IP-Lease vom DHCP-Server mit „PC.aka.test“ als FQDN an.
Der Server sendet eine dynamische Aktualisierungsanforderung an den DNS-Server, und der Datensatz wird erstellt.
Wenn nun ein Host im Netzwerk das nächste Mal versucht, „PC.aka.test“ aufzulösen, wird er an den Angreifer weitergeleitet. Der Angreifer muss jetzt nur ntlmrelayx.py starten und auf Authentifizierungsversuche warten.
Dieser Ansatz ist besser als die standardmäßige LLMNR/NBNS-Spoofing-Methode und die ADIDNS-Spoofing-Variation.
Klassisches LLMNR/NBNS-Spoofing erfordert keine Authentifizierung, ist jedoch auf Opfer im selben LAN beschränkt (da LLMNR/NBNS Broadcast-basiert sind).
ADIDNS-Spoofing gab uns die Möglichkeit, Opfer außerhalb des LAN anzugreifen (da DNS über Subnetze hinweg funktioniert), erforderte aber einen authentifizierten Nutzer.
Mit DHCP DNS Dynamic Updates erhalten wir das Beste aus beiden Welten: Der Angriff wirkt auf Opfer außerhalb des LAN und erfordert keine Authentifizierung.
Das ist ziemlich cool, aber wir können es noch besser machen.
Vorhandene Datensätze überschreiben
Das Erstellen nicht vorhandener DNS-Datensätze ist cool, aber dadurch sind wir auf eine andere Möglichkeit aufmerksam geworden: Was passiert, wenn wir versuchen, einen Datensatz für einen bereits vorhandenen Hostnamen zu erstellen? Könnten wir ihn überschreiben? Idealerweise sollte es nicht möglich sein – oder doch? Nun ...
Wir haben Fälle identifiziert, in denen es nicht authentifizierten Angreifern möglich sein könnte, vorhandene Datensätze zu überschreiben. Wir nennen diese Technik Überschreiben von DHCP-DNS. Bevor wir auf diese Fälle eingehen, wollen wir einige weitere Details zum Prozess für DHCP Dynamic Updates besprechen.
DNS-Datensatztypen und deren Eigentümer
Im Kontext von DHCP-DNS-Angriffen muss zwischen zwei Arten von DNS-Datensätzen unterschieden werden (Abbildung 12). Ab jetzt werden wir die folgenden Begriffe verwenden:
Client-Datensatz: Datensätze, die direkt von Windows-Clients erstellt wurden
Verwaltete Datensätze: Datensätze, die vom DHCP-Server im Namen von Clients erstellt wurden
Abb. 12: DNS-Datensatztypen
Der entscheidende Unterschied zwischen diesen Clients ist der Eigentümer. Wie wir zuvor in diesem Beitrag beschrieben haben, wird ein Client-Datensatz erstellt, wenn eine DNS-Aktualisierung durchgeführt wird; außerdem wird der Prinzipal, der die Aktualisierungsanforderung gesendet hat, als Datensatzeigentümer zugewiesen. Bei normalen Windows-Clients ist dieser Prinzipal das Gerätekonto des Clients.
Man könnte erwarten, dass verwaltete Datensätze auch dem anfragenden Client gehören würden, aber das ist nicht der Fall. Wenn der DHCP-Server DNS-Aktualisierungen im Namen von Clients sendet, authentifiziert er sich auch mit seinem eigenen Gerätekonto – das zum Datensatzeigentümer wird.
Dieser Unterschied ist in Abbildung 12 zu sehen. PC2 ist ein Client-Datensatz, der dem Client gehört, und PC1 ist ein verwalteter Datensatz, der dem DHCP-Server gehört.
Zugriffskontrolllisten beschränken DHCP-DNS-Überschreibungen
Wenn wir versuchen, ein DHCP DNS Dynamic Update für einen vorhandenen Datensatz durchzuführen, in diesem Fall „PC.aka.test“, scheitern wir. Wir beobachten ein interessantes Verhalten: Der DHCP-Server sendet tatsächlich ein DNS-Update mit unserem bereitgestellten FQDN, aber das Update wird dann vom Server abgelehnt (Abbildung 13).
Abb. 13: Vom Server abgelehnte DHCP-DNS-Aktualisierung
Dies geschieht, weil der DHCP-Server nicht berechtigt ist, den Datensatz zu ändern.
PC.aka.test ist ein Client -Datensatz, dessen Eigentümer der PC$ Prizipal ist. Wenn der DHCP-Server das DNS-Update sendet, authentifiziert er sich mithilfe seines eigenen Gerätekontos – DHCP$. Da dieses Konto keine Berechtigungen für den Datensatz hat, wird die Aktualisierung abgelehnt (Abbildung 14).
Abb. 14: Überschreiben des DNS-Datensatzes fehlgeschlagen
Hier eine Zusammenfassung: Angreifer können über den DHCP-Server beliebige DNS-Aktualisierungen senden, aber die DNS-Datensätze sollten aufgrund ihrer ACLs vor Überschreiben geschützt sein.
Jetzt, da wir den Mechanismus verstehen, der Überschreibungen verhindern soll, wollen wir sehen, wie sie immer noch ausgeführt werden können.
Überschreiben von verwalteten Datensätzen
Obwohl das Überschreiben vorhandener Client-Datensätze aufgrund ihrer einschränkenden ACLs (Access Control List, Zugriffssteuerungsliste) nicht funktioniert, können verwaltete Datensätze (die von DHCP erstellt wurden) überschrieben werden– denn der Authentifizierungsrechner ist auch Eigentümer des Datensatzes (Abbildung 15).
Dies ist möglich, weil ein DHCP-Server die Eigentumsrechte an DNS-Datensätzen nicht überprüft und ein DNS-Update für jeden angeforderten FQDN sendet.
Abb. 15: DHCP-DNS-Überschreibungen von Datensätzen, die Eigentum des DHCP-Servers sind
Wie wir sehen, führt der DHCP-Server eine Aktualisierung mit demselben Konto durch, das Eigentümer des Datensatzes ist – sein eigenes –, und die Aktualisierung ist erfolgreich.
Dazu ein Beispiel: Wir booten einen Ubuntu-Server, der nicht Teil der Domain ist und daher keinen eigenen DNS-Datensatz registrieren kann. Stattdessen wird der DHCP-Server aufgefordert, dies in seinem Namen zu tun (Abbildung 16).
Abb. 16: Der DHCP-Server registriert einen DNS-Datensatz im Namen des Ubuntu-Servers
Dieser Datensatz gehört zum Konto des DHCP-Servercomputers. Von unserem angreifenden Gerät fordern wir den gleichen FQDN vom DHCP-Server im Lease-Prozess an. Wir überprüfen die DNS-Zone und stellen fest, dass das Überschreiben erfolgreich war und der Datensatz nun auf die IP verweist, die uns gerade im Lease überlassen wurde (Abbildung 17).
Abb. 17: Ubuntu-Server-DNS-Datensatz wurde überschrieben
Dieser Angriff ist in Ordnung, aber seine Auswirkungen sind ziemlich begrenzt, da er sich nur auf verwaltete Datensätze auswirkt. Wie bereits erwähnt, sind diese Datensätze viel seltener als Client-Datensätze, die von diesem Angriff aber nicht betroffen sind. Dennoch können verwaltete Datensätze immer noch in einigen Fällen gefunden werden, in denen der Client seinen eigenen Datensatz nicht registrieren kann, z. B.:
Nicht-Windows-Clients
Ältere Windows-Clients
Windows-Clients, die Client-DNS-Aktualisierungen deaktiviert haben
DHCP-Selbstüberschreibung
Um die potenziellen Auswirkungen zu erhöhen, möchten wir Datensätze überschreiben können, die in jeder ADI-Zone vorhanden sind – Client-Datensätze. Das Problem besteht darin, dass diese Datensätze den Geräten gehören, die sie erstellt haben, und wir können uns nur über das Gerätekonto des DHCP-Servers authentifizieren.
Doch was ist mit dem DNS-Datensatz des DHCP-Servers? Wenn der DHCP-Server seinen eigenen DNS-Datensatz erstellt, wird sein Gerätekonto zum Eigentümer des Datensatzes! Es stellt sich heraus , dass wir den DHCP-Server veranlassen können, DHCP-DNS-Überschreibungen selbst durchzuführen. Wenn wir den DHCP-Servernamen als FQDN angeben, sendet der DHCP-Server ein DNS-Update für seinen eigenen Clientdatensatz – und dieses Überschreiben würde erfolgreich sein!
Abbildung 18 zeigt diesen Angriffsfluss.
Abb. 18: DHCP-DNS-Überschreibungen des DHCP-Server-DNS-Datensatzes
Dieser Angriff ist zuverlässiger: Wenn ein Microsoft DHCP-Server im Netzwerk vorhanden ist, ist ein übereinstimmender Client-Datensatz garantiert, während verwaltete Datensätze (die für das vorherige Überschreiben benötigt werden) seltener sind.
Was die Auswirkungen betrifft, so könnten Angreifer jede für den DHCP-Server bestimmte Kommunikation abfangen. Der Schweregrad hängt von der Art des Datenverkehrs ab. In den meisten Fällen kann die Fähigkeit, die für den DHCP-Server bestimmte Kommunikation abzufangen, missbraucht werden. Dann können Anmeldedaten abgefangen und weitergeleitet oder vertraulicher Datenverkehr anderer Dienste erfasst werden, die möglicherweise auf dem Server installiert sind.
Apropos sensible Services: Was passiert, wenn der DHCP-Server auf einem Domainencontroller (DC) installiert ist? Können wir den DC-Datensatz überschreiben? Es stellte sich heraus, dass wir das können.
Willkürliches Überschreiben von DHCP DC
Wenn der DHCP-Server auf einem DC installiert ist, können wir eine DHCP-DNS-Überschreibung des eigenen Datensatzes des DC durchführen (aus den Gründen, die wir bereits in diesem Post beschrieben haben). Das kann sehr nützlich sein, aber wir können noch mehr tun.
Wie wir bereits wissen, wird, wenn der DHCP-Server auf einem DC installiert ist, beim Senden von DNS-Updates das Computerkonto des DC verwendet. Wenn wir die Standard-ACL eines beliebigen DNS-Datensatzes überprüfen, sehen wir interessanterweise, dass der ENTERPRISE DOMAIN CONTROLLER -Prinzipal Schreibberechtigung für jeden DNS-Datensatz in der Zone hat – unabhängig davon, wer ihn erstellt hat (Abbildung 19).
Abb. 19: Standard-ACL aller Domain-Datensätze, die die Gruppe ENTERPRISE DOMAIN CONTROLLERS enthalten
Das ist eine große Sache. Wenn der DHCP-Server ein DC ist, verfügt er über Berechtigungen für alle Datensätze in der Zone, und Angreifer könnten ihn dazu verwenden , jeden DNS-Datensatz in der ADI-Zone zu überschreiben – als nicht authentifizierter Nutzer! Der Angriff ist in Abbildung 20 dargestellt.
Abb. 20: Willkürliches Überschreiben von DHCP-DNS, wenn der DHCP-Server ein DC ist
Unsere Daten zeigen, dass diese risikoreiche Konfiguration ziemlich häufig vorkommt. Unter den von uns beobachteten Netzwerken, die den Microsoft DHCP-Server benutzen, haben 57 % einen DHCP-Server auf einem DC installiert. Alle diese Domains sind standardmäßig anfällig.
Obwohl dieses Risiko von Microsoft in seiner Dokumentation eingeräumt wurde, sind wir der Ansicht, dass das Bewusstsein für diese Fehlkonfiguration nicht im Einklang mit den möglichen Auswirkungen steht.
Schadensbegrenzende Maßnahmen für DHCP-DNS-Angriffe und deren Umgehung
Alle bisher beschriebenen Angriffe funktionieren mit der Standardkonfiguration von Microsoft DHCP-Servern. Es gibt jedoch zwei Einstellungen, die helfen könnten, einige von ihnen abzuschwächen. Werfen wir einen Blick auf sie, um zu sehen, wie auch sie umgangen werden können.
DHCP Name Protection
Wie wir wissen, kann ein DHCP-Server, der einen DNS-Eintrag erstellt, andere Clients nicht daran hindern, denselben FQDN anzufordern und den Server zu zwingen, ihn zu überschreiben. Name Protection ist eine Funktion, die dies verhindern soll.
Name Protection wird mithilfe eines speziellen DNS-Datensatztyps implementiert – DHCID (DHCP-Client-ID). Wenn Name Protection aktiviert ist, wird jedes Mal, wenn ein DHCP-Server einen Datensatz im Namen eines Clients registriert, ein zusätzlicher DHCID-Datensatz erstellt (Abbildung 21).
Abb. 21: DHCID-Datensatz, der von einem DHCP-Server mit aktiviertem Name Protection erstellt wurde
Wie Sie sehen, ist der DHCID-Datensatzwert ein Datenblock, der in Base64 codiert ist. Dieser Wert (den wir später in diesem Beitrag analysieren werden) ist eine eindeutige Signatur, die dazu dient, den DHCP-Client zu identifizieren, der die Datensatzerstellung oder -aktualisierung angefordert hat.
Wenn der DHCP-Server aufgefordert wird, einen DNS-Datensatz zu ändern, berechnet er den DHCID-Wert des Clients und sendet ein DNS-Update, das die aktualisierten Daten neben diesem DHCID-Wert enthält.
Wenn der Datensatz noch nicht auf dem DNS-Server vorhanden ist, erstellt er einfach den Datensatz und den entsprechenden DHCID-Datensatz. Wenn jedoch Host (A) und DHCID-Datensätze vorhanden sind, wird der vorhandene DHCID-Wert mit dem vom DHCP-Server gesendeten Wert verglichen. Die Aktualisierung wird nur durchgeführt, wenn die Werte übereinstimmen.
Im Wesentlichen weist der DHCID-Datensatz also einen DNS-Datensatz dem Client zu, der ihn erstellt hat. Nachdem diese Zuordnung erstellt wurde, kann nur dieser ursprüngliche Client Änderungen am Datensatz vornehmen.
Name Protection umgehen
Wir haben eine Möglichkeit gefunden, Name Protection durch die Verwendung einer DHCP-Freigabemeldung zu umgehen. Das ist eine Nachricht, die von DHCP-Clients gesendet wird, um den Server zu informieren, wenn sie ihre geleaste IP-Adresse nicht mehr benötigen. Um den Überblick über die Adressen zu behalten, die er geleast hat, verwaltet der DHCP-Server eine Tabelle, in der die verschiedenen Adressen, ihre Ablaufzeiten und die eindeutige ID des Clients, der sie geleast hat, gespeichert werden (Abbildung 22).
Abb. 22: Lease-Tabelleneintrag für DHCP-Server
Die eindeutige Kennung ist die MAC-Adresse des Clients. Beim Empfang einer Freigabemeldung von einem Client sucht der DHCP-Server nach einem vorhandenen Eintrag mit einer übereinstimmenden Adresse und ID und löscht ihn, wenn er gefunden wird. Wenn DHCP DNS Dynamic Updates aktiviert sind, sendet der DHCP-Server zusätzlich zur Freigabe der IP-Adresse auch ein dynamisches DNS-Update, um den zugehörigen DNS-Datensatz des Clients zu löschen.
Wenn wir eine DHCP-Version mit einer eindeutigen ID (MAC-Adresse) senden können, die mit der Ziel-ID übereinstimmt, löscht der DHCP-Server den Datensatz, sodass wir ihn für uns selbst registrieren können. Die einzige Voraussetzung, um Name Protection zu umgehen, ist die MAC-Adresse des Opfers! (Beachten Sie, dass es nicht notwendig ist, unsere tatsächliche MAC-Adresse zu ändern – der Wert wird aus dem DHCP-Header übernommen.)
Wenn wir uns im selben LAN befinden wie das Ziel, ist die Suche nach seinem MAC ziemlich einfach. Wir können ihn beispielsweise durch Senden einer ARP-Anfrage finden. Aber was, wenn wir nicht im selben LAN sind? Dann gibt es eine andere Option.
Brute-Forcing der DHCID-Datensätze, Name Protection zu umgehen
DHCID-Datensätze werden definiert in RFC 4701, und ihr Algorithmus ist ziemlich einfach:
Verketten der folgenden Werte:
DHCP HTYPE (Hardwaretyp). Für Ethernet ist der Wert 01.
DHCP-Client-ID-Option
Datensatz-FQDN (im DNS-Drahtformat)
SHA256 das Ergebnis
DHCID-Datenbits hinzufügen (In der Windows-Implementierung ist dieser Wert konstant.)
Das Ergebnis in Base64 codieren
Abbildung 23 zeigt ein DHCID-Berechnungsbeispiel.
Abb. 23: Ein DHCID-Berechnungsbeispiel
Da wir wissen, dass der FQDN und die Datenbits konstant sind, ist die einzige Variable die Client-ID, die wiederum die MAC-Adresse des Clients ist.
DHCID-Datensätze sind normale DNS-Datensätze, sodass jeder Client den DNS-Server nach ihren Werten abfragen kann. Da wir den Algorithmus zur Berechnung eines DHCID-Datensatzes kennen, können wir alle möglichen MAC-Adressen iterieren und deren DHCID-Wert berechnen und jedes Ergebnis mit unserem Zieldatensatz vergleichen. Wenn wir eine Übereinstimmung erhalten, wissen wir, dass wir die richtige MAC-Adresse gefunden haben. So können Angreifer die MAC-Adresse in angemessener Zeit per Brute Force erlangen – 248 mögliche MAC-Adressen könnten von einem modernen, dedizierten Computer in nur wenigen Tagen geknackt werden. Wir können diese Zeit drastisch reduzieren, wenn wir nur gemeinsame Anbieter-IDs verwenden. Ein Beispiel für diesen Prozess ist in Abbildung 24 zu sehen.
Abb. 24: Löschen eines DNS-Datensatzes, der durch Name Protection geschützt ist
Der referenzierte Code kann verwendet werden, um den DHCID-Wert basierend auf angegebenen Parametern zu berechnen.
Die Nebenwirkungen von Name Protection
DHCP Name Protection ist für verwaltete Datensätze gedacht: Im Wesentlichen schützt der DHCP-Server die von ihm erstellten Datensätze davor, dass sie von zufälligen Clients geändert werden. Name Protection hat nichts mit Client-Datensätzen zu tun.
Dennoch kann Name Protection in einigen Fällen Angriffe auf Client-Datensätze abwehren.
Beim Aktualisieren von DNS-Datensätzen mit aktiviertem Name Protection benötigt der DHCP-Server das Vorhandensein eines DHCID-Datensatzes. Da normale DNS-Clients keine DHCID-Datensätze erstellen, werden Client-Datensätze nicht von ihnen begleitet. Daher würde jeder Versuch, einen Client-Datensatz von einem DHCP-Server zu aktualisieren, fehlschlagen (Abbildung 25).
Abb. 25: DNS-Aktualisierung schlägt fehl, wenn kein DHCID-Datensatz vorhanden ist
Dies geschieht aufgrund der Art, wie Name Protection implementiert wird. Wenn ein DHCP-Server mit aktiviertem Name Protection ein DNS-Update sendet, fügt er der Anfrage ein Feld namens Prerequisites hinzu. Dieses Feld gibt Bedingungen an, die auf dem DNS-Server erfüllt sein müssen, damit die DNS-Aktualisierung durchgeführt wird. In Abbildung 26 sehen Sie, dass das DNS-Update, das vom DHCP-Server gesendet wird, eine Voraussetzung für den DHCID-Wert enthält.
Abb. 26: Voraussetzungen für DNS-Aktualisierung
Dies bedeutet, dass die Aktualisierung fehlschlägt, wenn kein übereinstimmender Wert vorhanden ist. Da Client-Datensätze nie über einen DHCID-Datensatz verfügen sollten, sollten die Client-Datensätze bei aktiviertem Name Protection vor DHCP-DNS-Überschreibungen geschützt sein, ohne dass es eine Möglichkeit gibt, diesen zu umgehen. Sollten sein.
Dies ist nicht wirklich Teil der Funktion Name Protection – eher ein Nebenprodukt –, da Name Protection per Definition nur verwaltete Datensätze schützen soll. Aufgrund der Logik, die wir gerade beschrieben haben, kann es jedoch auch Client-Datensätze schützen. Aber selbst diese zufällige Verteidigung kann umgangen werden.
Sind DHCP-Anwendungsbereiche die Rettung?
DHCP-Server unterstützen die Möglichkeit, mehrere Anwendungsbereiche zu definieren – ein Anwendungsbereich ist ein definierter Satz IP-Adressen in einem bestimmten Subnetz, den DHCP leasen kann (Abbildung 27).
Abb. 27: Ein Beispiel für DHCP-Anwendungsbereiche
Die Aufteilung in Anwendungsbereiche ermöglicht eine bessere Verwaltung der Adressverteilung und erlaubt auch die Anwendung verschiedener Richtlinien für verschiedene Subnetze. Name Protection ist eine dieser Richtlinien und ist auf der Bereichsebene aktiviert, was bedeutet, dass verschiedene Bereiche unterschiedliche Konfigurationen haben können.
Wie bereits in diesem Beitrag erwähnt, haben wir bei dem Versuch, eine DHCP-DNS-Überschreibung eines Client-Datensatzes durchzuführen, einen Fehler verursacht, da unser Leasing aus einem DHCP-Bereich mit Name Protection stammt. Aber es gibt etwas Wichtiges zu verstehen: Anwendungsbereich ist ein DHCP-Begriff. Client-Datensätze kennen ihn nicht und sind keinem Anwendungsbereich zugeordnet.
Aus diesem Grund können wir, wenn wir ein Leasing von einem anderen Anwendungsbereich erhalten, für den Name Protection deaktiviert ist, diese Schadensbegrenzung „umgehen“. (Wie Sie ein Leasing aus einem anderen Anwendungsbereich erhalten, für den Name Protection deaktiviert ist, geht über den Rahmen dieses Beitrags hinaus. Sie können sich jedoch die DHCP-Relay-Option) ansehen.
Dies bedeutet, dass selbst wenn ein einziger Bereich auf dem Server Name Protection deaktiviert hat, es ausreichen sollte, dass ein Angreifer Client-Datensätze überschreibt (aufgrund einer der oben beschriebenen Fehlkonfigurationen).
DNS-Anmeldedaten
Eine weitere Einstellung, die auf dem DHCP-Server konfiguriert werden kann, sind die DNS-Anmeldedaten. Diese Einstellung ermöglicht es uns, die Anmeldedaten eines Domain-Nutzers anzugeben und diese vom DHCP-Server anstelle des Computerkontos beim Erstellen und Aktualisieren von Datensätzen zu verwenden (Abbildung 28).
Abb. 28: Konfiguration der DHCP-DNS-Anmeldedaten
Gehen wir zurück zu dem Beispiel, in dem ein DHCP-Server auf einem DC installiert wurde. Bei der Aktualisierung von DNS-Datensätzen wurde das DC-Gerätekonto verwendet. Das Konto verfügt über Berechtigungen für jeden Datensatz in der Zone. Bei konfigurierten DNS-Anmeldedaten könnte stattdessen ein schwaches Konto verwendet werden, und der Angriff würde nicht mehr funktionieren.
Die Konfiguration von DNS-Anmeldedaten ist sehr wichtig, da dadurch die Angriffsfläche des DHCP-Servers reduziert werden kann. Er sollte in der Lage sein, die schwersten Angriffe abzuwehren, die wir zuvor beschrieben haben.
Es gibt jedoch zwei Details, die Sie bei der Verwendung dieser Funktion beachten müssen:
Die konfigurierten Anmeldedaten müssen ein schwacher Nutzer sein. Wenn wir ihn beispielsweise als Domainadministrator konfigurieren, kann der DHCP-Server beliebige Datensätze überschreiben.
DNS-Datensätze, die vom DHCP-Server erstellt werden, gehören weiterhin denselben Anmeldedaten und sind weiterhin anfällig für DHCP-DNS-Überschreibungen.
DNSUpdateProxy-Gruppe
Während unserer Untersuchung von Microsoft DHCP und seiner Interaktion mit DNS haben wir eine andere Funktion gefunden, die missbraucht werden kann: die DNSUpdateProxy -Gruppe. Diese Gruppe soll zwei Berechtigungsprobleme von verwalteten Datensätzen lösen: Das Problem mit dem aktualisierten Client und das Problem mit mehreren DHCP-Servern.
Problem mit aktualisiertem Client
Betrachten wir zunächst das Problem mit dem aktualisierten Client: Ein älterer Client verwendet zunächst den DHCP-Server, um einen DNS-Datensatz zu registrieren, wird dann aber auf ein neueres Betriebssystem aktualisiert, das dynamische DNS-Updates unterstützt. Der Client kann seinen Datensatz nicht direkt ändern, da der Datensatz dem DHCP-Server gehört, der ihn erstellt hat.
Um dieses Problem zu lösen, kann der DHCP-Server der DNSUpdateProxy-Gruppe hinzugefügt werden.
Diese Gruppe hat zwei Auswirkungen: Erstens unterscheidet sich die ACL des Datensatzes bei der Erstellung eines DNS-Datensatzes von normalen verwalteten Datensätzen. Der authentifizierten Nutzergruppe wird Schreibberechtigung für den Datensatz gegeben. Dies bedeutet, dass jeder Client in der Domain ihn ändern kann (Abbildung 29).
Abb. 29: ACL-Datensatz des DNSUpdateProxy
Der zweite Effekt ist eine „Datensatzübernahme“-Funktion: Der erste Client, der einen Datensatz ändert, der von einem DNSUpdateProxy-Mitglied erstellt wurde, erhält die Eigentumsrechte an diesem Datensatz und entfernt die Schreibberechtigung der authentifizierten Nutzer. Dadurch wird das Problem des aktualisierten Clients gelöst, indem Clients ihre eigenen Datensätze ändern und übernehmen können, sobald sie dazu aufgefordert werden.
Problem mit mehreren DHCP-Servern
Das zweite Problem tritt auf, wenn mehrere DHCP-Server zusammenarbeiten müssen. In diesem Beispiel haben wir zwei DHCP-Server – DHCP1 und DHCP2 –, und ein Client-PC1 registriert einen DNS-Datensatz über DHCP1.
Stellen wir uns nun vor, dass DHCP1 aus irgendeinem Grund offline geht und DHCP2 aktiv wird. Der Lease des Clients läuft ab, daher kontaktiert er DHCP2 für einen neuen. Wenn DHCP2 die neue IP least und versucht, den DNS-Datensatz für den Client zu ändern, schlägt dies fehl, da der Datensatz DHCP1 gehört (Abbildung 30).
Abb. 30: Ein Beispiel für eine Einrichtung mehrerer DHCP-Server
Dieses Problem kann ebenfalls durch Verwendung von DNSUpdateProxy behoben werden, da diese Gruppe eine zusätzliche Funktion aufweist. Wenn ein Mitglied von DNSUpdateProxy versucht, einen Datensatz zu ändern, der einem anderen Mitglied gehört, ist die Aktualisierung aufgrund der ACL erfolgreich. Aber dieses Mal ändern sich die ACL und die Eigentümerschaft nicht. Dies ermöglicht mehreren Servern, Datensätze gemeinsam zu besitzen.
Ein Sicherheitsrisiko und ein Bug
Sie wissen wahrscheinlich, dass die DNSUpdateProxy-Gruppe ein Sicherheitsrisiko darstellt: Jeder Datensatz, der von Mitgliedern dieser Gruppe erstellt wurde, könnte von jedem authentifizierten Nutzer „gestohlen“ werden. Dies ist keine Schwachstelle, sondern nur ein Missbrauch des Designs der Funktion. Microsoft ist sich dieses Risikos bewusst.
Zusätzlich zu diesem Risiko haben wir ein weiteres Problem identifiziert, das auf einen Fehler in der Implementierung der DNSUpdateProxy-Funktion zurückzuführen ist. Wenn ein Mitglied der Gruppe seinen eigenen DNS-Datensatz erstellt, wird er mit derselben anfälligen ACL erstellt, für die authentifizierte Nutzer Schreibberechtigungen haben.
Abbildung 31 zeigt ein Beispiel. Unser DHCP-Server-Datensatz dhcp1.aka.test verfügt zunächst über eine sichere ACL.
Abb. 31: Anfängliche ACL des DHCP-Servers
Wir sehen, dass das Gerätekonto über Berechtigungen verfügt und die Gruppe „authentifizierte Nutzer“ nirgendwo zu finden ist. Jetzt fügen wir den Server der DNSUpdateProxy-Gruppe hinzu und lösen eine Neuerstellung des DNS-Datensatzes aus. Dies kann aus mehreren Gründen geschehen, z. B. wenn der Servername geändert wird. Nachdem der DNS-Datensatz neu erstellt wurde, überprüfen wir seine neue ACL (Abbildung 32).
Abb. 32: Anfällige ACL für DHCP-Server
Wir sehen, dass der neue DNS-Datensatz jetzt von Domain-Nutzern beschreibbar ist. Dies ist offensichtlich kein beabsichtigter Teil der Funktion – vom Server erstellte verwaltete Datensätze sollen eine geänderte ACL haben, aber der servereigene Client-Datensatz sollte nicht betroffen sein.
Abwehr von DHCP-DNS-Angriffen
DHCP DNS Dynamic Updates bergen viele Risiken. Fassen wir die verschiedenen möglichen Serverkonfigurationen zusammen und erfahren Sie, wie Sie die soeben beschriebenen Angriffe abwehren können.
Wir beziehen uns auf die beiden Arten von Datensätzen – verwaltete Datensätze, die vom DHCP-Server erstellt wurden, und Client-Datensätze, die direkt von Windows-Clients erstellt wurden.
Die TL;DR-Version ist:
Deaktivieren Sie DHCP DNS Dynamic Updates, wenn Sie diese nicht benötigen.
Client-Datensätze sollten sicher sein, wenn Sie einen schwachen Nutzer als DNS-Anmeldedaten konfigurieren.
Verwaltete Datensätze können mit keiner Konfiguration vor Spoofing geschützt werden; verwenden Sie nach Möglichkeit statische DNS-Datensätze für vertrauliche Hosts, die nicht von Windows stammen
Verwenden Sie nicht DNSUpdateProxy, sondern verwenden Sie stattdessen dieselben DNS-Anmeldedaten für alle DHCP-Server.
DNS-Anmeldedaten
Dies ist die beste Möglichkeit, DHCP-DNS-Überschreibungen in Client-Datensätzen zu vermeiden. Konfigurieren Sie einen schwachen Nutzer mit einem starken Kennwort, das für diesen Zweck dediziert ist. Wenn Sie einen DHCP-Server auf Ihrem DC ausführen, ist dies von entscheidender Bedeutung. Mit dieser Einstellung werden DHCP-DNS-Überschreibungen bei verwalteten Datensätzen nicht gestoppt.
Name Protection
Name Protection sollte zwar theoretisch verwaltete Datensätze schützen, doch in der Praxis können Angreifer dies ziemlich leicht umgehen. Es sollte trotzdem aktiviert sein, um Überschreibungen weniger einfach zu machen.
Obwohl Name Protection nicht dazu gedacht ist, Client-Datensätze zu schützen, würden Überschreibangriffe trotzdem abgewehrt, wenn diese Funktion auf allen Anwendungsbereichen auf dem Server aktiviert ist.
Beim Konfigurieren von Name Protection auf Microsoft DHCP gibt es zwei Möglichkeiten, es anzuwenden: auf der Serverebene oder auf der Anwendungsbereichsebene. Man könnte meinen, dass die Aktivierung von Name Protection auf Serverebene bedeutet, dass Name Protection auf Serverebene aktiviert ist, oder? Dem ist aber nicht so. Das Aktivieren von Name Protection auf Serverebene stellt nur sicher, dass neue Anwendungsbereiche auf dem Server mit dieser aktivierten Einstellung erstellt werden. Sie wird jedoch nicht für vorhandene Anwendungsbereiche aktiviert. Es ist wichtig, sicherzustellen, dass Name Protection auf der Bereichsebene jedes der Anwendungsbereiche auf dem Server aktiviert ist.
DNSUpdateProxy
Sie sollten diese Gruppe nicht verwenden. Es ist ein Sicherheitsrisiko, da alle von ihren Mitgliedern erstellten Datensätze überschrieben werden können.
Wenn Sie über mehrere DHCP-Server verfügen und diese zusammenarbeiten möchten, sollten Sie stattdessen DNS-Anmeldedaten verwenden. Konfigurieren Sie einfach die gleichen DNS-Anmeldedaten auf allen DHCP-Servern, damit sie die Datensätze einer anderen Person bearbeiten können.
DNSUpdateProxy ist nur nützlich, wenn Sie Windows NT 4.0-Clients (oder älter) haben, die Sie in Kürze aktualisieren möchten. Und wenn Sie etwas in dem Alter haben, haben Sie größere Probleme als DNSUpdateProxy.
Wenn Sie aus irgendeinem Grund DNSUpdateProxy verwenden müssen, wird empfohlen, für jedes Gruppenmitglied einen statischen DNS-Datensatz zu erstellen. Ein statischer Datensatz wäre Eigentum des erstellenden Kontos, das sich von den Gerätekonten der verschiedenen Server unterscheiden sollte. Dadurch wird verhindert, dass Server eigene Datensätze mit unsicheren Berechtigungen erstellen.
DHCP DNS-Spoofing
Es gibt keine Möglichkeit, nicht authentifizierte Angreifer daran zu hindern, nicht vorhandene DNS-Datensätze zu erstellen. Die einzige Möglichkeit dazu besteht darin, DHCP DNS Dynamic Updates auf allen DHCP-Servern zu deaktivieren. Wenn die Funktion DHCP DNS Dynamic Updates in Ihrer Umgebung nicht erforderlich ist, empfiehlt es sich im Allgemeinen, sie zu deaktivieren. Dadurch werden einige Risiken eliminiert und die Angriffsfläche reduziert.
Erkennen von Fehlkonfigurationen mit Invoke-DHCPCheckup
Damit Sie das Chaos möglicher DHCP-Konfigurationen überwinden können, veröffentlichen wir ein PowerShell-Tool namens Invoke-DHCPCheckup , um Risiken im Zusammenhang mit dynamischen DHCP-DNS-Updates zu identifizieren (Abbildung 33).
Abb. 33: Invoke-DHCPCheckup Beispielausgabe
Das Tool identifiziert die folgenden Fehlkonfigurationen:
DNS-Anmeldedaten
DNS-Anmeldedaten sind nicht konfiguriert.
Die konfigurierten DNS-Anmeldedaten stammen von einem starken Nutzer.
Name Protection
Name Protection ist für einen Anwendungsbereich nicht aktiviert.
Name Protection ist bei neuen Anwendungsbereichen nicht standardmäßig aktiviert.
DNSUpdateProxy
Gruppenmitglieder anzeigen
Angeben, ob es sich bei den Mitgliedern um DHCP-Server handelt
Schwache Datensatz-ACLs
Datensätze auflisten, die DHCP-Servern gehören (verwaltete Datensätze)
Datensätze auflisten, die von authentifizierten Nutzern überschrieben werden könnten
Dieses Tool basiert auf der DHCP-Serververwaltungs-API und erfordert einen starken Nutzer, um es auszuführen. Daher ist das Tool hauptsächlich für blaue Teams gedacht.
Zusammenfassung
Wir haben alle unsere Ergebnisse an Microsoft weitergeleitet, das daraufhin geantwortet hat, dass alle oben genannten Probleme entweder beabsichtigt sind oder nicht schwerwiegend genug sind, um behoben zu werden.
Wir sind anderer Meinung. Die Auswirkungen der Angriffe, die wir hervorgehoben haben, können sehr erheblich sein: Die Fähigkeit, DNS-Datensätze ohne Authentifizierung zu überschreiben, ermöglicht Angreifern, sich auf Hosts in der Domain eine Machine-in-the-Middle-Position zu verschaffen. Dies könnte vertrauliche Informationen und Anmeldedaten leicht offenlegen und auch Relay-Angriffe ermöglichen, sodass Angreifer AD-Domains verletzen und Berechtigungen eskalieren können. Die in diesem Beitrag veröffentlichten Statistiken zeigen, wie solide die Bedrohung für viele Rechenzentrumsnetzwerke ist.
Da eine Lösung für diese Probleme nicht geplant ist, fordern wir Verteidiger auf, ihre Umgebungen mithilfe von Invoke-DHCPCheckup zu scannen, um die riskanten Fehlkonfigurationen zu finden, die wir hervorgehoben haben. Spoiler-Alarm – wenn Sie die Standardkonfiguration nicht geändert haben, sind Sie verwundbar.
Wir halten Sie auf dem Laufenden
In einem demnächst erscheinenden Blogbeitrag werden wir DDSpoof (DHCP DNS Spoof) veröffentlichen. Das ist ein Tool, das alle in diesem Artikel beschriebenen Angriffe implementiert. Wir zeigen, wie nicht authentifizierte Angreifer die erforderlichen Daten von DHCP-Servern sammeln, anfällige DNS-Datensätze identifizieren, überschreiben und diese Möglichkeit nutzen können, um AD-Domänen zu gefährden.
