O QUE É LLMNR & WPAD E COMO UTILIZA-LOS DURANTE O PENTEST

E ae galera, trazendo mais um artigo a respeito de pentest interno. Hoje iremos falar sobre LLMNR & WPAD.

Em um pentest interno, simulamos ataques que podem ser executados em serviços e protocolos mal configurados em nível de rede. Estes ataques são causados ​​principalmente pelo fato de que serviços como o Protocolo de Resolução de Endereço (ARP), Protocolo de Configuração Dinâmica de Hosts (DHCP), e Domain Name System (DNS) não estão configurados corretamente. Um dos ataques mais importantes que podem ser encontrados é, sem dúvida, Man-in-the-Middle (MITM). Medidas de segurança contra este ataque podem ser tomadas em equipamentos de rede, como roteadores e switches. No entanto, devido às fraquezas inerentes de alguns protocolos, podemos realizar o mesmo ataque com métodos diferentes. Por esta razão, o tema principal deste artigo será os ataques Man-in-the-Middle contra os: LLMNR, NetBIOS e WPAD. Antes de começar, gostaria de explicar como os computadores têm sistema operacional Windows se comunicar uns com os outros na mesma rede e executar a resolução de nomes. Antes de começar, gostaria de explicar como os computadores que tem o sistema operacional Windows se comunicam uns com os outros na mesma rede.

Esse processo prossegue com algumas etapas da seguinte maneira:

1. O arquivo hosts no sistema de arquivos é verificado
   
   • Em seus arquivos de configuração, indaga sobre as informações do sistema que deseja alcançar. Ao mesmo tempo, verifica se o dispositivo acessado é ele mesmo.
   • Os arquivos de configuração estão localizados em: C:\Windows\System32\drivers\etc
    
2. Verifique o cache DNS local
   
   • Primeiro de tudo, o cache é verificado. Se as informações para o dispositivo a ser acessado existirem no cache, essas informações serão usadas.
   • O cache do DNS pode ser ilustrado com o comando ipconfig / displaydns.
    
3. Enviar consulta para o DNS
   
   • Se o computador não encontrar nenhuma informação dos arquivos de configuração sobre o dispositivo que deseja acessar, ele envia uma consulta ao servidor DNS na rede local.
    
4. Envie a consulta LLMNR
   
   • LLMNR é um protocolo que é processado quando o servidor DNS falha na resolução de nomes.
    
5. Envie a consulta NetBIOS-NS
   
   • Ele funciona na camada “Session” do modelo OSI. O NetBIOS é uma API, não um protocolo, usado para comunicação entre sistemas operacionais Windows.
   • O nome NetBIOS do computador é o mesmo que o nome do computador.

O que é o LLMNR e o NetBIOS-NS?
LLMNR (Resolução de Nome de Multicast Local de Link) e NetBIOS-NS (Serviço de Nome) são dois componentes que os sistemas operacionais Windows usam para resolução de nomes e comunicação. O LLMNR foi usado pela primeira vez com o sistema operacional Windows Vista e é visto como a continuação do serviço NetBIOS-NS.

Nos casos em que o servidor DNS falha em consultas de resolução de nomes, esses dois serviços continuam a nomear a resolução. Os serviços LLMNR e NetBIOS-NS tentam resolver consultas que o servidor DNS não pode responder. Na verdade, esta é a forma de cooperação entre os computadores do sistema operacional Windows. 

O protocolo LLMNR é servido pelo endereço IP multicast do link-scope 224.0.0.252 para IPv4 e de FF02: 0: 0: 0: 0: 0: 1: 3 para IPv6. Executa operações próprias através da porta TCP55 / UDP 5355.
Por exemplo, ao tentar pingar para test.local que não está na rede, a primeira consulta vai para o servidor DNS. Se o servidor DNS não puder resolver esse nome de domínio, a consulta será redirecionada para o protocolo LLMNR. LLMNR não é uma alternativa ao protocolo DNS; É uma solução aprimorada para situações em que as consultas ao DNS falham. É suportado por todos os sistemas operacionais comercializados após o Windows Vista.

O NetBIOS é uma API que os sistemas da rede local usam para se comunicar uns com os outros. Existem três serviços NetBIOS diferentes.

• Name Service, ele usa a porta UDP 137 para uso no registro de nomes e na resolução de nomes.
• Datagram Distribution Service, ele usa a porta UDP 138 para comunicação sem conexão.
• Session Service, executa operações na porta TCP 139 para comunicação orientada por conexão.

O protocolo LLMNR é usado após a consulta DNS malsucedida. E, em seguida, é um pacote NetBIOS-NS, que é uma consulta de divulgação, está incluído no tráfego.

Teoricamente, esses sistemas aparentemente não têm proteção contra ataques do tipo MITM na rede local. Um invasor pode obter dados confidenciais, como nome de usuário e senha, com ataques bem-sucedidos.

Capture a hash NTLMv2 manipulando o tráfego
O cenário principal será realizado conforme mostrado abaixo:

1. A vítima tentará se conectar ao sistema de compartilhamento de arquivos, chamado filesrvr, que digitou incorretamente.
2. A resolução de nomes, que será executada com as etapas mencionadas anteriormente, será respondida no computador da vítima primeiro.
3. Na etapa 2, como o servidor DNS não tem um registro correspondente, o nome do sistema é enviado como consulta LLMNR, NetBIOS-NS.
4. O invasor intercepta o tráfego de rede, captura a consulta de resolução de nomes.

O invasor interceptara e responderá a todas as consultas LLMNR e NetBIOS-NS. Desta forma, é possível manipular o tráfego com uma sessão falsa e obter hashes de nome de usuário e senha.

Existem diferentes ferramentas para fazer este ataque.

• Responder, desenvolvida por SpiderLabs. (Vamos usar essa ferramenta.)
• O llmnr_response é um módulo no Metasploit Framework.
• MITMF 

Começamos a interceptar o tráfego da rede especificando qual interface de rede.

Nossa vítima tenta conectar o compartilhamento filesrvr

E estamos recebendo o SMB-NTLMv2 Hash!

Como sabemos, as hashes NTLMv2 não podem ser usados ​​diretamente para ataques. Agora faremos o ataque da Hash. Assim, precisamos executar o ataque de quebra de senha para obter a senha de texto simples da hash capturado. Existem várias ferramentas para hash cracking; John the Ripper, Hashcat, Caim e Abel, Hydra, etc. Usaremos o hashcat para "quebrar" a hash NTLMv2 que recebemos do Responder.

A ferramenta Respondente mantém os valores de hash que detecta no diretório /usr/share/responder.

A hash NTLMv2 que obtivemos é a seguinte:

O Hashcat é uma ferramenta de quebra de senhas de código aberto. Além disso, tem suporte a GPU. Pode detectar o padrão de hash com o parâmetro -m. No final do comando, ele iniciará um ataque de força bruta usando dicionário.

 E voila! Nós recebemos a senha que é Abcde12345.

O que é o WPAD?
As organizações permitem que os funcionários acessem as internets por meio de servidores proxy para aumentar o desempenho, garantir a segurança e rastrear o tráfego. Os usuários que se conectaram à rede corporativa precisam conhecer o servidor proxy para uma URL específica sem fazer configuração. O protocolo WPAD (Web Proxy Auto-Discovery Protocol) é um método usado pelos clientes para localizar a URL de um arquivo de configuração usando os métodos de descoberta DHCP e / ou DNS. Uma vez concluída a detecção e o download do arquivo de configuração, ele pode ser executado para determinar o proxy de uma URL especificada.

Como funciona o WPAD?
O cliente deseja acessar o arquivo de configuração wpad.dat para configuração de proxy. Ele procura computadores nomeados como "wpad" na rede local para encontrar esse arquivo. E, em seguida, as seguintes etapas são realizadas:

1. Se o servidor DHCP estiver configurado, o cliente recuperará o arquivo wpad.dat do servidor DHCP (se tiver êxito, a etapa 4 será obtida).
2. A consulta wpad.corpdomain.com é enviada ao servidor DNS para localizar o dispositivo que está distribuindo a configuração do Wpad. (Se bem sucedido, o passo 4 é tomado).
3. Consulta LLMNR enviada para WPAD (se houver sucesso, vá para a etapa 4, caso contrário, o proxy não poderá ser usado).
4. Faça o download do wpad.dat e use.

De acordo com a seqüência acima, o ataque de envenenamento de DHCP pode ser feito na primeira etapa. Ataque de envenenamento de DNS pode naturalmente ser executado para a segunda etapa. Mas, como observei no começo deste artigo, os dispositivos de rede configurados previnem esses ataques. Quando uma consulta é feita através do LLMNR, esta solicitação irá para todos os clientes na rede via transmissão. Nesse ponto, o invasor envia seu arquivo wpad.dat para os clientes, agindo como um servidor wpad.

O importante é que o protocolo WPAD é construído em sistemas operacionais Windows. Essa configuração pode ser vista na seção Configurações de LAN do navegador Internet Explorer.

Com essa configuração, o Internet Explorer faz uma consulta de resolução de nome WPAD em toda a rede.

Atacando o WPAD
O Responder é um ótimo utilitário para o ataque MITM. O Responder atende a um servidor WPAD falso e responde à resolução de nomes WPAD dos clientes. O cliente solicita o arquivo wpad.dat desse falso servidor WPAD. O Respondente cria uma tela de autenticação e solicita que os clientes insiram o nome de usuário e a senha que eles usam no domínio. Naturalmente, os funcionários escrevem nomes de usuário e senhas usados ​​no nome do domínio. Finalmente, podemos ver seu nome de usuário e senhas.

Usar a ferramenta Responder é muito simples

git clone https://github.com/SpiderLabs/Responder.git

Eu configurei os seguintes sistemas para simular esse ataque.

Agora, mandamos o falso servidor HTTP e esperamos por senhas em texto puro.

E nossa vítima verá a seguinte caixa de login e, naturalmente, digitará o nome de usuário e a senha.

 

E a senha está abaixo:

Backdoor com Responder
O Responder não é apenas o ataque MiTM para o serviço WPAD. Isso pode forçar as vítimas a baixarem arquivos maliciosos direcionando-as para uma página da web falsa. A engenharia social pode ser usada para preparar realisticamente a página da web a ser usada para esse ataque. No entanto, o Respondente também possui uma página de redirecionamento falsa. Tudo o que precisamos fazer é fazer algumas mudanças no arquivo responder.conf. Nós configuramos os parâmetros “Servir-HTML” e “Servir-EXE” para “On”.

[HTTP Server]
; Set to On to always serve the custom EXE
Serve-Always = On
; Set to On to replace any requested .exe with the custom EXE
Serve-Exe = On
; Set to On to serve the custom HTML if the URL does not contain .exe
; Set to Off to inject the 'HTMLToInject' in web pages instead
Serve-Html = On 

E executamos o Respondente novamente.

python Responder.py -I eth0 -i 10.7.7.31 -r On -w On

Agora, quando a vítima tenta se conectar com a internet, ela só verá a página seguinte. E, por acaso, a vítima clica na conexão do Proxy Client e o Bind faz o download do CMD Shell, para que possamos nos conectar ao ponto de conexão da vítima com o netcat.

Mitigações contra o WPAD
A primeira solução para esse ataque é criar uma entrada de DNS com “WPAD” que aponta para o servidor proxy corporativo. Assim, o invasor não poderá manipular o tráfego.

A segunda solução é desabilitar “Configurações de Proxy de Autodetectação” em todos os Internet Explorer com Diretiva de Grupo.

Referências:

https://en.wikipedia.org/wiki/NT_LAN_Manager
https://github.com/SpiderLabs/Responder
https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
http://www.defenceindepth.net/2011/04/attacking-lmntlmv1-challengeresponse.html
https://www.sternsecurity.com/blog/local-network-attacks-llmnr-and-nbt-ns-poisoning
https://www.us-cert.gov/ncas/alerts/TA16-144A

Esse foi mais um artigo retirado do site pentest.blog, link do artigo:

https://pentest.blog/what-is-llmnr-wpad-and-how-to-abuse-them-during-pentest/