LDAP Relay Scan

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.

Sommario

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:

• LDAPS - channel binding
• LDAP - requisiti di firma del server

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.

TL;DR - LDAPS può essere verificato senza autenticazione, ma la verifica di LDAP richiede l'autenticazione.

Installazione

Si consiglia di utilizzare Docker o un ambiente virtuale Python quando si esegue questo progetto.

Docker

1. Assicurati che docker sia installato sulla tua macchina
2. Clona il repository e cambia directory
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Costruisci il container Docker
   • docker build -f docker/Dockerfile -t ldaprelayscan .
4. [opzionale] Assicurati che lo script venga eseguito correttamente
   • docker run ldaprelayscan -h

Ambiente Virtuale Python

1. Assicurati che python virtualenv sia installato sulla tua macchina
2. Clona il repository e cambia directory
   • git clone https://github.com/zyn3rgy/LdapRelayScan.git && cd LdapRelayScan
3. Crea un ambiente virtuale Python per il progetto
   • virtualenv env
4. Attiva l'ambiente virtuale Python
   • source venv/bin/activate
5. Installa le dipendenze con i requisiti esatti di versione
   • python3 -m pip install -r requirements_exact.txt
6. [opzionale] Assicurati che lo script venga eseguito correttamente
   • python3 LdapRelayScan.py -h

Utilizzo

NOTA: 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

Esempi

Esempi di Utilizzo Base / Ambiente Virtuale

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

Esempi di Utilizzo con Docker

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=host per 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

Dettagli Specifici dell'Enumerazione Basata sugli Errori

[LDAPS] Requisiti del Token di Channel Binding

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 8009034 durante il bind LDAP su SSL/TLS [1] [2] [3] [4] [5]

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