LLMNR / NBT-NS Poisoning Attack – Responder Parte 1
Fala galera, no post de hoje iremos falar sobre o ataque de envenenamento dos protocolos LLMNR e NBT-NS utilizando a ferramenta Responder desenvolvida por Laurent Gaffie. Iremos ver como esse ataque funciona, aprender sobre os protocolos envolvidos, fluxo de ataque e tudo mais 😉
Introdução
Nos testes internos, simulamos ataques que podem ser realizados contra serviços e protocolos mal configurados no nível de rede. Esses ataques são principalmente causados pelo fato de que mecanismos como ARP (Address Resolution Protocol), DHCP (Dynamic Host Configuration Protocol) e o DNS (Domain Name System) não estão configurados corretamente.
Um dos ataques mais importantes que podem ser encontrados é sem dúvida o Man-in-the-Middle. Ele permite o acesso a informações confidenciais ao sniffar o tráfego da rede ou manipular o alvo. No entanto, devido às vulnerabilidades inerentes de alguns protocolos, podemos realizar o mesmo ataque com diferentes métodos. O LLMNR & NBT-NS Poisoning é um ataque de rede clássico que ainda funciona hoje em dia, muito devido à falta de conhecimento por parte dos administradores de rede e ao fato desses protocolos serem habilitados por padrão em ambientes Windows.
O que é um ataque de LLMNR / NBT-NS Poisoning?
Através da escuta na rede por pacotes broadcast LLMNR e NetBIOS é possível manipular a vítima de forma que ela pense que está se conectando com um servidor autêntico. A vítima faz buscas errôneas em busca de servidores que não existem ou que não estão disponíveis, nesse momento o atacante responde indevidamente essas buscas dizendo que ele é o servidor que a vítima está buscando. Durante o processo de autenticação, o cliente enviará ao atacante o hash Net-NTLM (na maioria das vezes NTLMv2) do usuário que está realizando a solicitação, esse hash é armazenado na máquina do atacante para tentar ser quebrado de forma offline posteriormente com a ajuda de ferramentas como Hashcat ou John the Ripper. A imagem abaixo ilustra bem esse processo:
A ferramenta mais utilizada nesse tipo de ataque é o ‘Responder’, uma ferramenta desenvolvida por Laurent Gaffie e divulgada amplamente pela SpiderLabs. Hoje o repositório do Responder no GitHub está obsoleto, a ferramenta é atualmente mantida no repositório pessoal do Gaffie no Github.
A ferramenta – Responder
O Responder é uma ferramenta para envenenamento dos protocolos LLMNR, NBT-NS e MDNS. Ele irá responder às consultas do NBT-NS (NetBIOS Name Service) com base em seu sufixo de nome. Por padrão, a ferramenta apenas responderá a pedidos do serviço de arquivos que forem para o protocolo SMB. Algumas funcionalidades chaves do Responder são:
Servidor de autenticação SMB incorporado – Suporta hashes NTLMv1 e NTLMv2 com Extended Security NTLMSSP por padrão. Testado com sucesso desde o Windows 95 até o Server 2012 RC, Samba e Mac OSX Lion. O downgrade de hash LM é suportado utilizando o parâmetro –lm. Esse modo é ativado por padrão quando a ferramenta é iniciada.
Servidor de Autenticação MSSQL incorporado – Redireciona a autenticação SQL para a ferramenta que simula um servidor SQL. Para utilizar essa funcionalidade utilize o parâmetro -r. Este modo suporta hashes NTLMv1 e LMv2.
Servidor de autenticação HTTP incorporado – Para redirecionar a Autenticação HTTP para a ferramenta você precisa utilizar o parâmetro -r. Este modo suporta hashes NTLMv1, NTLMv2 e Basic Authentication.
Servidor de autenticação FTP, POP3, IMAP e SMTP incorporado – Esses módulos coletarão credenciais em texto claro na rede.
Servidor Proxy WPAD incorporado – Este módulo irá capturar todas as solicitações HTTP de qualquer pessoa que inicie o browser na rede com a opção “Detectar Automaticamente as Configurações”. Este módulo é altamente eficaz, você pode configurar seu script PAC personalizado no Responder.conf e injetar um HTML nas respostas do servidor.
Browser Listener – Este módulo permite encontrar o PDC de forma stealth.
Fingerprinting – Quando a opção -f é usada, o Responder irá fazer um fingerprint de todos os hosts que realizaram uma consulta LLMNR / NBT-NS.
Modo de análise – Este módulo permite que você veja consultas NBT-NS, BROWSER, LLMNR e DNS na rede sem envenenar qualquer resposta. Além disso, você pode mapear os domínios, servidores em geral e as estações de trabalho de forma passiva.
Para conhecer mais sobre a ferramenta e suas funcionalidades acesse:
https://github.com/SpiderLabs/Responder
https://github.com/lgandx/Responder
Como vimos até agora o Responde responde solicitações de protocolos muito pouco conhecidos, como o LMNR, NBT-NS e o mDNS, então vamos entender pra que servem esses protocolos e como eles atuam:
LLMNR
O Link-Local Multicast Name Resolution (LLMNR) é um protocolo baseado no formato de pacote do DNS que permite que os hosts executem a resolução de nomes para outros hosts na mesma sub-rede. Ele está embutido no Windows Vista, Windows Server 2008, Windows 7, Windows 8 e Windows 10. O LLMNR está definido na RFC 4795. Quando ativado, ele é um recurso utilizado antes do NetBios.
Imagine a seguinte situação em uma rede doméstica, onde existem 2 computadores executando o Windows 7, um se chama Client-A e o outro Client-B. Se Client-A quiser acessar recursos do Client-B será necessário digitar o caminho UNC (Universal Naming Convention) na forma \\Client-B. Caso o Client-A não tenha uma estrutura NetBios, ele irá utilizar primeiro o LLMNR a fim de tentar resolver o nome Client-B.
Caso ele não localize em seu cache o Client-B, ele irá mandar um pacote na rede e todos os hots da rede que estiverem com o NETWORK DISCOVERY habilitados irão ouvir o tráfego enviado. Se o Client-B estiver na mesma sub-rede e com o NETWORK DISCOVERY habilitado, ele irá ouvir a consulta e responderá ao Client-A. Como um mecanismo de resolução de nomes, o LLMNR oferece algumas vantagens importantes como não precisar de nenhuma configuração adicional e também é compatível com o IPv6, algo que o NetBios não é.
NBT-NS
O NetBIOS Name Service é parte do conjunto de protocolos NetBIOS-over-TCP que permite que aplicativos legados baseados na API NetBIOS sejam usados em redes TCP/IP. O NBT-NS atende ao mesmo propósito que o DNS, traduz hostnames em endereços IP. Os serviços do NBT-NS são mais limitados, os nomes NetBIOS tem em um espaço de nome plano em vez de um hierarquizado como no DNS. O NBT-NS só suporta endereços IPv4.
Com o advento do SMB-over-TCP, não é mais necessário ter o nome NetBIOS de uma máquina para que essa máquina faça conexões para servidores SMB ou para que as conexões SMB sejam feitas para essa máquina, com o advento do “DNS dinâmico”, um host pode registrar seu nome e seu endereço IP ou endereços com um servidor DNS quando ele inicializa. Portanto, os sistemas Windows mais recentes, podem usar o DNS para todos os fins para os quais o NBT-NS era usado. O NBT-NS ainda é amplamente utilizado, especialmente nas redes Windows, pois ainda pode haver versões mais antigas do Windows nessas redes.
MDNS
O mDNS (multicast Domain Name System) resolve nomes de host para endereços IP em pequenas redes que não incluem um servidor DNS local. É um serviço de configuração zero, utilizando essencialmente as mesmas interfaces de programação, formatos de pacotes e semântica operacional como o DNS. Embora Stuart Cheshire tenha projetado o mDNS para ser autônomo, pode funcionar em conjunto com servidores DNS.
O protocolo mDNS foi publicado na RFC 6762, usa pacotes de protocolo de datagrama e é implementado pelos pacotes de software como Apple Bonjour, Spotify Connect, Philips Hue, Google Chromecast e o Avahi. O mDNS também foi implementado no Windows 10, mas seu uso é limitado a descobrir impressoras em rede.
Laboratório
Estamos trabalhando com um cenário bem simples e ao mesmo tempo bem comum, onde temos um servidor Domain Controller na rede (AD), mais alguns servidores, um Firewall e os clientes. Como encontrado em diversas redes por ai, a instalação do Active Directory está default, sem muitas GPOs aplicadas a não ser as mais comuns como política de senha, compartilhamentos e etc.
Como é mostrado na imagem abaixo o AD não habilita a opção “Turn Off Multicast Name Resolution” por padrão, o que faz com que todas as máquinas que estejam do domínio fação consultas utilizando o protocolo LMNR. De todas os testes que eu fiz na vida, dá pra contar nos dedos as empresas que desabilitam esse tipo de consulta.
Fase do Ataque
Para realizar o ataque iremos precisar do Responder como já falamos e do John the Ripper para quebrar os hashes que capturarmos. Primeiro vamos baixar o Responder do diretório do Gaffie:
# cd /opt# git clone https://github.com/lgandx/Responder.git && cd Responder
Agora é só executar o Responder, os parâmetros estão explicados abaixo:
# python Responder.py -I eth0 -v --lm-I: Definir a interface de rede. -v: Trabalhar em modo verbose. --lm: Forçar o downgrade do hash LM em sistemas antigos.
Pronto, agora é só esperar as solicitações dos clientes da rede. Aqui iremos simular algumas consultas erradas feitas pelos clientes para ver o Responder funcionando conforme é mostrado nas imagens abaixo:
Nesse momento o Responder já respondeu a essas solicitações e capturou o hash desses usuários. Essa caixa de diálogo que aparece do lado esquerdo da imagem é o Responder, ele capturou o hash do usuário que está logado e deu acesso negado como resposta, assim o usuário tem a opção de tentar logar na pasta com outra credencial para “tentar acessar”, dessa forma o Responder captura mais um hash 🙂 Na imagem abaixo podemos ver os hashes capturados:
Não se preocupe em copiar esses hashes por que eles já estão sendo salvos nos arquivos de log do Responder. Depois que acabarmos de fazer o ataque, o que precisamos fazer é concatenar esses arquivos de hash para tentar quebrar com o John the Ripper:
# cd /opt/Responder/logs# cat SMB* > Hashes.txt
Agora é só tentar quebrar esses hashes com o John the Ripper. Iremos utilizar a wordlist rockyou que vem no Kali:
# john Hashes.txt --format=netntlmv2 -w /usr/share/wordlists/rockyou.txt
Como estamos utilizando um laboratório, as credencias dos usuários são bem simples, mas em um ambiente real depois de capturar diversos hashes e com uma boa wordlist a chance de conseguir algumas senhas são bem grandes. Um detalhe interessante aqui no lab é que o usuário ‘user2’ é um usuário comum, faz parte só do grupo ‘Domain Users’, porém ele é administrador local na máquina do usuário que utiliza ele, ou seja, tempos um bom ponto de entrada para tentar escalar privilégios e ir indo até conseguir um “Domain Admin”. Esse cenário se repete aos montes pelas empresas a fora, fica a fica 😉
Bem pessoal é isso ai, espero que tenham curtido. Não preciso dizer que esse post tem fins educacionais apenas, não utilize esse conhecimento para fins maliciosos. Não esqueçam de curtir nossas páginas nas redes sociais, Facebook, G+ e seguir o Guia do Ti no Twitter. Compartilhem e comentem esse artigo, isso é muito importante para divulgação do nosso trabalho.
Referências:
https://wiki.wireshark.org/NetBIOS/NBNS
https://en.wikipedia.org/wiki/NetBIOS_over_TCP/IP
https://technet.microsoft.com/library/bb878128
https://tools.ietf.org/html/rfc4795
https://en.wikipedia.org/wiki/Multicast_DNS
https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol
- Metasploit Framework de cabo a rabo – Parte 6 - 4 de junho de 2018
- Metasploit Framework de cabo a rabo – Parte 5 - 28 de maio de 2018
- CEH – Scanning Networks – Parte 2 - 24 de maio de 2018
