Para entregar um pacote, a rede depende de uma cadeia de pequenas respostas, todas aceitas na base da confiança: qual endereço de hardware corresponde a este IP, qual roteador é a saída, qual servidor responde por este nome, qual caminho chega àquela rede. Cada resposta vem de um protocolo que, na maioria dos casos, foi projetado numa época em que quem estava na rede era colega, e não adversário. Desviar tráfego é a arte de dar uma dessas respostas com informação falsa, para que a vítima mande o tráfego para o atacante em vez de mandá-lo para o next hop (o próximo salto) correto. Quando o atacante controla o caminho, ele pode ler o que passa, alterar o conteúdo ou descartá-lo. Essa posição é o (o homem no meio), e cada método desta série é uma forma diferente de chegar a ela.

Este artigo é o mapa. Ele explica a jogada que todos esses métodos têm em comum, organiza os métodos pela camada que exploram e leva ao passo a passo detalhado de cada um. Cada item traz a defesa padrão ao lado do ataque, porque, num site de treinamento, entender como um ataque é feito serve para reconhecê-lo numa captura e bloqueá-lo.

ANTESVocêO serviçoO tráfego vai direto ao serviçoDEPOIS DO DESVIOVocêNo meioO serviçoO tráfego é desviado por um terceiro primeiroque pode lê-lo, alterá-lo ou descartá-lo

A jogada em comum

Normalmente, os dois lados trocam pacotes direto: o seu dispositivo resolve o next hop e envia para ele, o next hop encaminha, e a resposta volta pelo mesmo caminho. O desvio coloca um terceiro nesse caminho. O atacante não quebra a criptografia, não adivinha senha nem explora um buffer overflow; ele responde a uma pergunta de rotina antes do dono legítimo, ou de forma mais convincente, e a vítima atualiza o próprio estado (o cache , uma rota padrão, a resposta do resolver, a tabela de roteamento) para apontar para o atacante. Daí em diante, a vítima colabora com a própria interceptação, em geral sem nenhum sintoma visível, porque um atacante competente encaminha o tráfego adiante e a conversa continua funcionando.

Disso saem duas consequências, e elas definem todas as defesas. A primeira: o ataque explora a confiança embutida no protocolo, e não um defeito, então a correção quase nunca é um patch. A correção é acrescentar autenticação em volta do protocolo (criptográfica, como no ou no ) ou uma validação feita pela infraestrutura (o switch ou o equipamento do primeiro hop conferindo as respostas, como no Dynamic ARP Inspection ou no RA Guard). A segunda: como a vítima não apresenta sintoma, detectar o ataque é perceber a mudança de estado (o endereço MAC do gateway que mudou, um segundo dispositivo respondendo pelo mesmo nome, um certificado que de repente é outro), e não perceber uma falha.

Onde cada método atua

Os métodos se agrupam pela pergunta que respondem com mentira, e essa pergunta indica também a camada em que eles atuam e o lugar certo para a defesa.

MétodoCamada / perguntaO que a resposta falsa fazA defesa padrão
(envenenamento de ARP)Enlace: qual MAC corresponde a este IP?Associa o IP do gateway ao MAC do atacante no cache ARP das vítimasDynamic ARP Inspection com ; entradas estáticas para os hosts críticos
MAC floodingEnlace: o encaminhamento no switchEstoura a tabela MAC do switch, que passa a fazer flooding dos frames (quadros) para todas as portas, inclusive a do atacantePort security (limitar os MACs aprendidos por porta)
hoppingEnlace: a que VLAN a porta pertenceChega a uma VLAN da qual a porta não faz parte, por switch spoofing (DTP) ou por double tagging na VLAN nativaDesativar o DTP, usar uma VLAN nativa sem uso, fazer pruning nos trunks
Rogue (servidor DHCP falso)IP local: qual é o meu gateway e o meu resolver?Entrega à vítima o atacante como default gateway e como servidor DNSDHCP snooping (só confiar na porta do servidor verdadeiro)
Rogue RA IPv6IP local: qual é o meu gateway IPv6?Anuncia o atacante como roteador IPv6 no mesmo linkRA Guard, SEND, filtragem na camada 2 ( 6105)
redirectIP local: existe um primeiro hop melhor?Manda o host rotear um destino pelo atacanteRejeitar os redirects que falham nas verificações de origem e de sub-rede da RFC 1122; desativar a aceitação
Spoofing de LLMNR / NBT-NS / mDNSNome: a quem pertence este nome não qualificado?Responde, antes de qualquer outro, por um nome pelo qual nenhum servidor DNS respondeDesativar o LLMNR e o NetBIOS Name Service onde o DNS dá conta
Nome + proxy: onde está a configuração do proxy?Entrega uma autoconfiguração de proxy que faz o navegador passar pelo atacanteDefinir o WPAD explicitamente ou desativar a detecção automática de proxy; os nomes wpad.tld hoje resolvem para loopback
DNS cache poisoningNome: qual é o endereço deste domínio?Planta um endereço falso no cache de um resolverValidação DNSSEC; porta de origem e ID da consulta aleatórios (pós-Kaminsky)
Evil twinAssociação sem fio: qual AP pertence a esta rede?Apresenta um access point falso com o verdadeiro, para que os clientes se associem a eleWPA2/ com validação do certificado do servidor; 802.11w
root takeoverTopologia do enlace: qual switch é o root bridge?Assume o papel de root do spanning tree para que o tráfego passe pelo switch do atacanteRoot Guard e Guard nas portas de borda
Transporte: isto vai ser HTTPS?Mantém a vítima em HTTP sem criptografia, para que a mudança para TLS nunca aconteçaHSTS e HSTS preload; modo somente HTTPS (RFC 6797)
relayIdentidade: quem está se autenticando?Repassa a autenticação da vítima para outro serviço, como se fosse a vítimaAssinatura e , channel binding (EPA), restringir o NTLM
(sequestro de prefixo): qual rede alcança este prefixo?Anuncia o prefixo de terceiros para que a internet o roteie até o atacanteRoute origin validation com ; filtragem de prefixos

O primeiro bloco é o dos métodos de rede local: são os que o atacante alcança estando no mesmo segmento, e os que o switch consegue barrar, porque vê todos os frames. O grupo de resolução de nomes explora os fallbacks, as alternativas que o cliente vai tentando quando o DNS está lento ou indisponível. O grupo de transporte e identidade (SSL stripping, NTLM relay) não desvia pacote nenhum: ele aproveita um desvio que algum dos outros métodos já criou e transforma a posição no meio do caminho em texto claro roubado ou num login roubado. O BGP hijack é a mesma jogada na escala da internet inteira, sem nenhum switch para defender a rede; por isso a resposta a ele é criptográfica (RPKI), e por isso ele tem um artigo só dele.

Por que os métodos de rede local formam uma só família

O ARP poisoning é o arquétipo, e ele mostra por que os outros se parecem tanto com ele. O Address Resolution Protocol da RFC 826 (David Plummer, novembro de 1982) associa um endereço IP a um endereço de hardware com uma requisição e uma resposta, e não tem nenhuma noção de quem tem o direito de responder: o host guarda no cache o par de endereços do remetente de qualquer resposta que veja, e sobrescreve uma entrada existente quando chega uma resposta nova. A RFC 5227, que padronizou os anúncios gratuitos que os hosts usam para reivindicar um endereço, admite isso abertamente na própria seção Security Considerations: "A malicious host may send fraudulent ARP packets on the network ... it is easy for a host to answer all ARP Requests with Replies giving its own hardware address." O protocolo foi feito para um ambiente de cooperação, e, num segmento compartilhado, a cooperação é uma suposição, não uma garantia.

Todos os outros métodos locais são a mesma suposição, em outro protocolo. O rogue DHCP se aproveita de que o cliente aceita a configuração (o gateway, o resolver) de qualquer servidor DHCP que responder, e a RFC 2131 diz com todas as letras que "unauthorized DHCP servers may be easily set up" para enviar "spoof routers" ("roteadores falsos") e "spoof nameservers" ("servidores de nomes falsos"). Os Router Advertisements IPv6 falsos se aproveitam de que o host adota como roteador padrão a origem de qualquer RA que ouvir, o problema que a RFC 6104 foi escrita para descrever. Os ICMP redirects se aproveitam de que o host, se não fizer nenhuma verificação, muda a rota para um destino só porque uma mensagem de redirect mandou. O LLMNR, o NetBIOS Name Service e o mDNS se aproveitam de que, quando o DNS não tem resposta, o cliente pergunta ao segmento inteiro e acredita na primeira resposta que chegar. Não são vulnerabilidades separadas, para corrigir uma a uma: é uma mesma geração de protocolos diante de um segmento hostil, e por isso as defesas também se parecem. Deixe a infraestrutura que vê todos os frames (o switch, o equipamento do primeiro hop) validar as respostas, e desative os protocolos de fallback de que ninguém precisa de verdade.

Por que as defesas se repetem

Leia a coluna da direita da tabela e você vai ver três respostas se repetindo; é isso que vale a pena levar deste artigo.

A primeira é deixar o switch confirmar o binding (a associação entre IP e MAC). O DHCP snooping ensina ao switch em que porta fica o servidor DHCP verdadeiro e monta uma tabela com o endereço que cada porta recebeu legitimamente; o Dynamic ARP Inspection, então, confere cada pacote ARP com essa tabela e descarta os que mentem. Esse é o controle que, sozinho, acaba com o ARP poisoning numa rede gerenciada. O RA Guard faz o mesmo com os Router Advertisements IPv6. O switch é o lugar certo para isso porque é o único equipamento que vê todos os frames do segmento e pode recusar os falsos já na porta.

A segunda é desativar o fallback que confia em qualquer um. O LLMNR, o NetBIOS Name Service, a detecção automática do WPAD e o DTP são facilidades de uma época mais amigável: cada um deles é um protocolo que responde a uma pergunta de boa vontade e sem nenhuma prova. Numa rede moderna, em que o DNS, a configuração explícita de proxy e os trunks configurados manualmente fazem o mesmo trabalho, esses fallbacks são só superfície de ataque, e a mitigação é desativá-los, não protegê-los.

A terceira é autenticar a informação em si. Quando a infraestrutura não tem como garantir nada (o pacote atravessa redes que ninguém controla em conjunto), a única resposta é criptográfica: o HSTS, para que o navegador se recuse a ficar em texto claro; o DNSSEC, para que o resolver distinga um registro forjado de um verdadeiro; o RPKI, para que o roteador distinga um prefixo sequestrado da sua origem verdadeira; e a assinatura de SMB e de LDAP (Lightweight Directory Access Protocol), para que uma autenticação repassada falhe na verificação de integridade. São as defesas mais difíceis de implantar, e os ataques que dependem delas para serem contidos (a falha de Kaminsky, o SSL stripping, o NTLM relay, o BGP hijack) são os que têm as histórias mais longas.

Os ataques desta série

Cada um dos itens abaixo tem, ou vai ter, um passo a passo detalhado próprio. Os que já foram escritos estão com link; os demais chegam junto com os milestones que cobrem os protocolos de cada um, e este artigo de abertura ganha o link de cada um à medida que ele é publicado.

  • ARP poisoning numa com switches: o arquétipo, passo a passo, e por que o Dynamic ARP Inspection acaba com ele. A base para esse estudo é ARP e endereços MAC.
  • MAC flooding e STP root takeover: as duas formas de fazer o próprio switch levar o tráfego pelo caminho errado, e as proteções configuradas na porta que barram os dois ataques.
  • VLAN hopping (virtual local area network): switch spoofing e double tagging, e a configuração de trunk que fecha as duas brechas.
  • Rogue DHCP e Router Advertisements IPv6 falsos: entregar à vítima um gateway falso, e os recursos de snooping e de guard que respondem a isso.
  • ICMP redirects e spoofing de LLMNR/NBT-NS/mDNS: os pequenos protocolos que confiam em qualquer resposta, e por que a correção costuma ser desativá-los.
  • DNS cache poisoning: tratado a fundo no artigo a falha de Kaminsky, o verão em que a internet inteira corrigiu o mesmo bug ao mesmo tempo.
  • Evil twin e o caminho sem fio: o access point falso, para ler junto com KRACK e o handshake do Wi-Fi, que mostra o que muda quando o meio é o ar.
  • SSL stripping: manter a vítima em texto claro, o ataque que o HSTS foi criado para responder, e o mecanismo de interceptação por proxy, que funciona de um jeito parecido, em interceptação com SSL forward proxy.
  • NTLM relay: repassar uma autenticação do Windows para outro serviço, em NTLM explicado.
  • BGP hijack (Border Gateway Protocol): a mesma jogada através da internet, em BGP e o gargalo do roteamento.

Para ver qualquer um desses ataques na rede, o artigo as ferramentas de interceptação cobre a parte de captura e análise, que é onde o reconhecimento começa.

Fontes