Ataque man-in-the-middle

O que é um ataque man-in-the-middle?

Um ataque man-in-the-middle, ou ataque MITM, coloca o atacante no caminho de comunicação entre duas pontas que acreditam estar falando diretamente uma com a outra. Dali ele pode ler o tráfego, modificá-lo, retransmiti-lo ou retê-lo. A MITRE ATT&CK cataloga o comportamento como Adversary-in-the-Middle (T1557) e descreve adversários se posicionando entre dois ou mais dispositivos em rede.

A posição é o que transforma isso em um ataque man-in-the-middle. O que o atacante faz dali é outra questão, e é onde a maioria das explicações erra.

Estar no caminho não significa ler o conteúdo. Um atacante que retransmite tráfego TLS sem quebrar o canal vê tamanhos de pacote, tempos e destinos, não texto não cifrado. Um ataque man-in-the-middle que lê ou modifica conteúdo protegido precisa que o cliente aceite uma identidade que deveria recusar: um certificado de uma autoridade comprometida, um certificado que a aplicação nunca valida ou uma conexão que o navegador permitiu rebaixar para HTTP. O problema é de autenticação mais do que de criptografia.

Três coisas são confundidas com um ataque man-in-the-middle. Escuta passiva: em um canal sem criptografia basta o acesso, não é preciso se interpor. Falsificação de identidade: forja uma identidade, mas pode não retransmitir nada. Ponta comprometida: vê texto não cifrado porque é uma das duas partes, o que não é o mesmo que estar no meio.

Como funciona um ataque man-in-the-middle

Todo ataque man-in-the-middle tem duas etapas: entrar no caminho e depois fazer algo com o tráfego. Elas são independentes, e um atacante pode conseguir a primeira e falhar na segunda. Diante de uma conexão TLS bem configurada, esse é o desfecho normal de um ataque man-in-the-middle.

Etapa um: posicionar-se. O atacante manipula um protocolo que decide para onde vai o tráfego: resolução de endereços, resolução de nomes, atribuição de endereços ou associação sem fio. Nenhum foi projetado com autenticação, e por isso ainda sustentam um ataque man-in-the-middle décadas depois de o problema ser descrito pela primeira vez.

Etapa dois: agir sobre o tráfego. O desfecho depende de como as pontas se autenticam entre si. Diante de protocolos sem criptografia, o atacante lê e reescreve à vontade. O requisito 181, Transmit data using secure protocols da Fluid Attacks cita HTTP, FTP, POP3 e Telnet como exemplos, e mapeia para CAPEC-94, CWE-319, PCI DSS 4.2.1 e NIST SP 800-115. Diante de TLS, o atacante precisa de uma falha de validação. Diante de TLS mais um cliente que fixa certificados ou apresenta o seu, normalmente precisa de execução de código no dispositivo.

Os controles que detêm cada etapa são diferentes. As organizações compram o primeiro conjunto e deixam o segundo sem exame, e é assim que um ataque man-in-the-middle atravessa uma rede que parece defendida.

Tipos de ataques man-in-the-middle

As técnicas abaixo são as que aparecem em redes reais. A MITRE classifica quatro como subtécnicas de T1557. O SSL stripping e o man-in-the-browser ficam de fora porque atacam o transporte e a ponta, não o roteamento.

Técnicas que viabilizam um ataque man-in-the-middle, com sua classificação na MITRE ATT&CK.

ARP poisoning

O atacante responde solicitações ARP em um segmento local e associa o próprio endereço MAC ao endereço IP de um host legítimo, normalmente o gateway. O tráfego destinado a esse host chega ao atacante. O ARP não tem autenticação, então vence a última resposta.

DNS spoofing

O atacante devolve respostas forjadas às consultas de nomes e envia a vítima para infraestrutura que ele controla. Isso é redirecionamento, não interceptação, e a distinção importa: o navegador da vítima ainda valida o certificado no destino. O DNS spoofing vira um ataque man-in-the-middle completo apenas quando combinado com um certificado que a vítima aceite, que foi exatamente o que o comprometimento da DigiNotar forneceu.

SSL stripping e HTTP spoofing

O atacante intercepta a solicitação em texto não cifrado que o navegador faz antes de qualquer redirecionamento para HTTPS e entrega à vítima uma cópia sem criptografia do site, enquanto mantém uma sessão HTTPS correta com o servidor real. A vítima vê uma página funcionando, sem cadeado. A fraqueza 131 da Fluid Attacks cobre a condição do servidor que permite isso: um cabeçalho Strict-Transport-Security ausente ou de vida curta.

Evil twin de Wi-Fi

O atacante transmite um ponto de acesso com o nome de uma rede em que o dispositivo da vítima já confia. O dispositivo se associa automaticamente e todos os pacotes seguintes passam pelo equipamento do atacante. Os pentesters da Fluid Attacks usam Aircrack-ng e bettercap para esse tipo de avaliação sem fio.

Envenenamento de LLMNR e retransmissão NTLM

Este é o ataque man-in-the-middle que mais causa dano dentro de redes corporativas, e não tem nada a ver com o wi-fi de uma cafeteria. Quando o Windows não consegue resolver um nome por DNS, recorre ao Link-Local Multicast Name Resolution e ao NetBIOS Name Service, que difundem a consulta ao segmento local. Um atacante responde, a vítima se autentica e o atacante recebe um hash NTLMv2 para quebrar offline ou retransmitir a outro host. A fraqueza 388 da Fluid Attacks indica que o NTLM "can be vulnerable to several security flaws, including Relay attacks, Man in the Middle" e força bruta. O pentest interno da Fluid Attacks cobre essa técnica, junto com o roubo de tickets Kerberos e os ataques IPv6.

Man-in-the-browser

Malware ou uma extensão maliciosa opera dentro do navegador, depois de o TLS terminar. O canal está intacto e o certificado é válido; o atacante lê e reescreve a página já decifrada. Nenhum controle de transporte detém isso, e por isso conta como comprometimento da ponta.

IP spoofing

O atacante forja endereços de origem para se passar por um host confiável. Sozinho, raramente produz um ataque man-in-the-middle aproveitável em redes modernas, mas sustenta as técnicas acima.

Uma nota sobre as ferramentas: mitmproxy, Wireshark e OWASP ZAP interceptam tráfego, e nenhuma é por natureza uma ferramenta de ataque. A autorização é o que separa um ataque man-in-the-middle de uma avaliação.

Ataques man-in-the-middle na Fluid Attacks

A Fluid Attacks avalia as condições que tornam possível um ataque man-in-the-middle: em aplicações, em infraestrutura e nas redes que seus pentesters estão autorizados a avaliar. Cada fraqueza é catalogada, recebe uma severidade e é verificada após a remediação.

O que avaliamos e sob quais regras

A avaliação de interceptação é delimitada e autorizada por escrito antes de qualquer instrumentação, e a Fluid Attacks mantém controle total do canal de comunicação entre o pentester e o objeto de avaliação. As ferramentas que tornam uma avaliação realista são as mesmas que os atacantes usam: na documentação da Fluid Attacks, o OWASP ZAP é descrito como um "man-in-the-middle proxy", porque reproduzir um ataque man-in-the-middle em condições controladas é exatamente o que um avaliador autorizado precisa fazer.

Como isso se vê na prática

Superfícies onde um ataque man-in-the-middle é possível, as ferramentas que os pentesters da Fluid Attacks usam em cada uma e a fraqueza catalogada à qual um achado mapeia.

A fraqueza de HSTS como aparece na base de dados da Fluid Attacks, com sua remediação.

O que a avaliação manual encontra e os scanners não veem

No benchmark da Fluid Attacks de 36 ferramentas AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades semeadas, um pentester detectou 89,6 % delas com 100 % de precisão. O scanner automatizado com melhor desempenho nesse exercício foi o da própria Fluid Attacks, com 22,7 % de recall, equivalente a 8,8 % da exposição ao risco total da aplicação medida em CVSSF. O pentester encontrou com exclusividade 743 vulnerabilidades, 86,8 % da exposição ao risco total.

As falhas por trás de um ataque man-in-the-middle se dividem com clareza nos dois lados dessa lacuna. Um scanner relata com confiabilidade um cabeçalho ausente ou uma suíte criptográfica fraca. Estabelecer que uma aplicação aceita um certificado que deveria recusar, em um fluxo específico e com um cliente específico, exige que alguém o faça.

O que os testes de segurança não vão dizer

Um scanner marca um cabeçalho Strict-Transport-Security ausente ou um TrustManager que confia em tudo. Ele não diz se alguém está no cabo neste momento. Detectar um ataque man-in-the-middle em curso é trabalho de telemetria de rede e resposta a incidentes, não de testes de segurança de aplicações. A Fluid Attacks relata as condições que tornam a interceptação viável e verifica que foram corrigidas.

A mesma ressalva vale para as defesas móveis. A análise da Fluid Attacks sobre a proteção dentro do app sustenta que ligar um controle não é o mesmo que corrigir a falha que está embaixo dele: a detecção de proxies maliciosos e o certificate pinning são camadas sobre uma base que precisa estar sólida primeiro.

Como protegemos nosso próprio transporte

Os controles documentados da Fluid Attacks aplicam aos seus próprios sistemas as recomendações desta página, e fecham uma a uma as etapas de um ataque man-in-the-middle. O domínio aceita apenas TLSv1.3 de ponta a ponta. As origens se autenticam por Authenticated Origin Pulls, um esquema de TLS mútuo apoiado em uma CA privada, de modo que a camada TLS recusa os handshakes sem um certificado assinado por essa CA. Cada handshake público usa a troca de chaves híbrida pós-quântica X25519MLKEM768. As três zonas principais estão na lista de pré-carregamento embutida nos navegadores, então eles recusam HTTP não cifrado já na primeira solicitação. Os certificados de fluidattacks.com têm validade de 14 dias.

Caminho de dados público da Fluid Attacks: cada salto leva criptografia de transporte e uma verificação de identidade na ponta receptora.

O que de fato detém um ataque man-in-the-middle

Cinco controles fazem quase todo o trabalho contra um ataque man-in-the-middle, e cada um detém uma etapa diferente. Implantá-los sem saber qual é qual é como as organizações acabam protegidas contra o ataque que não estavam enfrentando.

Qual etapa de um ataque man-in-the-middle cada controle interrompe e onde cada um termina.

Validação de certificados TLS

Este é o controle sobre o qual tudo o mais se apoia. O TLS dá confidencialidade, integridade e autenticação do servidor, e só a terceira detém um ataque man-in-the-middle

O mecanismo fica mais claro pelo lado ofensivo. Ao descrever como se monta um *proxy* de interceptação contra um app Android, o security analyst da Fluid Attacks Jonathan Armas observa que o certificado do proxy precisa chegar antes à lista de confiança do dispositivo: "Without this, we cannot intercept secure channel traffic". Essa frase é a defesa, lida ao contrário: um ataque man-in-the-middle sobre TLS começa pela confiança, não pela criptografia.

A falha comum não é um certificado ausente, e sim uma verificação desativada. A regra SAST-NATDC da Fluid Attacks detecta implementações de TrustManager em Kotlin que contornam a validação de certificados. A conexão é HTTPS. A validação sumiu.

Um `TrustManager` com o método de verificação vazio aceita qualquer certificado apresentado a ele; a versão corrigida usa o armazenamento de confiança do sistema.

HSTS e a lista de pré-carregamento

A RFC 6797 define o HTTP Strict Transport Security (HSTS). Seu cabeçalho Strict-Transport-Security instrui o navegador a usar HTTPS para um domínio e impede que os usuários ignorem os avisos de certificado. Fecha o SSL stripping para todas as conexões depois da primeira.

A primeira conexão é o buraco, e o pré-carregamento o fecha. Os domínios na lista de pré-carregamento ficam compilados dentro do navegador, então o texto não cifrado nunca sai do dispositivo. A OWASP adverte que a diretiva preload tem consequências permanentes: um domínio na lista não pode voltar a HTTP com rapidez.

O certificate pinning é mais estreito que sua reputação

A recomendação de fixar certificados por padrão está pendente de correção, e a OWASP é direta: "There is almost no situation where you should consider pinning" e "If it is not a native mobile application, do not pin". O certificate pinning resolve um problema, o de uma autoridade certificadora em que você não confia, para um par cliente-servidor do qual você controla as duas pontas. Não sobrevive a um atacante com acesso de instrumentação ao dispositivo e quebra sempre que um certificado roda de forma inesperada.

TLS mútuo

O TLS mútuo obriga os dois lados a provar identidade. É o controle certo para o tráfego entre serviços, onde um ataque man-in-the-middle dentro de um cluster é tão plausível quanto um em uma rede pública. O requisito 088 da Fluid Attacks pede que os sistemas que lidam com informação crítica para o negócio exijam certificados de cliente, e mapeia para NIST SP 800-63B 5.2.5 e OWASP Top 10 A07. A Fluid Attacks o recomenda para toda comunicação entre um cliente de Model Context Protocol e um servidor remoto.

MFA resistente a *phishing*

Os kits de phishing adversary-in-the-middle montam um proxy reverso entre a vítima e o provedor de identidade real. A vítima digita uma senha e um código de uso único, o proxy encaminha os dois, captura o cookie de sessão que o servidor devolve e o reproduz. Os códigos enviados por SMS ou gerados em um app não sobrevivem a essa forma de ataque man-in-the-middle. A CISA descreve a MFA por SMS e voz como "Vulnerable to phishing, SS7, and SIM swap attacks" e chama o FIDO/WebAuthn de "the only widely available phishing-resistant authentication". A razão é o vínculo com a origem: uma credencial FIDO não assina um desafio para um domínio que não corresponde à sua origem registrada, então o proxy não obtém nada.

O SSL stripping clássico e um proxy AiTM moderno, com o ponto onde HSTS preload e FIDO2 interrompem cada um. Elaboração própria.

Como detectar um ataque man-in-the-middle

A detecção de um ataque man-in-the-middle é comportamental. Você procura os efeitos colaterais de alguém estar no caminho, porque a interceptação em si não gera alerta nenhum. A estratégia de detecção DET0296 da MITRE lista o que observar diante de um ataque man-in-the-middle: "suspicious DNS/ARP poisoning attempts, unauthorized modifications to registry/network configuration" e "abnormal TLS downgrade activity". Suas analíticas também cobrem edições não autorizadas de /etc/hosts e /etc/resolv.conf, difusões ARP suspeitas e mudanças de configuração em dispositivos de rede.

Três sinais valem a instrumentação em primeiro lugar, porque são baratos e específicos: certificados que não correspondem ao que seu monitoramento espera para um domínio, negociações de versão de TLS ou de cifra que caem abaixo do seu mínimo, e respostas ARP ou DNS que mudam o mapeamento de um host que você controla.

Para os usuários, o conselho que de fato detecta um ataque man-in-the-middle é mais estreito que a lista habitual: nunca ignorar um aviso de certificado. Um navegador que relata um nome de host que não confere, um certificado vencido ou um emissor não confiável está descrevendo a condição exata de que um ataque man-in-the-middle precisa.

Quando a cadeia de confiança falha

Os dois casos abaixo terminaram com sessões cifradas sendo lidas, e em nenhum a criptografia foi quebrada. Seguem sendo a evidência pública mais clara de que um ataque man-in-the-middle derrota o HTTPS pela via da confiança, e não da criptografia.

DigiNotar e Superfish

Em 2011, atacantes comprometeram a autoridade certificadora holandesa DigiNotar e emitiram certificados em que toda a web confiava, incluindo um para o Google. A análise da ENISA registra que certificados falsos foram usados "para espionar usuários no Irã" durante dois meses. Os navegadores retiraram a confiança na DigiNotar e a empresa faliu.

Em 2015, notebooks de consumo da Lenovo saíram de fábrica com adware que executava um ataque man-in-the-middle por projeto: instalava a própria autoridade certificadora raiz no armazenamento de confiança do Windows para injetar conteúdo em páginas HTTPS. O alerta TA15-051A da CISA avisou que a falha permitia a um atacante "successfully impersonate (spoof) any website".

Os dois diferem em onde ocorreu a traição. A DigiNotar quebrou a hierarquia pública de confiança; o Superfish quebrou o armazenamento de confiança do dispositivo. Ambos produziram um ataque man-in-the-middle que nenhuma quantidade de criptografia teria evitado.

Conclusões

Um ataque man-in-the-middle é um problema de autenticação fantasiado de criptografia. A criptografia sem identidade verificada não protege nada, que foi o que DigiNotar e Superfish demonstraram em sessões que pareciam seguras na barra de endereços.

Os controles que funcionam contra um ataque man-in-the-middle são específicos: validar certificados e nunca desativar a verificação, enviar HSTS e pré-carregar o domínio, exigir TLS mútuo onde as duas pontas são suas, e mover a autenticação para FIDO2 onde o roubo de sessão é o risco real. O pinning é uma ferramenta estreita, não um padrão.

Os testes dizem quais desses você tem de fato. As fraquezas por trás de um ataque man-in-the-middle —canais inseguros, versões obsoletas de TLS, cabeçalhos ausentes, trust managers permissivos, NTLM legado— podem ser encontradas antes que um atacante as encontre, e um ataque man-in-the-middle é uma das poucas ameaças cuja lista de correções é assim de curta e assim de específica.

Perguntas frequentes

O HTTPS previne ataques man-in-the-middle?

Só quando a validação de certificados funciona. O HTTPS cifra o canal e autentica o servidor, e é a autenticação que bloqueia um ataque man-in-the-middle. Uma aplicação que desativa a verificação de certificados, confia em uma CA fraudulenta ou aceita um nome de host que não confere está cifrando seu tráfego direto para o atacante. A regra SAST-NATDC da Fluid Attacks existe porque a validação desativada dentro de código HTTPS no mais correto é frequente.

Como o HSTS detém o SSL stripping?

Elimina a solicitação sem criptografia da qual o SSL stripping depende. O cabeçalho Strict-Transport-Security instrui o navegador a usar HTTPS para um domínio e o impede de deixar que os usuários ignorem os avisos de certificado. Protege todas as conexões depois da primeira. O pré-carregamento fecha também a primeira, e por isso a Fluid Attacks inscreveu suas três zonas principais na lista de pré-carregamento.

O certificate pinning previne todos os ataques man-in-the-middle?

Não. A OWASP hoje desaconselha o pinning na maioria dos casos, e afirma que "there is almost no situation where you should consider pinning" e que as aplicações não nativas não deveriam fixar certificados. O certificate pinning defende um par cliente-servidor diante de uma autoridade não confiável. Não detém um ataque man-in-the-middle montado a partir de um dispositivo que o atacante pode instrumentar, e quebra quando os certificados rodam.

A autenticação de dois fatores detém um ataque adversary-in-the-middle?

Não se o segundo fator for um SMS ou um código gerado em um app. Um proxy AiTM encaminha o código em tempo real e rouba o cookie de sessão autenticado, então o ataque man-in-the-middle tem êxito com o segundo fator no lugar. A CISA chama o FIDO/WebAuthn de "the only widely available phishing-resistant authentication", porque uma credencial FIDO se recusa a assinar um desafio para um domínio que não corresponde à sua origem registrada.

A Fluid Attacks avalia fraquezas de man-in-the-middle?

Sim, em código de aplicação, configuração de transporte, apps móveis e avaliações de rede autorizadas, com cada achado mapeado a uma fraqueza catalogada e verificado após a remediação. No benchmark da Fluid Attacks de 36 ferramentas AppSec de terceiros contra uma aplicação com 1.201 vulnerabilidades semeadas, um pentester alcançou 89,6 % de recall com 100 % de precisão, enquanto o melhor scanner automatizado chegou a 22,7 %. As falhas por trás de um ataque man-in-the-middle caem dos dois lados dessa lacuna: os scanners encontram o cabeçalho ausente, as pessoas encontram o fluxo que aceita um certificado que deveria recusar.

Teste os controles que você acha que tem

Nossos pentesters e scanners revisam sua configuração de transporte, sua validação de certificados e sua autenticação como faria um atacante executando um ataque man-in-the-middle, para que as fraquezas que tornam a interceptação possível sejam corrigidas antes que alguém as use. Teste gratuito · Fale conosco.