zyn3rgy/ldaprelayscanVerifica as proteções LDAP referentes ao relay da autenticação NTLM.
Uma ferramenta para verificar Controladores de Domínio quanto às proteções do servidor LDAP relacionadas ao relay de autenticação NTLM. Se você tiver interesse nos detalhes da enumeração baseada em erros, veja abaixo. Para detalhes sobre o que pode ser feito quando você identifica a falta de proteções LDAP, consulte a seção de referências.
Existem algumas proteções no lado do servidor ao tentar fazer relay de autenticação NTLM para LDAP em Controladores de Domínio. As proteções LDAP que esta ferramenta tenta enumerar incluem:
A imposição do channel binding para LDAP sobre SSL/TLS pode ser determinada a partir de uma perspectiva não autenticada. Isso ocorre porque o erro associado a um cliente LDAP sem a capacidade de realizar o channel binding corretamente ocorrerá antes que as credenciais sejam validadas durante o processo de bind LDAP.
No entanto, para determinar se a proteção no lado do servidor do LDAP padrão é imposta (requisitos de integridade de assinatura do servidor), as credenciais do cliente devem primeiro ser validadas durante o bind LDAP. O possível erro que identifica a imposição dessa proteção é identificado a partir de uma perspectiva autenticada.
É recomendado usar Docker ou um ambiente virtual Python ao executar este projeto.
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: O DNS precisa resolver corretamente. Se você estiver roteando por SOCKS ou executando em um host não ingressado no domínio, garanta que isso esteja funcionando.
A ferramenta tem dois métodos: LDAPS (o padrão) e BOTH. LDAPS requer apenas o endereço IP do controlador de domínio, porque essa verificação pode ser realizada sem autenticação. O método BOTH exigirá um nome de usuário e senha ou hash NT. O domínio do Active Directory não é necessário; ele será determinado por meio de 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: A capacidade de usar SOCKS é passada por meio da variável de ambiente
PROXY_CONFIG. Se o SOCKS for necessário, a flag--network=hosttambém precisará ser usada para rotear o tráfego corretamente. Veja os exemplos abaixo.
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
Em um Controlador de Domínio corrigido desde o CVE-2017-8563, a capacidade de impor o channel binding de LDAPS existe. A política específica é chamada Domain Controller: LDAP server channel binding token requirements e pode ser definida como Never, When supported ou Always. Isso também não é obrigatório por padrão (no momento em que este texto foi escrito).
A descriptografia e o monitoramento do tráfego LDAP sobre SSL/TLS em um Controlador de Domínio permitiram identificar uma diferença nos erros durante tentativas de bind quando o channel binding é imposto versus quando não é. Ao tentar um bind em LDAP sobre SSL/TLS usando credenciais inválidas, você receberá o esperado resultCode 49 e, no conteúdo da mensagem de erro, verá data 52e. No entanto, quando o channel binding é imposto e o cliente LDAP não calcula e inclui o Channel Binding Token (CBT), o resultCode ainda será 49, mas o conteúdo da mensagem de erro conterá data 80090346, significando SEC_E_BAD_BINDINGS ou que os channel bindings da Security Support Provider Interface (SSPI) fornecidos pelo cliente estavam incorretos.
NOTA: Menções do erro
data 8009034durante o bind LDAP sobre SSL/TLS [1] [2] [3] [4] [5]
Esse erro específico torna bastante simples lidar com o caso em que a política Domain Controller: LDAP server channel binding token requirements está definida como Always. Basta tentar um bind LDAPS baseado em NTLM usando um cliente que não suporte channel binding e procurar o data 80090346 no erro em resposta. Mas e quando a política não está definida como Always, e quando está definida como When supported? A resposta é: faça bind ao LDAPS com autenticação baseada em NTLM e calcule propositalmente de forma incorreta as informações de channel binding.
Primeiro, precisamos de um cliente LDAP que suporte channel binding. A implementação de SkelSec disso no msldap será usada para implementar uma PoC. O channel binding aparece como um valor AV_PAIR durante o processo de desafio/resposta NTLM, especificamente no Tipo 3 ou AUTHENTICATE_MESSAGE. Aqui está mais uma visão de algum tráfego LDAPS descriptografado em um Controlador de Domínio para ver como é uma tentativa de bind de um cliente que suporta channel binding:
Calcular intencionalmente esse valor de forma incorreta, quando a política em questão está definida como When supported, produzirá o mesmo erro data 80090346. Isso nos dá a capacidade de diferenciar todas as configurações possíveis dessa política, como ela existe atualmente, a partir de uma perspectiva não autenticada. A forma como esse valor é propositalmente calculado incorretamente é importante, pois apenas substituir manualmente o valor durante o desafio/resposta invalidará o MIC.
Em um Controlador de Domínio, a política chamada Domain Controller: LDAP server signing requirements é definida como None, Require signing ou simplesmente não é definida. Quando não definida, o padrão é não exigir assinatura (no momento em que este texto foi escrito). O erro que identifica essa proteção como obrigatória ocorre quando uma tentativa de bind sicily NTLM ou simple responde com um resultCode 8, significando strongerAuthRequired. Isso só ocorrerá se as credenciais durante o bind LDAP forem validadas.
Alguns recursos inestimáveis para contextualizar este material e como ele se encaixa em cenários de ataque comuns.