zyn3rgy/ldaprelayscanComprueba las protecciones LDAP relativas al relay de autenticación NTLM
Una herramienta para comprobar en los controladores de dominio las protecciones del servidor LDAP con respecto al relay de autenticación NTLM. Si estás interesado en los detalles específicos de la enumeración basada en errores, consulta más abajo. Para obtener detalles sobre qué se puede hacer cuando identificas una falta de protecciones LDAP, consulta la sección de referencias.
Hay un par de protecciones del lado del servidor cuando se intenta hacer relay de autenticación NTLM sobre LDAP en controladores de dominio. Las protecciones LDAP que esta herramienta intenta enumerar incluyen:
La aplicación del enlace de canal para LDAP sobre SSL/TLS puede determinarse desde una perspectiva no autenticada. Esto se debe a que el error asociado con un cliente LDAP que no puede llevar a cabo el enlace de canal correctamente ocurrirá antes de que las credenciales se validen durante el proceso de bind LDAP.
Sin embargo, para determinar si la protección del lado del servidor del LDAP estándar está aplicada (requisitos de integridad de firma del servidor), las credenciales del cliente deben validarse primero durante el bind LDAP. El posible error que identifica la aplicación de esta protección se identifica desde una perspectiva autenticada.
Se recomienda usar Docker o un entorno virtual de Python al ejecutar este proyecto.
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: El DNS debe resolverse correctamente. Si estás enrutando a través de SOCKS o ejecutando en un host que no está unido al dominio, asegúrate de que esto funcione.
La herramienta tiene dos métodos: LDAPS (el predeterminado) y BOTH. LDAPS solo requiere la dirección IP de un controlador de dominio, porque esta comprobación se puede realizar sin autenticación. El método BOTH requerirá un nombre de usuario y contraseña o un hash NT. No se requiere el dominio de Active Directory; se determinará mediante un bind LDAP anónimo.
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 capacidad de usar SOCKS se pasa mediante la variable de entorno
PROXY_CONFIG. Si se requiere SOCKS, también será necesario usar el flag--network=hostpara enrutar correctamente el tráfico. Ver los ejemplos a continuación.
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
En un controlador de dominio que ha sido parcheado desde CVE-2017-8563, ha existido la capacidad de aplicar el enlace de canal LDAPS. La política específica se llama Domain Controller: LDAP server channel binding token requirements y puede establecerse en Never, When supported o Always. Esto tampoco es obligatorio por defecto (al momento de escribir esto).
Descifrar y monitorear el tráfico LDAP sobre SSL/TLS en un controlador de dominio permitió identificar una diferencia en los errores durante los intentos de bind cuando el enlace de canal está aplicado frente a cuando no lo está. Al intentar un bind a LDAP sobre SSL/TLS con credenciales no válidas, recibirás el esperado resultCode 49, y en el contenido del mensaje de error verás data 52e. Sin embargo, cuando el enlace de canal está aplicado y el cliente LDAP no calcula ni incluye el token de enlace de canal (CBT), el resultCode seguirá siendo 49, pero el contenido del mensaje de error contendrá data 80090346, lo que significa SEC_E_BAD_BINDINGS o que los enlaces de canal SSPI del cliente eran incorrectos.
NOTA: Las menciones del error
data 8009034durante el bind de LDAP sobre SSL/TLS [1] [2] [3] [4] [5]
Este error específico hace que sea bastante fácil tenerlo en cuenta cuando la política Domain Controller: LDAP server channel binding token requirements está establecida en Always. Simplemente intenta un bind LDAPS basado en NTLM usando un cliente que no soporte el enlace de canal y busca el data 80090346 dentro del error en la respuesta. Pero ¿qué pasa cuando la política no está establecida en Always? ¿Qué pasa cuando está establecida en When supported? La respuesta es: hacer bind a LDAPS con autenticación basada en NTLM y calcular deliberadamente mal la información del enlace de canal.
Primero, necesitamos un cliente LDAP que soporte el enlace de canal. Se usará la implementación de SkelSec de esto en msldap para implementar una PoC. El enlace de canal aparece como un valor AV_PAIR durante el proceso de challenge/response de NTLM, específicamente dentro del Tipo 3 o AUTHENTICATE_MESSAGE. Aquí hay otra vista del tráfico LDAPS descifrado en un controlador de dominio para ver cómo se ve un intento de bind de un cliente que soporta el enlace de canal:
Calcular deliberadamente mal este valor, cuando la política en cuestión está establecida en When supported, producirá el mismo error data 80090346. Esto nos da la capacidad de diferenciar entre todas las configuraciones posibles de esta política tal como existe actualmente, desde una perspectiva no autenticada. La forma en que este valor se calcula mal a propósito es importante, porque simplemente reemplazar manualmente el valor durante el challenge/response invalidará el MIC.
En un controlador de dominio, la política llamada Domain Controller: LDAP server signing requirements se establece en None, Require signing, o simplemente no está definida. Cuando no está definida, por defecto no se requiere firma (al momento de escribir esto). El error que identifica que esta protección es obligatoria ocurre cuando un intento de bind sicily NTLM o simple responde con un resultCode de 8, lo que significa strongerAuthRequired. Esto solo ocurrirá si las credenciales durante el bind LDAP son validadas.
Algunos recursos invaluables para contextualizar este material y cómo encaja en escenarios de ataque comunes.