Man In The Middle no RDP

Hoje vamos falar um pouco de uma vulnerabilidade antiga, mas que muitos pentesters esquecem de explorar quando dentro de uma rede ou sistema. Muita gente pensa que Man In The Middle resume-se à utilização do ARP Spoofing e que apenas serve para pegar tráfego de internet e senhas em texto claro.

Quando fazemos uma varredura na maioria das máquinas Windows, vemos um protocolo sempre presente, o RDP. O Remote Desktop Protocol é utilizado em Windows para a conexão remota através de Terminal Service. É basicamente um protocolo da camada de aplicação (como o HTTP, FTP, SMTP, SSH e etc) e podemos encontrá-lo rodando como o serviço Terminal Server na porta 3389 por padrão (obviamente que isso pode ser alterado, através de edição no registro do Windows).

Com a utilização desse serviço, através do Terminal Service, é possível acessar o desktop, aplicações e dados existentes no servidor configurado para receber tal conexão. Mas qual o problema disso? O problema, é que esses servidores são acessados por pessoas (na maioria das vezes administradores), com logins e senhas válidas dentro daquela rede. E sabem o que é mais interessante? Uma dessas pessoas que acessam esse serviço, pode ser o domain admin :-)

E o que será mesmo que podemos fazer com login e senha de um domain admin? Bem, vamos imaginar o que seria ter acesso ao servidor que controla TODA a rede de uma organização...

O RDP obviamente que não permite o tráfego das credenciais de acesso através de texto plano, mas possui vulnerabilidades que permitem ataques como o Man In The Middle, que com as ferramentas certas pode permite a captura das credencias.

Uma dessas vulnerabilidades - Microsoft RDP Man in the Middle Vulnerability (http://www.securiteam.com/windowsntfocus/5EP010KG0G.html) – já foi resolvida com patches e correções, mas sabemos que a maioria das empresas não tem uma política bem formulada sobre gerenciamento de atualização de sistemas e aplicação de patches de correção. Portanto, encontrando máquina Windows em uma rede, e o RDP estando habilitado, tenham em mente que um belo vetor de ataque se apresentou.

Uma coisa que precisa estar clara nesse artigo, é que a vulnerabilidade citada aqui, está vinculada a possibilidade captura das chaves que trafegam no processo de comunicação através do RDP. Essa vulnerabilidade está presente até a versão 5.2 do protocolo, utilizado até a versão 2003 do Windows Server (http://www.securityfocus.com/bid/13818/info). No entanto, ainda existem outras vulnerabilidades nesse protocolo, mesmo em sua última versão, a 7.0, como essa: Microsoft Remote Desktop Connection Client DLL Loading Arbitrary Code Execution Vulnerability (http://technet.microsoft.com/pt-br/security/bulletin/ms11-017), que inclusive possui exploit publicado para o Metasploit Framework.

O RDP foi criado com o intuito de ser um protocolo seguro, inclusive porque o mesmo utiliza o algoritmo de encriptação simétrica RC4 com chaves de 40 à 128 bits, dependendo da configuração do serviço. O problema na utilização do RDP, mesmo utilização criptografia, está no fato de que, no momento em que a troca das chaves públicas, entre o servidor e o cliente. Nesse ponto, como não há um meio de verificação da autenticidade da chave pública enviada pelo cliente para o servidor, basta o atacante enviar uma chave pública para servidor, da qual ele tem a posse de sua contraparte privada.

Um resumo de como o ataque funciona segue abaixo:

1-     O atacante captura um pacote enviado pelo servidor, utilizando ARP Spoofing, para extrair sua chave pública a partir do que foi capturado.

2-     A chave pública do servidor é substituída por uma nova, gerada pelo atacante (durante a fase de troca de chaves).

3-     O pacote, já com a nova chave pública, é enviado para o cliente.

4-     O pacote enviado pelo cliente é capturado, através de ARP Spoofing, e tem sua chave pública extraída do mesmo, utilizando a chave privada do atacante.

5-     O pacote do cliente é então encriptado, usando a chave pública do servidor, e enviado para o mesmo.

6-     Os pacotes decriptados são armazenados em um arquivo de texto, para posterior leitura.

O que é interessante, é que esse ataque é completamente transparente, pois o software utilizado para o acesso, não avisa o usuário sobre a troca das chaves.

É preciso estar atento, para que tipo de implementação é a melhor para evitar esse tipo de ataques, já que nas versões vulneráveis há duas possíveis:

1- pré-autenticação, com acesso via rede, com o serviço rodando como SYSTEM;

2- Network Level Authentication (NLA) habilitado, para que seja solicitada a autenticação antes que uma sessão RDP seja estabelecida entre cliente e servidor.

Portanto, mesmo em versões vulneráveis é possível proteger-se contra esse ataque. Porém, a experiência mostra que, como a primeira opção é a configuração padrão, é justamente essa a utilizada pela maioria das implementações.

E, antes de mostrar a exploração na prática, seguem os links de duas ferramentas que podem ser utilizadas para esse ataque:

• rdpproxy - An RDP mitm proxy: http://cvs.sourceforge.net/viewcvs.py/rdesktop/rdpproxy/
• Cain & Abel v2.7 - Provides the ability to perform invisible mitm attacks against RDP: http://www.oxid.it

Processo

O primeiro processo a ser executado, é varrer um range de IPs para definir quais são as máquinas que estão ativas e podem ser sniffadas.

Sabendo quais são os IPs ativos, fica mais fácil definir seus alvos e saber quem participará do ARP Spoofing.

Agora, é só definir os alvos, e criar uma nova tabela para utilização com o ARP Spoofing.

Com tudo configurado, basta executar o ataque de ARP Spoofing + Sniffing, para que os pacotes entre os dois alvos definidos, sejam capturados durante o acesso com o Terminal Service.

Aqui, vemos o cliente iniciando um acesso ao RDP através do Terminal Service.

Na aba APR dentro de Sniffer, podemos ver os pacotes capturados de diversos protocolos, e especificamente do protocolo RDP. E quando clicamos sobre o pacote, para visualizarmos com o Bloco de Notas, o que foi capturado aparece em texto plano e desencriptado para nós.

Obviamente que o conteúdo do arquivo é grande, com muitos caracteres. Mas quando mandamos localizar a string "Key Pressed", nos deparamos com as credenciais que foram enviadas pelo cliente, para o servidor, no processo de autenticação.

E assim temos acesso à senha digitada pelo usuário :-)

Até a próxima!