LDAP Relay Scan

Ein Tool zur Überprüfung von Domänencontrollern auf LDAP-Server-Schutzmaßnahmen im Hinblick auf das Relay von NTLM-Authentifizierung. Wenn dich die Einzelheiten der fehlerbasierten Enumeration interessieren, siehe unten. Details dazu, was getan werden kann, wenn du ein Fehlen von LDAP-Schutzmaßnahmen feststellst, findest du im Referenzabschnitt.

Zusammenfassung

Es gibt einige serverseitige Schutzmaßnahmen, wenn versucht wird, NTLM-Authentifizierung über LDAP an Domänencontroller weiterzuleiten. Die LDAP-Schutzmaßnahmen, die dieses Tool zu enumerieren versucht, umfassen:

• LDAPS - Channel Binding
• LDAP - Server-Signaturanforderungen

Die Durchsetzung von Channel-Binding für LDAP über SSL/TLS kann aus einer nicht authentifizierten Perspektive festgestellt werden. Dies liegt daran, dass der Fehler, der mit einem LDAP-Client verbunden ist, dem die Fähigkeit zur ordnungsgemäßen Durchführung von Channel-Binding fehlt, auftritt, bevor die Anmeldeinformationen während des LDAP-Bind-Prozesses validiert werden.

Jedoch muss, um festzustellen, ob der serverseitige Schutz des Standard-LDAP durchgesetzt wird (Integritätsanforderungen für die Serversignatur), zuerst die Anmeldeinformationen des Clients während des LDAP-Bind validiert werden. Der potenzielle Fehler, der die Durchsetzung dieses Schutzes identifiziert, wird aus einer authentifizierten Perspektive festgestellt.

TL;DR - LDAPS kann ohne Authentifizierung überprüft werden, aber für die Überprüfung von LDAP ist eine Authentifizierung erforderlich.

Installation

Es wird empfohlen, beim Ausführen dieses Projekts entweder Docker oder eine Python-Virtualenv-Umgebung zu verwenden.

Docker

1. Stelle sicher, dass Docker installiert auf deinem Rechner ist
2. Klone das Repository und wechsle in das Verzeichnis
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Baue den Docker-Container
   • docker build -f docker/Dockerfile -t ldaprelayscan .
4. [optional] Stelle sicher, dass das Skript ordnungsgemäß ausgeführt wird
   • docker run ldaprelayscan -h

Virtuelle Python-Umgebung

1. Stelle sicher, dass python virtualenv auf deinem Rechner installiert ist
2. Klone das Repository und wechsle in das Verzeichnis
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Erstelle eine Python-Virtualenv-Umgebung für das Projekt
   • virtualenv env
4. Aktiviere die Python-Virtualenv-Umgebung
   • source venv/bin/activate
5. Installiere die exakten Versionsabhängigkeiten aus der Requirements-Datei
   • python3 -m pip install -r requirements_exact.txt
6. [optional] Stelle sicher, dass das Skript ordnungsgemäß ausgeführt wird
   • python3 LdapRelayScan.py -h

Verwendung

HINWEIS: DNS muss ordnungsgemäß aufgelöst werden. Wenn du über SOCKS leitest oder auf einem Host ohne Domänenbeitritt arbeitest, stelle sicher, dass dies funktioniert.

Das Tool hat zwei Methoden: LDAPS (Standard) und BOTH. LDAPS erfordert nur die IP-Adresse eines Domänencontrollers, da diese Prüfung ohne Authentifizierung durchgeführt werden kann. Die BOTH-Methode erfordert einen Benutzernamen und ein Passwort oder einen NT-Hash. Die Active-Directory-Domäne ist nicht erforderlich; sie wird über einen anonymen LDAP-Bind ermittelt.

arguments:
  -h, --help        show this help message and exit
  -method method    LDAPS or BOTH - LDAPS checks for channel binding, BOTH checks for LDAP signing and LDAP channel binding [authentication required]
  -dc-ip DC_IP      DNS Nameserver on network. Any DC's IPv4 address should work.
  -u username       Domain username value.
  -timeout timeout  The timeout for MSLDAP client connection.
  -p password       Domain username value.
  -nthash nthash    NT hash of password

Beispiele

Grundlegende / Virtual-Environment-Nutzungsbeispiele

python3 LdapRelayScan.py -method LDAPS -dc-ip 10.0.0.20
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -p badpassword2
python3 LdapRelayScan.py -method BOTH -dc-ip 10.0.0.20 -u domainuser1 -nthash e6ee750a1feb2c7ee50d46819a6e4d25

Docker-Nutzungsbeispiele

HINWEIS: Die Möglichkeit, SOCKS zu verwenden, wird über die Umgebungsvariable PROXY_CONFIG übergeben. Wenn SOCKS erforderlich ist, muss auch das Flag --network=host verwendet werden, um den Datenverkehr korrekt zu leiten. Siehe Beispiele unten.

docker run ldaprelayscan -h
docker run ldaprelayscan -dc-ip 10.0.0.20
docker run ldaprelayscan -dc-ip 10.0.0.20 -method BOTH -u domainuser1 -p secretpass
docker run -e PROXY_CONFIG='socks5 127.0.0.1 9050' --network=host ldaprelayscan -dc-ip 10.0.0.20 -method BOTH -u domainuser1 -p secretpass

Details zur fehlerbasierten Enumeration

[LDAPS] Anforderungen an das Channel-Binding-Token

Auf einem Domänencontroller, der seit CVE-2017-8563 gepatcht wurde, besteht die Möglichkeit, LDAPS-Channel-Binding zu erzwingen. Die spezifische Richtlinie heißt Domain Controller: LDAP server channel binding token requirements und kann auf Never, When supported oder Always gesetzt werden. Dies ist standardmäßig nicht erforderlich (zum Zeitpunkt der Erstellung dieses Artikels).

Das Entschlüsseln und Überwachen von LDAP-over-SSL/TLS-Datenverkehr auf einem Domänencontroller ermöglichte die Identifizierung eines Unterschieds bei Fehlern während Bind-Versuchen, wenn Channel-Binding erzwungen wird, im Vergleich zu wenn dies nicht der Fall ist. Wenn du einen Bind-Versuch an LDAP über SSL/TLS mit ungültigen Anmeldeinformationen durchführst, erhältst du den erwarteten resultCode 49, und im Inhalt der Fehlermeldung siehst du data 52e. Wenn jedoch Channel-Binding erzwungen wird und der LDAP-Client das Channel Binding Token (CBT) nicht berechnet und einfügt, bleibt der resultCode 49, aber der Inhalt der Fehlermeldung enthält data 80090346, was SEC_E_BAD_BINDINGS bedeutet oder dass die Channel-Bindings des vom Client gelieferten Security Support Provider Interface (SSPI) falsch waren.

HINWEIS: Erwähnungen des Fehlers data 8009034 während LDAP-over-SSL/TLS-Bindings [1] [2] [3] [4] [5]

"Never" vs "When supported" vs "Always"