O mais recente sequestro do BGP teve como alvo um fornecedor de software de hospedagem.

Como o atacante sequestrou esse espaço de endereços IP?

A partir das 20h57 UTC de 28 de agosto de 2026, um novo prefixo entrou na tabela de roteamento global. O prefixo 162.55.80.0/24 foi anunciado ao longo do AS path:

… 6204 62390 24940

Este intervalo incluía endereços IP usados ​​para o endpoint de atualização do software da Softaculous, bem como para seu site de clientes e faturamento. Tratou-se de um sequestro de prefixo mais específico referente ao 162.55.0.0/16, normalmente anunciado pela Hetzner Online (AS24940). É provável que a rota tenha sido originada pelo penúltimo AS do caminho, NexonHost (AS62390), seja por uma invasão ao sistema ou por um cliente que explorou falhas em sua segurança.

O sequestro também incluiu um AS path com uma origem falsificada. Como o atacante adicionou 24940 como o ASN mais à direita do caminho, a rota foi considerada válida pelo RPKI por dois motivos: o ROA exigia que a origem fosse o AS24940, mas também porque permitia que o comprimento do prefixo estivesse entre 24 e 16. Como resultado, essa rota era válida para o RPKI e não corria o risco de ser descartada pelos sistemas autônomos que rejeitam as rotas não válidas para o RPKI.

Como não havia nenhuma rota existente para 162.55.80.0/24 competir, esta se propagou até onde outros mecanismos de filtragem de rotas permitiram. E como era uma rota mais específica, qualquer tráfego destinado a este intervalo de IP a preferiria em relação à rota legítima (162.55.0.0/16) devido à preferência dos roteadores pela correspondência com o prefixo mais longo.

A linha do tempo da origem de 162.55.80.0/24 é representada na visualização BGP da Kentik abaixo. O gráfico mostra a porcentagem de pontos de observação do BGP que tinham 162.55.80.0/24 em suas tabelas de roteamento ao longo do tempo e pode ser interpretado como uma medida da propagação da rota.

A visualização ajuda a ilustrar a linha do tempo da presença de 162.55.80.0/24 na tabela de roteamento global. Desde que surgiu pela primeira vez às 20:57 UTC do dia 28 de agosto, a rota oscilou com intermitências várias vezes até que o verdadeiro AS24940 começou a anunciá-la quase 12 horas depois, às 08:44 UTC do dia 29 de agosto. Às 14:10 UTC do dia seguinte, o AS24940 já tinha retirado a sua rota.

A rota de sequestro retornou às 19:55 UTC do dia 29 de agosto e se ativou repetidamente até que, mais uma vez, o verdadeiro AS24940 interveio e começou a anunciar 162.55.80.0/24 às 05:45 UTC do dia 30 de agosto, momento em que o sequestro foi retirado. No momento em que este artigo foi escrito, o AS24940 continua anunciando o prefixo 162.55.80.0/24.

Como mostra a visualização acima, a propagação da rota de sequestro foi ligeiramente menor do que a da rota legítima, indicando que houve algum tipo de filtragem de rotas que limitou a propagação subsequente. Independentemente disso, a propagação do sequestro foi substancial e gerou o risco de um desvio generalizado do tráfego para 162.55.80.0/24.

Como o atacante conseguiu um certificado TLS válido?

O sequestro do BGP por si só não era suficiente para realizar esse ataque. Outra peça fundamental deste quebra-cabeça é a emissão de certificados TLS válidos para o atacante. Essa mesma vulnerabilidade foi explorada no ataque de 2022 contra a KLAYswap, uma corretora de criptomoedas on-line com sede na Coreia do Sul.

Em seu excelente artigo sobre esse incidente, Henry Birge-Lee e seus colegas de Princeton escreveram:

Ainda assim, ironicamente, o KLAYswap e a Kakao estavam usando o TLS corretamente, e não foi uma vulnerabilidade no protocolo TLS que foi explorada durante o ataque. Em vez disso, o ataque explorou a falsa confiança que o TLS deposita na infraestrutura de roteamento. \ … \ Usando o sequestro do BGP, o atacante primeiro teve como alvo a infraestrutura de chave pública (PKI) e lançou um ataque do tipo man-in-the-middle contra o processo de distribuição de certificados. Somente após obter um certificado digital válido para o domínio alvo, o ataque foi direcionado a usuários reais, com a distribuição do arquivo JavaScript malicioso por meio de uma conexão criptografada.

A garantia de identidade do TLS é tão confiável quanto o sistema de roteamento que direciona o tráfego usado para validar os certificados para o lugar certo. Para solucionar essa fragilidade, a autoridade certificadora pública Let’s Encrypt vem implementando a Corroboração de Emissão Multiperspectiva (MPIC) há vários anos.

Em MPIC, em vez de uma autoridade de certificação (CA) validar o controle de um domínio a partir de um único ponto de observação (que poderia ser substituído por um sequestro BGP localizado), a CA realiza verificações simultâneas a partir de múltiplas localizações da rede geográfica e topologicamente diversas e requer a concordância de um quórum antes de emitir um certificado. Um sequestro que atinge apenas alguns pontos de observação é detectado pela falta de consenso entre os demais.

No entanto, neste caso, como a rota de sequestro era uma rota mais específica e sem concorrência, sua propagação global criou um quórum completamente controlado pelo atacante.

Prevenção e detecção

Ainda em 2022, um sequestro de BGP teve como alvo o serviço de criptomoedas Celer Bridge, hospedado pela AWS. Na postagem que escrevi na época, citei a prática que seguia a AWS, na época, de usar ROA muito permissivas que permitiam múltiplas origens e prefixos “variando em tamanho de /10 até /24” como um fator que limitava a capacidade de validação de origem com o RPKI para ajudar. Na postagem, eu acrescentei,

“Uma abordagem alternativa para a criação de ROA seria fazer o que outras redes, como Cloudflare e Comcast, fizeram: definir a origem e o comprimento máximo do prefixo para que sejam idênticos à forma como o prefixo é roteado. Embora essa abordagem acarrete um custo adicional de atualização de um ROA sempre que uma rota é modificada, também deixa pouco espaço para que versões alternativas da rota entrem em circulação”.

AWS agora faz correspondências exatas em seus ROA, mas devemos ter cuidado para não superestimar as capacidades de ROV com o RPKI para nos proteger de um “adversário determinado” como este. Sempre soubemos que os atacantes podem falsificar AS paths para tornar os sequestros válidos para o RPKI. Mas se a Hetzner Online tivesse usado ROA rigorosas com comprimentos máximos de prefixo que correspondessem às suas rotas, a circulação do sequestro teria sido bastante reduzida, permitindo que o MPIC impedisse a emissão de certificados TLS válidos.

Assim como no caso do ataque à Celer Bridge, o monitoramento do BGP poderia ter alertado que um novo espaço de endereços /24 da Hetzner Online estava sendo anunciado, embora a origem falsificada pudesse fazê-lo parecer legítimo.

Mas quando este novo /24 apareceu com um upstream inesperado de NexonHost (AS62390), um alerta deveria ter sido disparado para chamar a atenção para esta anomalia. O detalhe crucial que teria diferenciado este alerta do aparecimento de mais um peer da Hetzner Online seria o fato de a nova origem estar visível para a grande maioria dos pontos de observação do BGP. Em outras palavras, esse novo prefixo estava sendo transitado exclusivamente por esse provedor de hospedagem relativamente desconhecido, e isso poderia ter chamado a atenção da equipe de operações de rede da Hetzner Online.

Conclusão

Embora a validação de origem de rotas com o RPKI tenha contribuído significativamente para a redução de problemas de roteamento, esta não foi projetada para evitar completamente um incidente como este. Sua função principal é reduzir a propagação dos erros de origem vazados, que geralmente envolvem erros inocentes. Também vimos os benefícios de ROV com o RPKI durante os chamados sequestros “intencionais, mas também acidentais”, como o bloqueio da Telegram na Índia que aconteceu em junho. Independentemente disso, umas ROA mais rigorosas poderiam ter permitido que a validação de origem com o RPKI reduzisse a propagação da rota sequestrada a ponto de o MPIC poderia ter impedido a emissão de um certificado TLS válido.

Os ataques à infraestrutura como esses destacam problemas universais que não se restringem a criptomoedas ou software de hospedagem. As empresas que buscam proteger suas infraestruturas voltadas para a Internet precisam implementar um monitoramento robusto de BGP e o DNS em sua infraestrutura e em quaisquer dependências baseadas na Internet que possam ter.

As empresas devem rejeitar rotas inválidas para o e, ao mesmo tempo, criar ROA rigorosas para seu espaço de endereçamento IP, incluindo comprimentos máximos de prefixo que correspondam exatamente aos comprimentos de prefixo usados em suas rotas. De fato, a RFC 9319 Uso de maxLength na infraestrutura de chave pública de recursos (RPKI) afirma que é uma “melhor prática atual” que as redes evitem completamente o uso do atributo maxLength nas ROA, exceto em certas circunstâncias. Deixar o campo maxLength em branco em um ROA tem o mesmo efeito que configurá-lo para que corresponda ao prefixo. Essas medidas podem reduzir significativamente as oportunidades para um atacante comprometer sua infraestrutura de Internet.