zyn3rgy/ldaprelayscanPrüft LDAP-Schutzmaßnahmen in Bezug auf das Relay von NTLM-Authentifizierung.
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.
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:
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.
Es wird empfohlen, beim Ausführen dieses Projekts entweder Docker oder eine Python-Virtualenv-Umgebung zu verwenden.
git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScandocker build -f docker/Dockerfile -t ldaprelayscan .docker run ldaprelayscan -hgit clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScanvirtualenv envsource venv/bin/activatepython3 -m pip install -r requirements_exact.txtpython3 LdapRelayScan.py -hHINWEIS: 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
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
HINWEIS: Die Möglichkeit, SOCKS zu verwenden, wird über die Umgebungsvariable
PROXY_CONFIGübergeben. Wenn SOCKS erforderlich ist, muss auch das Flag--network=hostverwendet 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
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 8009034während LDAP-over-SSL/TLS-Bindings [1] [2] [3] [4] [5]
Dieser spezifische Fehler macht es leicht genug, den Fall zu berücksichtigen, wenn die Richtlinie Domain Controller: LDAP server channel binding token requirements auf Always gesetzt ist. Versuche einfach einen NTLM-basierten LDAPS-Bind mit einem Client, der kein Channel-Binding unterstützt, und suche im Fehler in der Antwort nach data 80090346. Was aber, wenn die Richtlinie nicht auf Always gesetzt ist, was, wenn sie auf When supported gesetzt ist? Die Antwort lautet: Binde mit NTLM-basierter Authentifizierung an LDAPS und berechne die Channel-Binding-Informationen absichtlich falsch.
Zunächst benötigen wir einen LDAP-Client, der Channel-Binding unterstützt. SkelSec's Implementierung davon in msldap wird verwendet, um einen PoC umzusetzen. Channel-Binding erscheint während des NTLM-Challenge/Response-Prozesses als AV_PAIR-Wert, genauer gesagt innerhalb des Type 3 oder der AUTHENTICATE_MESSAGE. Hier ein weiterer Blick auf entschlüsselten LDAPS-Datenverkehr auf einem Domänencontroller, um zu sehen, wie ein Bind-Versuch eines Clients aussieht, der Channel-Binding unterstützt:
Das absichtliche falsche Berechnen dieses Werts, wenn die betreffende Richtlinie auf When supported gesetzt ist, erzeugt denselben Fehler data 80090346. Dies gibt uns die Möglichkeit, aus einer nicht authentifizierten Perspektive zwischen allen derzeit möglichen Einstellungen dieser Richtlinie zu unterscheiden. Wie dieser Wert absichtlich falsch berechnet wird, ist wichtig, denn ein bloßes manuelles Ersetzen des Werts während des Challenge/Response würde den MIC ungültig machen.
Auf einem Domänencontroller ist die Richtlinie mit der Bezeichnung Domain Controller: LDAP server signing requirements auf None, Require signing gesetzt oder einfach nicht definiert. Wenn sie nicht definiert ist, wird standardmäßig keine Signatur verlangt (zum Zeitpunkt der Erstellung dieses Artikels). Der Fehler, der diese Schutzmaßnahme als erforderlich identifiziert, tritt auf, wenn ein sicily-NTLM- oder einfacher-Bind-Versuch mit einem resultCode von 8 antwortet, was strongerAuthRequired bedeutet. Dies geschieht nur, wenn die Anmeldeinformationen während des LDAP-Bind validiert werden.
Einige unschätzbare Ressourcen zur Kontextualisierung dieses Materials und wie es in gängige Angriffsszenarien passt.