Ataque de spoofing de IP faz o mundo inteiro enviar denúncias de abuso para seus amigos

• A Hetzner encaminhou uma denúncia de abuso dizendo que havia ocorrido uma varredura de portas SSH a partir de 195.201.9.37, mas dentro do servidor não apareceram evidências de processo malicioso, alterações em arquivos ou tráfego anômalo
• O fluxo real visto com tcpdump mostrou que o servidor não estava se conectando para 22/tcp externo; em vez disso, vários hosts na internet estavam devolvendo TCP RST ao servidor, algo mais próximo de backscatter
• A causa central é que, por meio de redes que não aplicam filtragem BCP38, é possível enviar pacotes com IP de origem arbitrário; em protocolos como TCP, QUIC e TLS, que exigem resposta de ida e volta, o atacante não consegue ver diretamente as respostas
• O mesmo padrão apareceu em outros 2 relays Tor do autor, e a lista tor-relays e uma issue do Tor Project já tinham relatos semelhantes desde dias antes, incluindo casos em que alguns nós ficaram temporariamente fora do ar
• O atacante pode falsificar o IP da vítima como origem e enviar tentativas de conexão para vários destinos SSH, induzindo denúncias automáticas de abuso, inclusão em blocklists e ações do provedor de hospedagem

---

Denúncia de abuso da Hetzner e inspeção do servidor

• A Hetzner enviou um e-mail de AbuseInfo sobre o IP 195.201.9.37
  • O denunciante era [e-mail]
  • Os logs incluíam entradas DENIED apontando para 22/tcp de vários destinos 202.91.16x.x
• À primeira vista, parecia que o servidor havia começado a abrir conexões SSH para a internet, uma situação que normalmente faria suspeitar de infecção por malware
• Após 1 a 2 horas de verificação, o estado do servidor parecia praticamente normal
  • Nenhum processo anômalo
  • Nenhuma alteração no sistema de arquivos
  • Nenhum tráfego de rede anormal do ponto de vista do hipervisor
• Esse servidor executava vários serviços distribuídos e federados
  • Relay Syncthing
  • Instância Mastodon
  • Relay Tor
  • Homeserver Matrix
• O relay Tor se conecta a alguns relays em 22/tcp, mas isso não batia com a rede da denúncia, e nem os logs de Matrix e Mastodon nem a fila Sidekiq do Mastodon mostravam rastros de requisições para IPs ou portas aleatórios

O fluxo real de pacotes mostrado pelo tcpdump

• No início, a tentativa foi verificar tráfego saindo do servidor para 22/tcp externo com o filtro dst port 22
• Ao trocar o filtro para not src host 195.201.9.37, apareceram pacotes TCP RST vindos de 22/tcp de vários IPs externos para portas efêmeras do servidor do autor
• Na prática, o servidor não havia enviado conexões para 22/tcp de hosts arbitrários; eram hosts aleatórios da internet enviando pacotes de reset para o servidor
• Esse padrão bate com backscatter, em que os pacotes de resposta retornam ao IP falsificado por causa de spoofing de IP de origem

Spoofing de IP de origem e a brecha do BCP38

• Na internet, o IP de destino precisa estar correto, mas ainda é possível enviar pacotes para vários destinos usando um IP de origem falso
• O BCP38 é a prática recomendada atual para permitir que redes pares usem como origem apenas os endereços IP esperados
• Essa filtragem só é eficaz se for aplicada no começo do caminho do pacote
  • No nível de grandes transit providers, é difícil fazer uma filtragem útil, porque os pares esperam que o provedor encaminhe tráfego para toda a internet
• Basta encontrar um único transit provider sem BCP38 para conseguir enviar pacotes com IP de origem arbitrário
• A APNIC publicou em 2023 um texto sobre por que a validação de endereço de origem ainda continua sendo um problema
• Famílias como TCP, QUIC e TLS exigem comunicação de ida e volta, então, ao falsificar o IP de origem, o atacante não consegue ver a resposta
  • Isso não serve bem para verificar resultados de uma varredura de portas comum
  • Já existem formas conhecidas de abuso, como DDoS por reflexão

Por que esse spoofing gera dano real

• O fluxo mais plausível é que alguém esteja usando o IP do autor como origem para enviar tentativas de conexão ao 22/tcp de vários hosts na internet
• Se o objetivo fosse apenas descobrir portas abertas, isso não faria muito sentido, porque quem falsificou o IP não consegue ver as respostas
• No passado existiu a técnica Idle Scanning, mas ela dependia de servidores pouco ocupados e contadores previsíveis na pilha de rede, e deixou de ser prática há décadas
• O volume de tráfego é baixo demais e a duração longa demais, então também parece pouco convincente a hipótese de um scanner mal configurado com IP de origem preenchido errado
• O dano real surge da automação das denúncias de abuso
  • As tentativas de conexão falsificadas alcançam redes com honeypots ou sistemas de detecção de intrusão
  • Alguns sistemas enviam automaticamente denúncias de abuso
  • O provedor de hospedagem pode interpretar de forma errada que o servidor da vítima foi comprometido ou é malicioso

O mesmo padrão se repetiu em outros relays Tor

• O autor voltou a confirmar que seu servidor operava como relay Tor
• Um relay Tor é um nó interno da rede Tor e, se não for um exit node, não se comunica diretamente com a internet pública
  • O relay encaminha tráfego anônimo criptografado entre nós participantes da rede Tor
  • Alguns relays atuam como Guard Node e podem ser pontos de entrada na rede Tor
• O autor executou tcpdump também em mais 2 relays, em países e ISPs diferentes
  • Um relay em conexão residencial
  • Um relay em uma VPS Linode no Japão
• Nos dois relays apareceu o mesmo padrão de respostas TCP falsificadas vindas de 22/tcp externo para o IP do relay
• O autor enviou um e-mail para a lista tor-relays, e já existia uma issue do Tor Project sobre o mesmo fenômeno, diagnosticado desde alguns dias antes
• Esse ataque de spoofing começou antes em outros tipos de nós, não apenas relays, e houve casos em que alguns nós ficaram temporariamente fora do ar por causa de conexões falsificadas em escala maior

Um fluxo de ataque que pode atingir qualquer pessoa

• Um fluxo de ataque possível é o seguinte
  • O atacante consegue acesso a uma rede sem filtragem BCP38
  • Envia pedidos de conexão TCP para 22/tcp de vários hosts arbitrários na internet
  • Falsifica o IP de origem com o IP da vítima
  • Os hosts de destino ou seus sistemas de segurança entendem que foi a vítima quem tentou se conectar e enviam denúncias de abuso
  • Em escala suficiente, o IP da vítima pode parar em várias blocklists e o provedor de hospedagem pode suspender o servidor
• Não há nada nesse ataque que seja específico do Tor
• Não parece ser uma técnica particularmente difícil de executar para um atacante com motivação única
• A vítima não é o atacante real, mas sim a dona do IP de origem falsificado; ainda assim, pode sofrer impacto operacional por causa das denúncias automáticas de abuso e da reação do provedor de hospedagem

Um problema de operação da internet que ainda existe em 2024

• O fato de IPs de origem falsificados ainda serem um problema em 2024 chega perto de ser uma falha operacional da internet
• Além do BCP38, o RPKI passou por problema semelhante de adoção, e só começou a se expandir mais quando grandes empresas da internet passaram a impor exigências diretamente aos seus pares
• Os próximos passos para esse ataque não são claros
  • Ele já está acontecendo de fato
  • O autor não sabe se é um ataque já documentado antes
  • Não conhece um método para rastrear retroativamente a origem real dos pacotes com IP falsificado
• Operadores que receberem denúncias de abuso semelhantes precisam verificar que seu servidor pode não ser o agressor, e sim a vítima, além de reunir evidências para explicar isso ao provedor de hospedagem

[GN⁺]

Opiniões do Hacker News

• Esse tipo de problema é realmente irritante de lidar. Porque a resposta legítima a uma denúncia de abuso — “alguém fez spoofing do meu IP, não fui eu, e meu equipamento não foi comprometido” — é exatamente igual à desculpa que um agente malicioso daria.
  No fim, como no texto, você precisa apresentar uma prova de ausência para alguém que nem está tão interessado assim, o que na prática é quase impossível.

  • A Hetzner disse no e-mail que não era necessária uma resposta.
    Uma denúncia automática de abuso por algo que pode ser facilmente spoofado não justifica necessariamente a denúncia em si, mas pode ser um motivo para verificar rapidamente se meu servidor está operando normalmente e não foi tomado.
  • Uma resposta legítima deveria incluir uma prova real, como uma garantia no mundo real por um terceiro confiável.
    No mínimo, seriam necessários fundamentos sobre identidade e jurisdição, talvez até algo como uma chamada de vídeo. Não basta afirmar anonimamente na internet “sou uma boa pessoa” e pedir que acreditem.

• O mesmo vale para endereços MAC spoofados, endereços de e-mail, mensagens ARP, Neighbor Discovery e certificados TLS de intermediário.
  Ainda assim, é surpreendente que alguma coisa funcione.

  • A internet não está quebrada; ela tem uma utilidade e confiabilidade enormes.
    Se ela tivesse sido projetada e operada para ser perfeita, provavelmente quebraria de forma grave com bastante frequência. A capacidade de tolerar um pouco de imperfeição contribuiu muito para a robustez e a utilidade da internet.
    Isso não quer dizer que não devamos melhorá-la; é mais um alerta de que perseguir o perfeccionismo facilita cometer grandes erros que estragam tudo.
  • Endereços MAC que podem ser spoofados são bastante essenciais para a privacidade no Wi-Fi.
  • A rede de telefonia móvel SS7 tem um problema parecido: https://youtu.be/wVyu7NB7W6Y
  • Estou começando a achar que fazia sentido a China ter proposto reformar os protocolos da internet.
  • Ouço muitas reclamações sobre DNS, mas fico me perguntando o quão seguro ele realmente é e por que há tão pouco esforço para consertá-lo.

• Antigamente, eu escaneava servidores de reflexão DrDoS de uma forma parecida. Como nenhum provedor de hospedagem quer receber denúncias de varredura de portas, se você definisse o endereço de origem da varredura como um IP de um provedor de nuvem inocente e com boa reputação, os servidores refletores enviavam as respostas UDP para lá sem problemas.
  O provedor de nuvem obviamente recebia uma enxurrada de denúncias, mas, se você dissesse que não estava fazendo varredura a partir do seu servidor, o provedor verificava e não desligava o serviço. Como o servidor que enviava os pacotes de varredura spoofados não era detectado, era possível escanear repetidamente a internet inteira sem o problema comum de denúncias de abuso.
  Não sei com que frequência isso acontece de fato, mas é possível rastrear a origem dos pacotes spoofados voltando salto por salto em cooperação com as operadoras de trânsito. Certa vez, o JPMorgan trabalhou com a Cogent e me avisou para não enviar pacotes para os endereços IP deles. A propósito, entre as operadoras Tier 1 da internet, a Cogent é uma das mais tolerantes com spoofing.
  É a primeira vez que ouço falar desse método sendo usado especificamente contra o Tor, e isso é um pouco contraintuitivo. Eu imaginaria que quem envia pacotes spoofados seria apoiador do Tor. É mais provável que seja apenas um troll e, felizmente, os provedores que hospedam Tor provavelmente não vão se importar muito com isso.

  • A Cogent parece meio ruim no geral também.
    Pode ser apenas um troll, mas também pode ser alguém tentando fazer o Tor ser tratado como lixo radioativo porque ele atrapalha trabalhos de vigilância.

• Isso não é novidade. Alguns anos atrás, criei uma regra de firewall bem básica: se um pacote TCP de entrada para a porta de destino 22 tivesse SYN=1 e ACK=0, o IP de origem era bloqueado por um dia.
  Só que começaram a surgir reclamações de que certos sites e serviços não funcionavam, e descobri que, a cada poucos dias, chegavam pacotes assim de IPs de servidores populares como 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram e vários serviços de chat. Naturalmente, eram todos pacotes spoofados, e acabei adicionando um pouco mais de validação à regra de firewall.
  Por isso tenho bastante certeza de que isso é bem comum. Pessoalmente, sei que estou em um caso excepcional, operando vários endereços IP, mas preciso da flexibilidade de enviar pacotes para qualquer ISP usando qualquer um dos meus endereços de origem. Isso é importante para mim, e se um ISP filtrar por endereço de origem, é motivo para encerrar o contrato e mudar para outro ISP.

  • Se você realmente tem seus próprios endereços IP, isso é normal e esperado. Mas se é possível usar endereços IP do ISP A através do ISP B, ou vice-versa, isso sempre foi um bug e não deveria ser usado assim.
    Se for o segundo caso, está mais para algo na categoria de “ligar de novo o aquecedor da barra de espaço”, e espero que os ISPs corrijam suas redes quebradas.
  • Vou dar um exemplo real concreto.
    Em uma empresa, alguns ativos web eram hospedados no ambiente on-premises de uma filial, onde havia um link de 1 Gbps. Como a matriz tinha vários links de 10G e um data center bem decente, eles moveram as VMs web para a matriz, mas mantiveram os endereços IP atribuídos, ou seja, os IPs públicos fixos do ISP-A. O tráfego era roteado por VPN até a matriz, e o servidor usava o gateway padrão para enviar respostas com IP de origem do ISP-A pela conexão 10G do ISP-B.
    Assim, mesmo que a entrada ficasse limitada a 1G, a saída aproveitava 10G. Afinal, eram só requisições GET. Não era a configuração ideal e, no fim, os IPs foram trocados, mas parece um caso de uso válido.
    Em um segundo caso, havia dois links de ISPs diferentes, um ASN próprio e um bloco /23 próprio. Para balancear parte do tráfego, metade dos IPs ia pelo ISP-A e a outra metade pelo ISP-B. Funcionou bem, mas, ao tentar misturar um pouco mais o equilíbrio, apareceu um problema interessante. O primeiro /24 era anunciado ao ISP-A e o segundo /24 ao ISP-B, mas o ISP-A tinha filtragem RP. Então foi preciso anunciar todos os IPs também por lá.
    Pelo modo como o filtro RP funciona, não dá para fazer algo como prepend; todo o tráfego precisa entrar por eles. Se ele vê uma rota melhor para aquele prefixo, filtra. Durante meses eles se recusaram a corrigir, alegando segurança. Como a justificativa era “boas práticas de segurança”, posso dizer o nome do ISP: era a Virgin Media.
    Para constar, o link de internet com rp_filter não custava 20 dólares por mês, mas mais de 5 mil dólares por mês. Não dava para trocar porque não havia alternativa naquela região, mas, se houvesse, era óbvio quem perderia o contrato.
  • Como alguém que costuma ativar rp_filter em todos os lugares, fico realmente curioso para saber por que essa flexibilidade é necessária.
  • Tecnicamente, esses ISPs também provavelmente estariam em violação. É preciso ter um ASN próprio.

• A hipótese de que “alguém odeia relays Tor” não parece muito convincente em relação ao esforço envolvido
  Pode ser que a entidade que opera relays maliciosos esteja derrubando relays legítimos de forma antiética para aumentar a proporção da rede que controla

  • Quase certamente parece ser isso. Há bastante fuga da realidade por aqui sobre como é fácil para um atacante com acesso aos logs de alguns nós nem tão grandes enxergar os padrões de acesso a serviços de indivíduos
  • Se você odeia a rede Tor, uma forma mais fácil seria degradar o serviço despejando tráfego nela
    Rodar alguns downloads via BitTorrent já poderia ser suficiente

• O que seria necessário para que um número suficiente de operadoras de rede recusasse o tráfego de todos os ASes que não implementam BCP38, de modo que spoofing deixe de ser possível?

  • Só a Cloudflare provavelmente já bastaria
    Como ela já controla tráfego inbound suficiente, a mensagem “verificando a segurança da conexão” poderia passar a ter um sentido real
  • É preciso encontrar uma forma de fazer as operadoras de rede se importarem. Especialmente operadoras de trânsito Tier 1 ou redes anormalmente grandes
    Ainda assim, reduzir o fator de amplificação por reflexão é muito mais fácil. Isso porque, em IPv4, dá para escanear vetores de reflexão e reclamar com quem responde com 10 vezes o número de bytes recebidos

• É um problema parecido com swatting. Depende de uma entidade com autoridade tomar medidas fortes com base em denúncias não verificadas
  A diferença parece ser que, em vez de contatar diretamente a autoridade, usa-se um terceiro não relacionado para enviar a denúncia

• Para solicitações que consistem em um único pacote e não têm ida e volta, acho que um sistema não deveria enviar automaticamente denúncias de abuso, a menos que seja tráfego em nível de negação de serviço
  Especialmente no caso de SSH, antes que qualquer tipo de handshake aconteça, não há como considerar aquilo uma tentativa de conexão válida

  • Se qualquer pessoa pode enviar uma denúncia de abuso, o provedor do servidor deve verificar a denúncia de fato antes de acionar medidas contratuais como “se não responder em 2 dias, o servidor será suspenso”
    Meu servidor principal também já caiu por causa de uma denúncia falsa de abuso. Alegavam que meu IP estava sofrendo um ataque DoS acima de 1 Gbps, mas a conexão do meu servidor era limitada a 400 Mbps. Bastaria uma pessoa ler a denúncia para perceber que era impossível, e eu não teria precisado brigar por telefone com o suporte durante dois dias enquanto estava de férias
  • Mas também há casos em que a ação abusiva que realmente aparece, como um port scan, é apenas esse único pacote

• Isto é como a versão IP de swatting, assédio por patentes, incriminar inocentes e pedidos de remoção DMCA para eliminar concorrentes
  Essencialmente, é uma forma de transformar mecanismos antiabuso em arma para atacar alvos indesejados. É interessante que uma entidade com autoridade se torne o elo fraco e possa ser usada ativamente para cumprir os objetivos de agentes inescrupulosos, mas não é um fenômeno totalmente novo

  • Se o atacante for esperto e também tiver seu próprio relay, quanto mais relays alheios ele derrubar, maior fica a probabilidade de o relay dele ser escolhido
    Olhando os gráficos de número de relays e de “advertised bandwidth” em metrics.torproject.org, não parece ter feito uma grande diferença, mas ainda assim é interessante
    A pior parte é que lugares que imitam extorsionários como “Watchdog Cyber Defense”, Spamhaus, Shadowserver ou UCEPROTECT podem enviar milhões de denúncias automáticas, e os hosts basicamente precisam atendê-las se não quiserem que seus blocos de IP entrem em listas de bloqueio

• Não há solução in-band para este problema, mas pode haver uma solução out-of-band
  Por exemplo: (1) avisar ao ISP de destino que ele está recebendo tráfego reverso; (2) esse ISP verifica de onde vêm os pacotes e avisa o ISP correspondente; (3) repetir a etapa 2 até encontrar a origem; (4) isolar parte dessa rede até que ela funcione corretamente
  No fim das contas, a internet é feita de pessoas

  • Algumas pessoas às vezes se surpreendem com o fato de que a internet inteira funciona porque existe uma parcela da humanidade que realmente gosta de administrar o jogo de canos mais exagerado do mundo
  • As etapas 2 e 3 exigem que muita gente trabalhe de graça para resolver o problema dos outros
  • Referência: https://news.ycombinator.com/item?id=41985920