Leia
Baixe
Acompanhe
|
O simples fato de sua senha não funcionar por várias tentativas em algum serviço web (e você saber que é a senha correta) pode indicar que um MITM está acontecendo e você é a vítima.
Neste artigo vamos mostrar passo-a-passo como um ataque deste tipo é friamente planejado e executado. Prepare-se para conhecer como é feito algo que faz vítimas todos os dias.
Imagine um computador que acessa um serviço na rede, por exemplo um quiosque que ofereça acesso à internet mediante login com usuário e senha. A topologia da rede pode ser como esta:
No servidor de nossa rede fictícia estão instalado os seguintes serviços:
- Servidor DHCP. - Servidor DNS. - Proxy com autenticação (escutando na porta 3128). - Firewall.
Os clientes receberam os IP's exibidos na imagem (192.168.0.11 até 192.168.0.14) via DHCP, além disso, receberam como servidor DNS e como gateway padrão o IP do serivdor que é 192.168.0.1.
Quando um cliente senta-se em uma máquina e tenta acessar um site qualquer, ele é redirecionado para a página de login do proxy, como mostra a imagem a seguir:
Página de login do proxy
Em nosso exemplo, utilizei no servidor o MikroTik RouterOS, que possui a função de proxy com autenticação, além de outras. Com esta simples e corriqueira tentativa te acesso, o atacante já tem várias informações úteis. Veja:
- O IP do servidor é o 192.168.0.1 (vide redireração exibida na barra de endereços).
- A autenticação é baseada em HTTP, sem criptografia (se houvesse SSL, o protocolo informado na barra de endereços seria o HTTPS).
- O servidor utiliza PAT (Port Address Translation) no proxy, o que é comum em proxys transparentes. Nós digitamos um site e formos redirecionados para a página de login no proxy, ou seja, no firewall do serividor há uma regra para que qualquer tentativa de conexão proveniente da rede interna e com destino à porta 80 (websites) seja redirecionada para a porta do proxy no servidor (3128, em nosso exemplo). Graças à esta tradução de porta, o servidor obriga os hosts a logar antes de acessar qualquer site.
- O sistema utilizado é o MikroTik RouterOS. De posse dessa informação, o invasor também pode pesquisar por falhas conhecidas neste sistema à fim de explorá-las.
Um atacante pode inserir um notebook nesta rede ou até mesmo usar uma das máquinas clentes para iniciar uma breve análise de como a rede funciona, qual a classe dos IP's, etc. Vamos simular um ataque partindo do pressuposto da inserção de um notebook com alguma distribuição Linux na rede.
Ao conectar àa rede, receberemos um IP da faixa DHCP. Vamos admitir o IP 192.168.0.15. Ao tentar acessar algum site, somos redirecionados para a tela de autenticação do proxy, que pede nome e senha, do mesmo jeito que com os outros clientes.
A técnica man-in-the-middle consiste em roubar senhas fazendo-se passar pelo servidor de autenticação. Desta forma, quando um cliente que possui usuário e senha previamente cadastrados for efetuar o login, ele o fará na máquina do atacante pensando estar no servidor. O atacante então recebe o nome e a senha do usuário e o ataque está terminado. Portanto, vamos analisar o que é preciso ter em uma máquina para se fazer passar por um servidor de autenticação no exemplo acima:
- Servidor web.
- Cópia da página de login do proxy.
- Firewall (necessário para fazer PAT).
- Sniffer.
- Fazer com que os clientes acessem o servidor falso (máquina do atacante).
Servidor web Um webserver é necessário pois o atacante precisa exibir a página de login para o cliente, o que consiste em entender comandos HTTP. Existem vários servidores web disponíveis. No caso do Linux, o mais conhecido é o Apache. Já nos sistemas da gigante da Redmond, há o IIS que é nativo do Windows.
Cópia da da página de login do proxy O atacante simplesmente salva a página de login do proxy, com todas as imagens, textos, links e formulários, tudo isso para exibi-la idêntica ao cliente, afim de que ele não perceba que é uma página falsa, o que tornaria o ataque ineficaz.
Firewall Assim como no servidor, a máquina do atacante também precisará redirecionar uma tentativa de conexão na porta 80 para outra porta, mas no caso, será a porta onde o servidor web está escutando. Neste momento pode surgir a pergunta: Por quê não deixar o servidor web escutando na porta 80, como de costume? Acontece que quando um cliente tenta acessar, por exemplo, www.google.com.br:80, ele é redirecionado para 192.168.0.1:3128 e a página de login é exibida. Se o acesso fosse feito sem PAT, a máquina do host tentaria primeiro resolver o nome www.google.com.br para IP, usando o servidor DNS e depois receberia um erro uma vez que a máquina do atacante não possui servidor DNS neste exemplo, muito menos compartilha a conexão com a internet. Sendo assim, o cliente somente veria a página de login falsa se digitasse na barra de endereços http://192.168.0.1, o que certamente não aconteceria.
Sniffer Este é usado na fase final, justamente para analisar os pacotes que chegam na máquina do atacante em busca de senhas dos usuários. Um sniffer ethernet com muitos recursos é o Wireshark (www.wireshark.org).
Fazer com que os clientes acessem o servidor falso Esta é a parte mais difícil. O atacante pode usar inúmeras técnicas para realiar tal tarefa. Vejamos algumas:
Atuar como servidor DHCP O atacante pode fixar seu IP e instalar um servidor DHCP na máquina, entregando como gateway o seu próprio endereço. Geralmente servidores DHCP em Linux têm prioridade mais alta em responder quando algum host requisita IP na rede, além disso, são altamente configuráveis. No dhcpd, um dos mais famosos servidores DHCP para Unix/Linux, basta adicionar a linha "authoritative;" (sem aspas) ao arquivo dhcpd.conf.
Copiando o IP do servidor Se o atacante configurar em sua máquina o IP do servidor, automaticamente as requisições serão encaminhadas tanto pra ele quanto para o servidor real. Quem responder o TCP handshake primeiro será o dono da conexão. Se o atacante quiser evitar que o servidor real receba conexões, existem técnicas para manter o servidor real ocupado e o flood é uma delas.
Agora que já conhecemos um dos métodos de aplicar o MITM, vamos ver passo-a-passo a configuração de uma máquina para um ataque. Utilizaremos a distribuição OpenSuse 11.0 para tal.
1. Análise A análise neste caso é rápida. Basta colocar o computador na rede e verificar alguns itens. Primeiro vamos verificar o IP que adquirimos com o comando ifconfig: suse64:~ # ifconfig eth0 Agora, temos de verificar quem é o nosso default gateway. Para isso, basta analisar a saída do comando route:
suse64:~ # route
Podemos ver o servidor DNS que recebemos no conteúdo do arquivo /etc/resolv.conf: suse64:~ # cat /etc/resolv.conf
nameserver 192.168.0.1
Tudo aponta para o 192.168.0.1. Então sabemos que o servidor concentra todos os serviços citados no exemplo.
2. Cópia da página Agora vamos tentar acessar o site www.mentebinaria.com.br afim de cair na página de autenticação do proxy e salvá-la no disco. Qualquer browser pode ser usado para realizar tal tarefa.
Serão salvos uma página login.html e um diretório login_files, contendo a imagem logobottom.png e o script md5.js. Isso no caso do MikroTik (nosso exemplo), claro.
Vamos ver o código-fonte da página login.html.
Destacamos as partes mais interessantes do código da página login.html:
<form name="sendin" action="http://192.168.0.1/login" method="post"> Aqui vemos um formulário com o endereço do servidor de autenticalção e um método POST.
<input name="dst" value="http://www.mentebinaria.com.br/" type="hidden"> Agora um valor que contém a URL do site que digitamos. Ele será usado se o login for bem sucedido para nos redirecionar para o site que queremos visitar.
<script type="text/javascript" src="/login_files/md5.js"></script> Um código em JavaScript que implementa a crptografia MD5.
document.sendin.password.value = hexMD5('\260' + document.login.password.value + '\336\245\056\163\014\056\216\106\362\136\064\322\160\122\162\306'); Aqui e senha é criptografada quando o usuário clica no botão login. Ela sofrerá a criptografica MD5 com mais alguns bytes, técnica conhecida como salting, para dificultar a quebra do MD5.
Se colocarmos esta página do jeito que está em nosso servidor web, receberemos a senha criptografada com MD5 + salting bytes. Portanto, o melhor é remover essa função de criptografia para que possamos sniffar a senha em texto puro (clear text). A página alterada, que será usada no MITM, é exibida abaixo:
Removemos os trechos de código desnecessários para o MITM, assim como a função que implementa o algoritmo MD5. Na verdade, para este MITM, basta um formulário simples com usuário e senha. Padrões de formatação e comportamento foram mantidos em prol da similaridade com a página real.
Agora vamos renomear esta página para index.html, afim de fazer dela nossa página inicial no servidor web, que aliás, é a próxima etapa.
3. Instalação do servidor web Um atacante já teria um servidor web previamente instalado em seu micro, no entanto, para instalar o Apache no OpenSuse, basta comandar: # zypper in apache2
Ao final da instalação, o Apache já deve estar rodando e funcionando. Para verificar, basta acessar o localhost (127.0.0.1) a partir de um browser.
Por padrão o Apache escuta na porta 80. Temos que mudar esta porta porque usaremos o firewall para fazer PAT, então vamos colocar o Apache para escutar na 3128. Para isso, basta editar o arquivo /etc/apache2/listen.conf e alterar a linha Listen 80 para Listen 3128.
O diretório login_files e o arquivo index.html que criamos devem ser copiados para /srv/www/htdocs. O diretório htdocs deve estar como a saída do comando abaixo.
suse64:~ # ls /srv/www/htdocs/
O Apache deve ser reiniciado: # service apache2 restart
Para testar a página falsa, basta digitar na barra de endereços do navegador a URL http://localhost:3128.
4. Configuração do PAT Agora temos uma página fake (falsa) em nosso servidor web, na porta 3128. Mas as requisições virão pela porta 80, portanto temos que implementar o PAT com o iptables, assim:
# modprobe iptable_nat
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
Pronto. Qualquer conexão que entrar em nossa porta 80 será redirecionada para nossa porta 3128, onde está o Apache com a página de login falsa.
5. Fazendo com que os clientes acessem o servidor falso Para economizar tempo, vou simplesmente colocar o IP do servidor na máquina usada para o ataque, sem floodar o servidor real. Assim, as conexões serão divididas entre o servidor real e o falso (como vantagem, nem todos os clientes vão perder o acesso à web). Em compensação, menos senhas serão capturadas.
Para configurar, basta usar o ifconfig: # ifconfig eth0 192.168.0.1/24
6. Capturando as senhas Chegou a hora esperada. Abrir o Wireshark (leia o artigo Sniffing com o Wireshark) e aguardar a captura das senhas. Basta olhar os pacotes recebidos no método POST do protocolo HTTP (pode-se usar um filtro "HTTP matches POST" ou "HTTP matches HTTP/1.1" para visualizar melhor os pacotes). Alternativamente outros sniffers podem ser usados, como o tcpdump.
É importante salientar que esta configuração é muito básica. Atacantes experientes organizam ataques muito mais elaborados que fazem parecer que não houve ataque algum. Além disso, existem ferramentas especializadas para MITM que automatizam muitas tarefas. No entanto, o objetivo deste artigo é conhecer o MITM básico e para isso esta configuração deve ser suficiente.
E como fica a proteção? Bem, como boas práticas de segurança, qualquer servidor de autenticaçao deve usar SSL e de preferência uma lingugagem dinâmica como PHP. Além disso, um IDS (Intrusion Detection System) pode detectar um ataque MITM sem muito esforço. Outra falha é deixarem pontos de rede que não estão sendo usados ligados ao switch, o que atrai a atenção de um atacante.
Eu usei o sistema MikroTik somente para demonstração. A falha não está nele, mas a segurança dele pode (e deve) ser melhorada.
Espero que tenha atingido o objetivo de demonstrar o básico do MITM. Se houver dúvidas, não hesite em discutir em nosso fórum.
{jos_smf_discuss:4}
|
Dentre os mais variados tipos de ataque contra redes de computadores, o ataque man-in-the-middle (homem-no-meio) ou em sua forma abreviada, MITM, tem se mostrado extremamente perigoso, capaz de conseguir informações confidenciais apostando-se na fraqueza e inexperiência do usuário e não do administrador de redes. O alvo do MITM é quase sempre o usuário de uma rede protegida e este, dificilmente saberá que está sendo atacado, pelo menos enquanto o ataque acontece.
É um exemplo de topologia bem simples e largamente encontrado em pequenas redes mas a teoria explicada aqui pode ser aplicada em redes de qualquer tamanho e com qualquer nível de complexidade.
Últimos artigos
- Serviços Google via linha de comando (264 hits)
- Monitoração de serviços com o Zabbix (1074 hits)
- Recuperando mensagens do Outlook Express com Linux (239 hits)
- Flash Player 10 nativo para Linux 64-bits (343 hits)
- D-Link DWA-125 no Ubuntu 10.04 (Lucid Lynx) (1103 hits)
- Opera Web Browser - o seu próximo navegador (872 hits)
- Como remover vírus de pen drive (2891 hits)
- Go - A linguagem de programação do Google (917 hits)
- Como usar cartuchos recarregados na HP C5180 (1119 hits)
- Expressões regulares no Mediation (771 hits)
Artigos mais lidos
- Sniffing com o Wireshark (14705 hits)
- Controle de dispositivos com a porta paralela (9487 hits)
- Mascarando o endereço MAC da placa de rede (8136 hits)
- Remoção manual de vírus (6295 hits)
- Ghost pela rede (5975 hits)
- Tudo sobre o GRUB (5429 hits)
- Criando um layout para seu website (4076 hits)
- Extensões perigosas no Windows (3648 hits)
- Entendendo um ataque man-in-the-middle (3354 hits)
- BackTrack - uma distribuição hacker (3272 hits)