zyn3rgy/ldaprelayscanVerifica le protezioni LDAP relative al relay dell'autenticazione NTLM
Uno strumento per verificare la presenza di protezioni lato server LDAP sui Domain Controller per quanto riguarda il relay dell'autenticazione NTLM. Se sei interessato ai dettagli specifici dell'enumerazione basata sugli errori, vedi qui. Per i dettagli su cosa si può fare quando si identifica una mancanza di protezioni LDAP, consulta la sezione riferimenti.
Ci sono un paio di protezioni lato server quando si tenta di effettuare relay dell'autenticazione NTLM verso LDAP sui Domain Controller. Le protezioni LDAP che questo strumento tenta di enumerare includono:
L'applicazione del channel binding per LDAP su SSL/TLS può essere determinata da una prospettiva non autenticata. Questo perché l'errore associato a un client LDAP che non è in grado di eseguire correttamente il channel binding si verifica prima che le credenziali vengano validate durante il processo di bind LDAP.
Tuttavia, per determinare se la protezione lato server per LDAP standard viene applicata (requisiti di integrità della firma del server), le credenziali del client devono prima essere validate durante il bind LDAP. Il potenziale errore che identifica l'applicazione di questa protezione viene rilevato da una prospettiva autenticata.
Si consiglia di utilizzare Docker o un ambiente virtuale Python quando si esegue questo progetto.
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 -hNOTA: Il DNS deve risolvere correttamente. Se stai instradando il traffico tramite SOCKS o se stai operando su un host non appartenente al dominio, assicurati che funzioni.
Lo strumento ha due metodi: LDAPS (predefinito) e BOTH. LDAPS richiede solo l'indirizzo IP del domain controller, perché questo controllo può essere eseguito senza autenticazione. Il metodo BOTH richiede un nome utente e una password oppure un hash NT. Il dominio di Active Directory non è necessario, verrà determinato tramite bind LDAP anonimo.
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
NOTA: La possibilità di usare SOCKS viene passata tramite una variabile d'ambiente
PROXY_CONFIG. Se è necessario SOCKS, sarà anche necessario utilizzare il flag--network=hostper instradare correttamente il traffico. Vedi gli esempi qui sotto.
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
Su un Domain Controller che è stato aggiornato dopo CVE-2017-8563, esiste la possibilità di applicare il channel binding LDAPS. La policy specifica si chiama Domain Controller: LDAP server channel binding token requirements e può essere impostata su Never, When supported o Always. Inoltre, non è richiesta per impostazione predefinita (al momento della stesura di questo documento).
Decifrare e monitorare il traffico LDAP su SSL/TLS su un Domain Controller ha permesso di identificare una differenza negli errori durante i tentativi di bind quando il channel binding viene applicato rispetto a quando non lo è. Quando si tenta un bind verso LDAP su SSL/TLS utilizzando credenziali non valide, si riceverà il previsto resultCode 49 e nel contenuto del messaggio di errore vedrai data 52e. Tuttavia, quando il channel binding viene applicato e il client LDAP non calcola e include il Channel Binding Token (CBT), il resultCode sarà comunque 49, ma il contenuto del messaggio di errore conterrà data 80090346, che significa SEC_E_BAD_BINDINGS oppure che i bindings del canale SSPI (Security Support Provider Interface) forniti dal client non erano corretti.
NOTA: Menzioni dell'errore
data 8009034durante il bind LDAP su SSL/TLS [1] [2] [3] [4] [5]
Questo errore specifico rende abbastanza semplice gestire il caso in cui la policy Domain Controller: LDAP server channel binding token requirements è impostata su Always. Basta tentare un bind LDAPS basato su NTLM utilizzando un client che non supporta il channel binding e cercare data 80090346 nell'errore di risposta. Ma cosa succede quando la policy non è impostata su Always? E quando è impostata su When supported? La risposta è: effettuare il bind su LDAPS con autenticazione basata su NTLM e calcolare deliberatamente in modo errato le informazioni di channel binding.
Innanzitutto, abbiamo bisogno di un client LDAP che supporti il channel binding. Verrà utilizzata l'implementazione di SkelSec's in msldap per realizzare una PoC. Il channel binding appare come un valore AV_PAIR durante il processo di challenge/response NTLM, in particolare all'interno del Type 3 o AUTHENTICATE_MESSAGE. Ecco un altro sguardo al traffico LDAPS decifrato su un Domain Controller per vedere come appare un tentativo di bind da parte di un client che supporta il channel binding:
Calcolare deliberatamente in modo errato questo valore, quando la policy in questione è impostata su When supported, produrrà lo stesso errore data 80090346. Questo ci dà la possibilità di distinguere tra tutte le possibili impostazioni di questa policy così com'è attualmente, da una prospettiva non autenticata. Il modo in cui questo valore viene calcolato deliberatamente in modo errato è importante, perché semplicemente sostituire manualmente il valore durante il challenge/response invaliderà il MIC.
Su un Domain Controller, la policy chiamata Domain Controller: LDAP server signing requirements è impostata su None, Require signing, oppure semplicemente non è definita. Quando non è definita, per impostazione predefinita non richiede la firma (al momento della stesura di questo documento). L'errore che identifica questa protezione come richiesta si verifica quando un tentativo di bind sicily NTLM o semplice risponde con un resultCode di 8, che significa strongerAuthRequired. Questo si verifica solo se le credenziali durante il bind LDAP vengono validate.
Alcune risorse inestimabili per contestualizzare questo materiale e come si inserisce negli scenari di attacco comuni.