DHCP-DNS-Spoofing gezielt einsetzen – ein praktischer Leitfaden
Einführung
Im ersten Teil dieser Blogserie haben wir neue Angriffe auf Active-Directory-Domains, die DHCP-Server (Dynamic Host Configuration Protocol) von Microsoft verwenden, beleuchtet. Diese Angriffe ermöglichen es Cyberkriminellen, DNS-Datensätze in Active Directory Integrated DNS-Zonen (ADIDNS) zu fälschen, indem sie die DHCP DNS Dynamic Updates-Funktion missbrauchen. Wir haben diese Funktion genauer untersucht und Fehlkonfigurationen hervorgehoben, die von Angreifern missbraucht werden könnten, um vertrauliche DNS-Datensätze zu fälschen.
In diesem zweiten Blogbeitrag möchten wir einige der technischen Details erläutern, die erforderlich sind, um diese Angriffsfläche auszunutzen. Wir werden die Methoden beschreiben, mit denen alle für die Durchführung der Angriffe erforderlichen Informationen gesammelt werden, einige Angriffsbegrenzungen beschreiben und untersuchen, wie mehrere DNS-Datensätze gefälscht werden können, indem wir ein interessantes DHCP-Serververhalten missbrauchen.
Zum Abschluss stellen wir ein neues Tool vor, das Sie Ihrer Toolbox hinzufügen können. Wir haben alles, was wir gelernt haben, kombiniert, um DDSpoof zu erstellen – ein Python-Tool, mit dem Red und Blue Teams DHCP-DNS-Angriffe durchführen und untersuchen können. In einem späteren Abschnitt dieses Blogbeitrags wird beschrieben, wie das Tool in verschiedenen Angriffsszenarien eingesetzt werden kann.
Haftungsausschluss: DDSpoof kann Sicherheitsteams dabei unterstützen, Risiken zu erkennen und gleichzeitig das Bewusstsein für diese Angriffsfläche zu schärfen. Das Tool allein reicht jedoch nicht aus, um tatsächlichen Schaden zu verursachen – es erfordert Netzwerkzugriff und weitere Ausnutzung, um das DNS-Spoofing-Primitiv zu missbrauchen.
DHCP-Aufzählung
In unserem vorherigen Beitrag ging es um die Theorie hinter DHCP DNS Spoofing. In der Praxis sind mehrere Informationen erforderlich, um die beschriebenen Angriffe effektiv durchzuführen. Ein Glück für die Angreifer: Die Fähigkeit, DHCP-Server und Informationen über ihre Konfiguration herauszufinden, sind Teil des DHCP-Protokolls, was den Aufklärungsprozess trivial macht.
In den folgenden Abschnitten werden verschiedene Methoden und Tricks beschrieben, mit denen Angreifer aus einem nicht authentifizierten Kontext diese verschiedenen Informationen sammeln können.
DHCP-Server identifizieren
Im Mittelpunkt eines DHCP-DNS-Angriffs steht der DHCP-Zielserver. Der erste Schritt besteht also darin, einen solchen zu identifizieren. Die Identifizierung aktiver DHCP-Server im Netzwerk ist sehr einfach. Ein Angreifer kann eine DHCP-Discover-Broadcast-Nachricht senden und die Antworten von Servern überprüfen.
Um DHCP-Nachrichten zu senden, können wir das Linux-Dienstprogramm dhclient ausführen – einen konfigurierbaren DHCP-Client, der die Interaktion mit DHCP-Servern ermöglicht. Wir können dhclient durch Bearbeiten der Konfigurationsdatei konfigurieren, die sich hier befindet: /etc/dhcp/dhclient.conf.
Wenn wir dhclient ausführen, fordert er die Netzwerkkonfiguration vom DHCP-Server an und wendet sie auf unseren Geräten an, wodurch unsere aktuelle IP-Adresse überschrieben wird. Um dies zu vermeiden, können wir ihn auf einer virtuellen Schnittstelle mit folgender Syntax ausführen:
dhclient <interface_name>:<virtual_interface_name>
Nach der Ausführung dieses Befehls können wir sehen, dass die ursprüngliche IP-Adresse (172.25.14.55) unverändert bleibt, während unsere virtuelle Schnittstelle vom DHCP-Server eine neue IP-Adresse erhalten hat (Abbildung 1).
Abb. 1: Verwendung von dhclient auf einer virtuellen Schnittstelle und Beibehaltung unserer ursprünglichen IP-Adresse
Wenn wir den Traffic aufzeichnen und DHCP-Offer-Nachrichten überprüfen, können wir alle aktiven DHCP-Server identifizieren (Abbildung 2).
Abb. 2: Senden einer DHCP-Discover-Nachricht zur Identifizierung aktiver DHCP-Server im Netzwerk
Die Domain und den DNS-Server eines DHCP-Servers abrufen
Nachdem wir DHCP-Server im Netzwerk identifiziert haben, müssen wir herausfinden, welche Datensätze über die einzelnen Server gefälscht werden können. Ein DHCP-Server kann nur Datensätze innerhalb der zugehörigen ADI-Zone erstellen. Ein Server, der der Domain „aka.test“ zugeordnet ist, kann nur DNS-Datensätze mit demselben Suffix schreiben: <hostname>.aka.test. Um zu verstehen, welche Datensätze wir fälschen können, müssen wir dieses Suffix identifizieren.
Darüber hinaus möchten wir wissen, auf welchem DNS-Server die neuen Datensätze gehostet werden, sodass wir sie abfragen und den Erfolg des Angriffs überprüfen können.
Mit der Option „Parameter Request List“ können Angreifer diese beiden Parameter herausfinden und den DHCP-Server nach bestimmten Einstellungen abfragen. Für unsere Zwecke können wir die mit dem Server verknüpften Optionen Domain Name und Domain Name Server abfragen.
Dazu können wir wieder dhclient nutzen. Um die Option Parameter Request List zu unserer Discover-Nachricht hinzuzufügen, fügen wir die folgende Zeile in die Konfigurationsdatei von dhclient ein:
request domain-name, domain-name-servers;
Wenn wir dhclient ausführen, (wie zuvor auf einer virtuellen Schnittstelle) und unsere Discover-Nachricht untersuchen, sehen wir, dass die Option Parameter Request List mit den angefragten Feldern angezeigt wird (Abbildung 3).
Abb. 3: Parameter Request List in einer DHCP-Discover-Nachricht
Ein empfangsbereiter Microsoft DHCP-Server sollte auf diese Discover-Nachricht mit den angefragten Parametern eine Offer-Antwort senden (Abbildung 4).
Abb. 4: DHCP-Serverantwort mit den angefragten Einstellungen
Name-Protection-Status herleiten
Eine weitere wichtige Einstellung, die beim Missbrauch dynamischer DHCP-DNS-Updates zum Einsatz kommt, ist Name Protection. Diese Einstellung legt fest, obbestimmte Überschreibeangriffe möglich sind. Wir können den Name-Protection-Status nicht direkt abfragen, aber es gibt einen einfachen Weg in vier Schritten, ihn herzuleiten.
Einen DNS-Datensatz mit einem DHCP DNS Dynamic Update erstellen
Prüfen, ob ein Datensatz A erstellt wurde
Den DNS-Server nach einem DHCID-Datensatz mit demselben Namen abfragen
Wenn es einen DHCID-Datensatz neben dem A-Datensatz gibt, ist Name Protection aktiviert
Um ein DHCP DNS Dynamic Update mit dhclient aufzurufen, fügen wir der Konfigurationsdatei die folgenden Zeilen hinzu:
send fqdn.fqdn = “kali.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
In den ersten beiden Zeilen wird die FQDN-Option mit dem Server-Flag hinzugefügt, die erforderlich ist, damit der DHCP-Server den DNS-Datensatz für uns registriert. Die dritte Zeile ist optional und ermöglicht das Hinzufügen einer Server Identifier DHCP-Option, um einen bestimmten DHCP-Server anzugreifen, wenn mehrere vorhanden sind.
Nach dem Ausführen von dhclient können wir nslookup verwenden, um den DNS-Zielserver abzufragen und nach einem DHCID-Datensatz zu suchen (Abbildung 5).
Abb. 5: Überprüfen des Name-Protection-Status mit nslookup
In diesem Fall wurde ein DHCID-Datensatz erstellt, was darauf hinweist, dass Name Protection aktiviert ist.
Eine DHCP DNS Dynamic Updates-Konfiguration herleiten
Es gibt drei Optionen, die bestimmen, in welchen Fällen der DHCP-Server DNS-Datensätze für Clients erstellt (Abbildung 6). Wenn Angreifer wissen, welche Einstellung verwendet wird, können sie DHCP-Anfragen abfragen und diejenigen identifizieren, die zur Erstellung eines verwalteten Datensatzes führen. Auf diese Weise werden potenzielle Ziele für das Überschreiben von verwalteten Datensätzen, also das Fälschen von Datensätzen, die vom DHCP-Server erstellt wurden, identifiziert.
Die drei möglichen Einstellungen lauten:
Nur dynamisch aktualisieren, wenn vom Client angefordert. Dies ist die Standardoption, die nur dann einen DNS-Datensatz erstellt, wenn eine FQDN-Option in der Anfrage vorhanden ist und das Server-Flag festgelegt ist.
Immer dynamisch aktualisieren. Ein DNS-Datensatz wird für jede DHCP-Anfrage mit einer FQDN-Option erstellt, unabhängig vom Wert des Server-Flags.
Dynamisch aktualisieren für Clients, die keine Aktualisierungen anfordern. Ein DNS-Datensatz wird für Clients erstellt, auch wenn die FQDN-Option nicht vorhanden ist – der FQDN basiert auf der DHCP-Option Hostname. Dies soll alte DHCP-Clients unterstützen, die die FQDN-Option nicht verwenden.
Abb. 6: DHCP DNS Dynamic Update-Einstellungen
Diese Einstellung kann anhand ihrer „Nebenwirkungen“ hergeleitet werden: Wir lösen unter den verschiedenen Bedingungen ein DHCP DNS Dynamic Update aus und fragen den DNS-Server ab, um zu prüfen, ob ein Datensatz erstellt wurde. Dies kann mithilfe von dhclient erfolgen, um eine IP-Adresse zu leasen und den DNS-Server mit „nslookup“ abzufragen.
Die erforderliche Konfiguration von dhclient wird für jede der möglichen Einstellungen getestet und lautet wie folgt:
Datensätze für Clients erstellen, die keine Aktualisierungen anfordern
# Only include the hostname option, without the FQDN option
send host-name = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Datensätze immer erstellen (wenn die FQDN-Option vorhanden ist)
# Include the FQDN option, without the server update flag
send fqdn.fqdn = “test.aka.test”;
send dhcp-server-identifier 172.25.14.123;
Datensätze nur erstellen, wenn vom Client angefordert
# Include the FQDN option and the server update flag
send fqdn.fqdn = “test.aka.test”;
send fqdn.server-update on;
send dhcp-server-identifier 172.25.14.123;
Beschränkungen der Adresse der gefälschten Datensätze
Damit unser Angriff effektiv ist, müssen die gefälschten DNS-Datensätze auf unser kontrolliertes Gerät verweisen. Mit DHCP-DNS-Spoofing verlassen wir uns auf den DHCP-Server, um diese DNS-Datensätze zu erstellen. Leider können wir keine beliebige IP-Adresse auswählen – der DHCP-Server hat einen definierten Umfang interner IP-Adressen und lehnt es ab, eine IP-Adresse außerhalb dieses Bereichs zu leasen (und anschließend einen DNS-Datensatz für diese zu erstellen).
Aus diesem Grund gibt es zwei Einschränkungen bei der Adresse, an die wir die Kommunikation weiterleiten:
Die Adresse darf sich nicht außerhalb des Netzwerks befinden: Eine externe IP-Adresse kann nicht vom DHCP-Server geleast werden und daher nicht beim Spoofing verwendet werden.
Die Adresse darf nicht von einem Gerät mit einer statischen IP-Adresse stammen: Wenn auf einem Gerät eine statische IP-Adresse konfiguriert ist, befindet sich diese Adresse wahrscheinlich nicht im Lease-Pool eines DHCP-Servers und kann daher nicht beim Spoofing verwendet werden.
Da wir Zugriff auf ein internes Gerät haben, das eine dynamische IP-Adresse verwenden kann, können wir einfach jede vom DHCP-Server angebotene Adresse für unsere gefälschten Datensätze verwenden.
Um sicherzustellen, dass wir bei der Durchführung zusätzlicher Aktionen dieselbe Adresse verwenden, können wir die Option Requested IP Address nutzen, indem wir die folgende Zeile zur Konfiguration von dhclient hinzufügen:
send dhcp-requested-address 172.25.14.55;
Mehrere DNS-Datensätze schreiben
Wenn wir DHCP-DNS-Spoofing durchführen, möchten wir höchstwahrscheinlich mehrere DNS-Datensätze fälschen, anstatt nur einen einzigen. Das Ziel ist, den Traffic von so vielen Opfern wie möglich umzuleiten. Wenn wir jedoch versuchen, mehrere DNS-Datensätze auf dieselbe Ziel-IP zu verweisen, tritt ein Problem auf.
Nachdem ein DHCP-Server eine bestimmte IP-Adresse an einen Host geleast hat, kann sie nicht von anderen Clients geleast werden. Dieses Verhalten soll IP-Konflikte zwischen verschiedenen Clients verhindern. Wenn wir eine IP-Adresse mit einem bestimmten FQDN zur Durchführung eines DDSpoof leasen, wird diese IP-Adresse aus dem Adressen-Pool des Servers entfernt. Wenn wir versuchen, dieselbe IP-Adresse erneut mit einem anderen FQDN zu leasen, bietet der Server eine andere Adresse an (Abbildung 7).
Abb. 7: DHCP-Lease-Prozess bei Verwendung der angefragten Adresse
Wir können dieses Problem nicht lösen, indem wir den vorherigen Lease erneut leasen, da dies ein dynamisches DNS-Update durch den DHCP-Server auslösen würde. Und das führt zur Löschung des veröffentlichten Datensatzes, wodurch wiederum der zuvor gespoofte Datensatz entfernt werden würde (Abbildung 8).
Abb. 8: DHCP-Release führt zum Löschen des zugehörigen DNS-Datensatzes
Unsere Ziele sind also:
die IP-Adresse freizugeben, d. h. den Lease-Eintrag vom DHCP-Server zu entfernen und ihn an den Adressen-Pool zurückzugeben (damit wir einen neuen DNS-Datensatz registrieren können).
das Löschen des vorhandenen gefälschten DNS-Datensatzes zu verhindern.
Wir haben ein interessantes Verhalten/einen interessanten Fehler gefunden, mit dem wir genau das tun können.
Wir senden ein DHCP-Anfragepaket mit den folgenden Parametern an den DHCP-Server, der derzeit unsere IP-Adresse least:
Die Client-MAC-Adresse, die verwendet wurde, um das vorhandene DHCP-Lease vom Server anzufordern
Die Server-ID eines Servers, der sich von unserem Zielserver unterscheidet
Wenn wir diese Broadcast-Nachricht sehen, geht unser DHCP-Zielserver davon aus, dass wir eine neue IP-Adresse von einem anderen Server anfordern, sodass wir die vorhandene (geleaste) Adresse nicht mehr benötigen. Anschließend wird der IP-Lease gelöscht, ohne den zugehörigen DNS-Datensatz zu entfernen (Abbildung 9). Warum der DNS-Datensatz nicht gelöscht wird, ist nicht klar. Wir vermuten, dass es sich um einen Logikfehler handeln könnte.
Abb. 9: Löschen eines Lease-Eintrags ohne Löschen des zugehörigen DNS-Datensatzes
Sehen wir uns das in der Praxis an
Wir möchten zwei DNS-Datensätze erstellen, die auf dieselbe IP verweisen. Wir erstellen den ersten Datensatz mit dhclient wie oben beschrieben. Unser Datensatz wird erstellt – und wenn wir uns die Lease-Tabelle für den DHCP-Server ansehen, erkennen wir, dass unser Lease dort angezeigt wird (Abbildung 10).
Abb. 10: Tabelleneintrag DHCP-Lease
Wir ändern jetzt die Option dhcp-server-identifier dhclient in der Konfigurationsdatei, damit sie auf eine andere IP-Adresse verweist, führen dhclient aus und stellen fest, dass unser Lease gelöscht wurde.
Nun können wir dhclient einfach erneut mit einem anderen FQDN ausführen und gleichzeitig dieselbe IP-Adresse anfordern und einen zweiten Datensatz erstellen (Abbildung 11).
Abb. 11: Mehrere DNS-Angreiferdatensätze verweisen auf dieselbe IP-Adresse
Wir stellen vor: DDSpoof.py
Wir haben alle Funktionen und Techniken kombiniert, die in dieser Blogreihe beschrieben wurden, und DDSpoof erstellt – ein Toolkit, das die Performance von DHCP-DNS-Angriffen ermöglicht. Dieses Python-Tool führt die DHCP-Serveraufzählung sowie nutzerdefinierte DHCP-DNS-Befehle aus und identifiziert potenzielle Spoofing-Ziele. Die Funktionalität von DDSpoof ist in diesem Repository aufgeführt.
In den nächsten Abschnitten untersuchen wir mehrere Angriffsszenarien, die mit DDSpoof ausgeführt werden können.
DDSpoof einrichten
Wir führen einen Kali-Linux-Rechner in unserem Zielnetzwerk aus, ohne Domain-Anmeldedaten. Zunächst führen wir DDSpoof aus, um das Netzwerk zu scannen und potenzielle Ziele zu identifizieren (unter Angabe der Schnittstelle, die zum Senden und Empfangen von Paketen verwendet werden soll; Abbildung 12).
Abb. 12: Erste DDSpoof-Aufzählung
Wir sehen, dass DDSpoof Folgendes ausführt:
Identifiziert alle erreichbaren DHCP-Server und deren Konfigurationen
Bestimmt den Name-Protection-Status
Überprüft, ob unsere aktuelle IP-Adresse auf unserem Zielserver zum Leasing verfügbar ist
In diesem Beispiel steht unsere IP-Adresse nicht für das Leasing auf unserem Zielserver zur Verfügung. Daher wandeln wir sie manuell in die vom Server angebotene Adresse um (Abbildung 13).
Abb. 13: Umwandlung der IP-Adresse in eine auf dem DHCP-Server verfügbare Adresse
Wir sind jetzt bereit, mit dem Spoofing zu beginnen.
DHCP DNS-Spoofing
Um unser erstes DHCP DNS-Spoofing durchzuführen, möchten wir erfolglose Versuche zur Namensauflösung identifizieren und DNS-Datensätze für diese erstellen, die auf unser Gerät verweisen. Dazu verwenden wir den DDSpoof-Befehl „start-llmnr“. Dieser Befehl aktiviert einen LLMNR-Sniffer. Dadurch werden wir über LLMNR-Abfragen im Netzwerk, die uns zu potenziellen Spoofing-Zielen führen könnten, benachrichtigt (Abbildung 14).
Abb. 14: Verwendung des LLMNR-Sniffer von DDSpoof zur Identifizierung von Spoofing-Zielen
Hier sehen wir, dass der Sniffer in der Lage war, den Namen „files.aka.test“ zu identifizieren. Mit dem Befehl „write-record“ können wir jetzt versuchen, den DNS-Namen zu registrieren (Abbildung 15).
Abb. 15: Verwendung von DDSpoof zum Spoofen eines DNS-Datensatzes für den Zielnamen
Wie wir sehen, hat DDSpoof den DNS-Datensatz, der auf unsere IP-Adresse verweist, erfolgreich erstellt! Dies können wir mit nslookup überprüfen (Abbildung 16).
Abb. 16: Verwendung von nslookup als Bestätigung, dass der Datensatz erfolgreich erstellt wurde
Wenn ein Host im Netzwerk wieder versucht, den Namen files.aka.test aufzulösen, wird er zu unserem kontrollierten Gerät geleitet.
Nachdem wir unseren Angriff durchgeführt haben, können wir mit dem Befehl delete-record unseren gefälschten Datensatz löschen (Abbildung 17).
Abb. 17: Verwendung von DDSpoof zur Löschung des gespooften Datensatzes
DHCP-DNS überschreiben
Eine weitere Option ist das Überschreiben von DHCP DNS. Unser DHCP-Zielserver ist auch ein DNS-Server, wie in Abbildung 12 zu sehen. Dies deutet darauf hin, dass der Server auch ein Domain Controller (DC) sein kann, da der DNS-Server in Active Directory-Umgebungen häufig auf einem DC installiert ist. Wir können dies mit dem folgenden „nmap“-Befehl überprüfen:
Nmap -p389 -sV 172.25.14.123
Abb. 18: Nmap-Output, der bestätigt, dass der Server ein Domain-Controller ist
Wenn keine DNS-Anmeldedaten konfiguriert wurden, können wir jeden Datensatz in der ADI-Zone überschreiben. Nehmen wir an, wir haben einen Host mit dem Namen „file-server.aka.test“ identifiziert (Abbildung 19).
Abb. 19: nslookup-Ergebnisse für file-server.aka.test
Wir können versuchen, den DNS-Datensatz mit dem DDSpoof-Befehl write-record zu überschreiben. Wenn schwache DNS-Anmeldedaten konfiguriert wurden, sollte dies fehlschlagen. In diesem Fall wurden jedoch keine schwachen DNS-Anmeldedaten konfiguriert. Der Datensatz wurde also erfolgreich überschrieben (Abbildung 20).
Abb. 20: Verwendung von DDSpoof zur Durchführung einer DHCP-DNS-Überschreibung des file-server-DNS-Datensatzes
Abb. 21: Verwendung von nslookup als Bestätigung, dass der Datensatz erfolgreich überschrieben wurde
Name Protection umgehen
In einem anderen Szenario führen Sie den DDSpoof-Befehl start-dhcp aus, der DHCP-Traffic erfasst und DHCP-Request-Nachrichten identifiziert (Abbildung 22).
Abb. 22: Verwendung des DHCP-Sniffers von DDSpoof zur Identifizierung potenzieller verwalteter Datensätze
In diesem Beispiel wird ein Gerät mit dem Namen ubuntu-server.aka.test identifiziert, das eine DHCP-Anfrage mit seinem FQDN gesendet hat. Dies könnte dazu führen, dass der DHCP-Server einen DNS-Datensatz erstellt, was ein Überschreiben von verwalteten Datensätzen zur Folge hat (beachten Sie, dass ein verwalteter Datensatz für Hosts erstellt wird, die nicht von Windows stammen, da diese nicht Teil der Domain sind und daher nicht direkt mit dem DNS-Server kommunizieren können.)
Aber es gibt ein Problem. Dieses Mal ist bei unserem DHCP-Zielserver Name Protection aktiviert (Abbildung 23).
Abb. 23: DDSpoof zählt einen DHCP-Server mit aktivierter Name Protection auf
Wenn wir alle DNS-Datensätze nach unserem Ziel ubuntu-server.aka.testabfragen, sehen wir, dass tatsächlich ein DHCID-Datensatz vorhanden ist (Abbildung 24).
Abb. 24: nslookup-Output mit DHCID-Datensatz
Aber keine Sorge: Wir wissen bereits, dass Name Protection einfach umgangen werden kann!
Dazu müssen wir einfach ein DHCP-Release mit einer Client-ID (CID) senden – im Wesentlichen die Client-MAC-Adresse –, die mit dem ursprünglichen Eigentümer des Datensatzes übereinstimmt. Dies führt dazu, dass der DHCP-Server den Datensatz löscht.
Dazu nutzen wir den Befehl set-cid . Wir füttern ihn mit der Ziel-CID, die wir zuvor erhalten haben, damit DDSpoof den ursprünglichen DHCP-Client imitiert. Danach führen wir den Befehl delete-record zum Entfernen unseres Zieldatensatzes aus (Abbildung 25).
Abb. 25: Verwenden von DDSpoof zum Löschen eines mit Name Protection geschützten DNS-Datensatzes
Jetzt können wir den Namen einfach mit dem Befehl „write-record“ registrieren (Abbildung 26).
Abb. 26: Verwendung von DDSpoof zum Erstellen eines neuen Datensatzes nach dem Löschen des ursprünglichen Datensatzes unter Umgehung von Name Protection
Zusammenfassung
In den in diesem Beitrag untersuchten Angriffsszenarien zeigen wir, wie es möglich ist, verschiedene DNS-Datensätze in Active Directory-Domains aus einem nicht authentifizierten Kontext zu fälschen. Diese Fähigkeit ist sehr flexibel und kann von Angreifern auf verschiedene Weise missbraucht werden, z. B. um:
Zugriff auf Windows-Geräte und Intercept NTLM- oder Kerberos-Authentifizierungen zu erhalten, um weitere Relay- oder Brute-Force-Angriffe zu ermöglichen.
Anwendungen anzugreifen, die unsichere Protokolle ausführen, und vertrauliche Daten abzufangen.
DNS-Datensätze interner Sicherheitsserver anzugreifen, wie Antivirenprogramme oder SIEM, und den Zugriff auf diese zu blockieren.
Dies sind nur einige Beispiele dafür, wie diese Fähigkeit von Cyberkriminellen missbraucht werden könnte; es gibt viele andere.
Sicherheitsteams aufgepasst
Die Angriffsfläche, die von DHCP DNS Dynamic Updates offengelegt wird, ist sehr wirkungsvoll, und da Microsoft nicht plant, sich damit zu befassen, wird es dieses Risiko auch in Zukunft geben. Wir ermutigen Sicherheitsteams, die folgenden Tools zu verwenden, um die Risiken von DHCP-DNS-Spoofing zu identifizieren und zu mindern – idealerweise, bevor Angreifer im Vorteil sind:
Invoke-DHCPCheckup: Identifizieren Sie DHCP- und DNS-Konfigurationen in Active Directory.
DDSpoof: Heben Sie Risiken hervor und testen Sie Ihre Widerstandsfähigkeit gegenüber der DHCP DNS Dynamic Update-Angriffsfläche.
