Você está na página 1de 5

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 utilizao do ARP Spoofing e que apenas serve para pegar trfego de internet e senhas em texto claro. Quando fazemos uma varredura na maioria das mquinas Windows, vemos um protocolo sempre presente, o RDP. O Remote Desktop Protocol utilizado em Windows para a conexo remota atravs de Terminal Service. basicamente um protocolo da camada de aplicao (como o HTTP, FTP, SMTP, SSH e etc) e podemos encontr-lo rodando como o servio Terminal Server na porta 3389 por padro (obviamente que isso pode ser alterado, atravs de edio no registro do Windows). Com a utilizao desse servio, atravs do Terminal Service, possvel acessar o desktop, aplicaes e dados existentes no servidor configurado para receber tal conexo. Mas qual o problema disso? O problema, que esses servidores so acessados por pessoas (na maioria das vezes administradores), com logins e senhas vlidas dentro daquela rede. E sabem o que mais interessante? Uma dessas pessoas que acessam esse servio, 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 organizao... O RDP obviamente que no permite o trfego das credenciais de acesso atravs 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 correes, mas sabemos que a maioria das empresas no tem uma poltica bem formulada sobre gerenciamento de atualizao de sistemas e aplicao de patches de correo. Portanto, encontrando mquina 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 comunicao atravs do RDP. Essa vulnerabilidade est presente at a verso 5.2 do protocolo, utilizado at a verso 2003 do Windows Server (http://www.securityfocus.com/bid/13818/info). No entanto, ainda existem outras vulnerabilidades nesse protocolo, mesmo em sua ltima verso, 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 encriptao simtrica RC4 com chaves de 40 128 bits, dependendo da configurao do servio. O problema na utilizao do RDP, mesmo

utilizao criptografia, est no fato de que, no momento em que a troca das chaves pblicas, entre o servidor e o cliente. Nesse ponto, como no h um meio de verificao da autenticidade da chave pblica enviada pelo cliente para o servidor, basta o atacante enviar uma chave pblica 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 pblica a partir do que foi capturado. 2- A chave pblica do servidor substituda por uma nova, gerada pelo atacante (durante a fase de troca de chaves). 3- O pacote, j com a nova chave pblica, enviado para o cliente. 4- O pacote enviado pelo cliente capturado, atravs de ARP Spoofing, e tem sua chave pblica extrada do mesmo, utilizando a chave privada do atacante. 5- O pacote do cliente ento encriptado, usando a chave pblica do servidor, e enviado para o mesmo. 6- Os pacotes decriptados so armazenados em um arquivo de texto, para posterior leitura. O que interessante, que esse ataque completamente transparente, pois o software utilizado para o acesso, no avisa o usurio sobre a troca das chaves. preciso estar atento, para que tipo de implementao a melhor para evitar esse tipo de ataques, j que nas verses vulnerveis h duas possveis: 1- pr-autenticao, com acesso via rede, com o servio rodando como SYSTEM; 2- Network Level Authentication (NLA) habilitado, para que seja solicitada a autenticao antes que uma sesso RDP seja estabelecida entre cliente e servidor. Portanto, mesmo em verses vulnerveis possvel proteger-se contra esse ataque. Porm, a experincia mostra que, como a primeira opo a configurao padro, justamente essa a utilizada pela maioria das implementaes. E, antes de mostrar a explorao na prtica, 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 so as mquinas que esto ativas e podem ser sniffadas.

Sabendo quais so os IPs ativos, fica mais fcil definir seus alvos e saber quem participar do ARP Spoofing.

Agora, s definir os alvos, e criar uma nova tabela para utilizao 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 atravs 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 ns.

Obviamente que o contedo 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 autenticao.

E assim temos acesso senha digitada pelo usurio :-) At a prxima!