zyn3rgy/ldaprelayscanVérifie les protections LDAP concernant le relais de l'authentification NTLM
Un outil pour vérifier les protections du serveur LDAP des contrôleurs de domaine concernant le relais d'authentification NTLM. Si vous êtes intéressé par les spécificités de l'énumération basée sur les erreurs, voir ci-dessous. Pour plus de détails sur ce qui peut être fait lorsqu'aucune protection LDAP n'est détectée, voir la section références.
Il existe plusieurs protections côté serveur lors d'une tentative de relais d'authentification NTLM vers LDAP sur les contrôleurs de domaine. Les protections LDAP que cet outil tente d'énumérer sont :
L'application de la liaison de canal pour LDAP sur SSL/TLS peut être déterminée depuis une perspective non authentifiée. En effet, l'erreur associée à un client LDAP incapable d'effectuer correctement la liaison de canal survient avant la validation des identifiants lors du processus de liaison LDAP.
Cependant, pour déterminer si la protection côté serveur du LDAP standard est appliquée (exigences d'intégrité de signature du serveur), les identifiants du client doivent d'abord être validés lors de la liaison LDAP. L'erreur potentielle identifiant l'application de cette protection est détectée depuis une perspective authentifiée.
Il est recommandé d'utiliser Docker ou un environnement virtuel Python pour exécuter ce projet.
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 -hREMARQUE : Le DNS doit être correctement résolu. Si vous passez par SOCKS ou si vous exécutez l'outil sur une machine non jointe au domaine, assurez-vous que cela fonctionne.
L'outil dispose de deux méthodes, LDAPS (par défaut) et BOTH. LDAPS ne nécessite qu'une adresse IP de contrôleur de domaine, car cette vérification peut être effectuée sans authentification. La méthode BOTH nécessite un nom d'utilisateur et un mot de passe ou un hash NT. Le domaine Active Directory n'est pas requis, il sera déterminé via une liaison LDAP anonyme.
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
REMARQUE : La prise en charge de SOCKS est transmise via une variable d'environnement
PROXY_CONFIG. Si SOCKS est requis, le drapeau--network=hostdevra également être utilisé pour router correctement le trafic. Voir les exemples ci-dessous.
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
Sur un contrôleur de domaine corrigé depuis CVE-2017-8563, la capacité d'appliquer la liaison de canal LDAPS existe. La stratégie spécifique s'appelle Domain Controller: LDAP server channel binding token requirements et peut être définie sur Never, When supported ou Always. Elle n'est également pas requise par défaut (au moment de la rédaction de ce document).
Le déchiffrement et la surveillance du trafic LDAP sur SSL/TLS sur un contrôleur de domaine ont permis d'identifier une différence dans les erreurs lors des tentatives de liaison selon que la liaison de canal est appliquée ou non. Lors d'une tentative de liaison LDAP sur SSL/TLS avec des identifiants invalides, vous recevrez le resultCode 49 attendu, et dans le contenu du message d'erreur vous verrez data 52e. Cependant, lorsque la liaison de canal est appliquée et que le client LDAP ne calcule pas et n'inclut pas le jeton de liaison de canal (CBT), le resultCode sera toujours 49, mais le contenu du message d'erreur contiendra data 80090346, ce qui signifie SEC_E_BAD_BINDINGS ou que les liaisons de canal SSPI (Supplied Support Provider Interface) du client étaient incorrectes.
REMARQUE : Mentions de l'erreur
data 8009034lors de la liaison LDAP sur SSL/TLS [1] [2] [3] [4] [5]
Cette erreur spécifique permet de prendre en compte facilement le cas où la stratégie Domain Controller: LDAP server channel binding token requirements est définie sur Always. Il suffit de tenter une liaison LDAPS basée sur NTLM avec un client qui ne prend pas en charge la liaison de canal et de rechercher data 80090346 dans l'erreur en réponse. Mais qu'en est-il lorsque la stratégie n'est pas définie sur Always, par exemple lorsqu'elle est définie sur When supported ? La réponse est : effectuer une liaison LDAPS avec une authentification basée sur NTLM et calculer délibérément de manière incorrecte les informations de liaison de canal.
Tout d'abord, nous avons besoin d'un client LDAP prenant en charge la liaison de canal. L'implémentation de SkelSec's dans msldap sera utilisée pour implémenter une PoC. La liaison de canal apparaît comme une valeur AV_PAIR lors du processus de défi/réponse NTLM, plus précisément dans le Type 3 ou AUTHENTICATE_MESSAGE. Voici un autre aperçu du trafic LDAPS déchiffré sur un contrôleur de domaine pour voir à quoi ressemble une tentative de liaison d'un client prenant en charge la liaison de canal :
Le calcul volontairement incorrect de cette valeur, lorsque la stratégie en question est définie sur When supported, produira la même erreur data 80090346. Cela nous permet de différencier tous les paramètres possibles de cette stratégie tels qu'ils existent actuellement, depuis une perspective non authentifiée. La manière dont cette valeur est volontairement mal calculée est importante, car le simple remplacement manuel de la valeur pendant le processus de défi/réponse invaliderait le MIC.
Sur un contrôleur de domaine, la stratégie nommée Domain Controller: LDAP server signing requirements est définie sur None, Require signing, ou elle n'est simplement pas définie. Lorsqu'elle n'est pas définie, elle n'exige pas la signature par défaut (au moment de la rédaction de ce document). L'erreur qui identifie cette protection comme requise est lorsqu'une tentative de liaison sicily NTLM ou simple répond avec un resultCode de 8, signifiant strongerAuthRequired. Cela ne se produit que si les identifiants lors de la liaison LDAP sont validés.
Quelques ressources inestimables pour contextualiser ce contenu et comprendre comment il s'intègre dans les scénarios d'attaque courants.