Extrato: Um breve sequestro de BGP em 2025 mostrou como a segurança do roteamento pode falhar quando os atacantes exploram vulnerabilidades no processo de integração de provedores.
Durante a sessão do Grupo de Interesse Especial (SIG) do APNIC sobre Segurança do roteamento) que fez parte de APRICOT 2026/APNIC 61, o APNIC e LACNIC apresentaram um estudo de caso sobre um sequestro de BGP que combinou um ataque técnico com engenharia social. O incidente aconteceu em julho de 2025. Este artigo explica o incidente, a coordenação entre os Registros Regionais da Internet (RIR) e o que isso significa para as ROA (Route Origin Authorizations) e as ASPA (Autonomous System Provider Authorizations).
(Acesso livre, não requer assinatura)
O incidente
O primeiro relatório veio de um usuário que não conseguia enviar e-mails. As mensagens eram aceitas pelo servidor, mas nunca chegavam ao destinatário. Inicialmente, isso pareceu um problema rotineiro do sistema, pois ocorreu no final da noite. Por isso, a equipe decidiu pesquisar no dia seguinte. Uma análise mais detalhada mostrou que parte do espaço de endereços do LACNIC estava sendo originado por redes que não estavam autorizadas a fazê-lo.
A análise mostrou que o atacante falsificou o Número do Sistema Autônomo (ASN) de modo que a rota anunciada pelo AS do atacante não fosse marcada como inválida. Esta estratégia contribuiu para a propagação de anúncios falsos. O atacante também redirecionou o tráfego através de um servidor upstream que, posteriormente, foi confirmado que se tratava de outra vítima, e não de um cúmplice.
Ocorreram três eventos breves de sequestros:
O incidente
O primeiro relatório veio de um usuário que não conseguia enviar e-mails. As mensagens eram aceitas pelo servidor, mas nunca chegavam ao destinatário. Inicialmente, isso pareceu um problema rotineiro do sistema, pois ocorreu no final da noite. Por isso, a equipe decidiu pesquisar no dia seguinte. Uma análise mais detalhada mostrou que parte do espaço de endereços do LACNIC estava sendo originado por redes que não estavam autorizadas a fazê-lo.
A análise mostrou que o atacante falsificou o Número do Sistema Autônomo (ASN) de modo que a rota anunciada pelo AS do atacante não fosse marcada como inválida. Esta estratégia contribuiu para a propagação de anúncios falsos. O atacante também redirecionou o tráfego através de um servidor upstream que, posteriormente, foi confirmado que se tratava de outra vítima, e não de um cúmplice.
Ocorreram três eventos breves de sequestros:
2025‑07‑09 19h47 (UTC −3) por cerca de 20 minutos
2025‑07‑10 20h34 (UTC −3) por cerca de 15 minutos
2025‑07‑12 10h13 (UTC −3) por cerca de 5 minutos
Nenhuma outra atividade foi registrada. Este ASN tinha um histórico de ataques semelhantes no AFRINIC, ARIN, LACNIC e APNIC, o que corrobora a conclusão de que isso foi deliberado e não acidental.
A equipe também conseguiu reconstruir parte da infraestrutura do atacante. Eles identificaram um servidor de e-mail, um servidor web e outro sistema que escutava em várias portas, possivelmente uma ferramenta de escaneamento ou um honeypot.
A atividade apresentou claros indícios de reconhecimento. Os anúncios surgiram em breves rajadas, em horários aleatórios, e atingiam apenas uma pequena parte da Internet. O atacante também dependia de uma relação upstream forjada para fazer o tráfego fluir. Esses comportamentos coincidiam com outros ataques em que os atacantes testam até onde rotas inválidas ou suspeitas se propagam.
A investigação
O LACNIC encaminhou o caso para o APNIC, que, por sua vez, contatou a APJII/IDNIC, o Registro Nacional da Internet (NIR) da Indonésia, que delegou o ASN. Os resultados foram inesperados: o titular legítimo do ASN não teve qualquer envolvimento. Eles eram um pequeno provedor de serviços da Internet com um upstream local, e também foram vítimas. Um agente malicioso se fez passar por eles usando documentos falsificados e um nome de domínio semelhante ao da organização real.
O atacante convenceu um provedor upstream multinacional a habilitar o trânsito para o ASN sequestrado (que chamaremos de “AS X”). Assim que a sessão BGP esteve ativa, o atacante usou o ASX apenas como trânsito e injetou breves anúncios a partir de vários ASN de origem falsificados por trás dele. Essas rajadas duravam apenas alguns minutos e desapareciam rapidamente, o que dificultava seu rastreamento.
A coordenação entre o LACNIC, APNIC e APJII/IDNIC foi fundamental. Este esforço conjunto confirmou a fraude, identificou a vítima upstream e demonstrou o valor das rotas de escalonamento entre os ‑RIR e os NIR.
Fluxo do ataque
Figura 1: Esquema do processo de roubo de identidade e do processo de provisionamento do upstream. Fonte.
A Figura 1 mostra o titular legítimo do ASN, o ASN sequestrado e o atacante que usa documentos de identidade falsificados para solicitar trânsito de um provedor multinacional. O provedor habilita o BGP e o atacante emite anúncios breves e aleatórios usando o ASN sequestrado.
O atacante não conseguiu burlar o RPKI. Em vez disso, explorou a fraqueza dos processos de verificação de identidade implementados pelo upstream. O provedor multinacional não validou a identidade corporativa ou a propriedade do domínio do cliente antes de habilitar o BGP, o que permitiu que os anúncios não autorizados prosseguissem. Os sequestros resultantes se propagaram amplamente porque a Validação de Origem da Rota (ROV) é implementada de forma inconsistente e muitas redes ainda aceitam rotas NotFound. Além disso, a presença de valores excessivamente permissivos do parâmetro MaxLength das ROA aumentou a escala do incidente ao permitir que prefixos mais específicos parecessem válidos.
Resolução do incidente
APNIC, LACNIC, APJII/IDNIC e o titular legítimo do ASN confirmaram que a solicitação feita ao upstream era fraudulenta. O provedor upstream então encerrou a sessão BGP. Eles também concordaram que o incidente poderia servir de exemplo para a comunidade de segurança do roteamento.
Os palestrantes da sessão também pediram desculpas ao pequeno ISP, que inicialmente havia sido suspeito até que a investigação confirmou que se tratava de mais uma vítima.
Lições sobre a segurança do roteamento
Este incidente oferece diversas lições importantes que destacam oportunidades para fortalecer as práticas atuais de segurança do roteamento.
Disciplina no uso de MaxLength nas ROA
Valores amplos de MaxLength permitem que rotas não intencionais e mais específicas sejam validadas sob ROV. Os operadores devem:
Evitar valores amplos de MaxLength
Adequar o MaxLength às necessidades operacionais reais
Revisar as ROA regularmente
Esta é uma prática recomendada geral e não específica deste incidente.
ASPA e provedores upstream não autorizados
ASPA pode prevenir relações upstream forjadas. Se ASPA tivesse sido implementado, esse ataque teria sido muito mais difícil de executar. A aplicação destas medidas depende da política do operador e do suporte do roteador.
Figura 2: Controles de segurança do roteamento recomendados Fonte.
A Figura 2 destaca duas defesas principais: definir valores precisos de MaxLength para as ROA e usar ASPA para impedir provedores upstream não autorizados.
O provisionamento de provedores upstream é um limite de segurança
O ataque teve como alvo o processo de ativação de clientes usado pelos grandes provedores. Fortalecer esse processo é essencial. Os provedores devem:
Verificar os registros do RIR e do Registro de Roteamento da Internet (IRR).
Ligar para os contatos registrados para confirmar as solicitações.
Rejeitar as cartas de autorização (LOA), que são fáceis de falsificar.
Verificar os metadados do domínio, incluindo a idade, similaridade e padrões de registro.
Adotar a validação ASPA assim que essa funcionalidade estiver disponível nas diferentes plataformas.
A coordenação entre múltiplas partes é importante.
Os incidentes de roteamento ultrapassam fronteiras organizacionais e regionais. A coordenação entre os RIR, NIR, operadores e Grupos de Operadores de Rede (NOG) ajuda a confirmar identidades, identificar padrões e conter incidentes.
Conclusão
A segurança de roteamento abrange mais do que criptografia. As ROA e ASPA reduzem os riscos técnicos, mas não conseguem impedir os ataques que exploram falhas na verificação de identidade. Mais disciplina nas ROA, a adoção de ASPA, uma melhor verificação da integração de usuários e uma coordenação contínua em toda a comunidade da internet reduzirão a probabilidade de ataques semelhantes. A combinação de controles da camada de roteamento com verificações na camada de identidade permitirá a construção de uma Internet mais resiliente.
