À medida que as notícias internacionais se intensificam em torno da captura e detenção do líder venezuelano Nicolás Maduro pelos Estados Unidos, um detalhe técnico chamou a atenção da comunidade de cibersegurança: uma anomalia grave de routing na Internet venezuelana. Uma newsletter especializada em segurança digital analisou dados do Cloudflare Radar e identificou um route leak significativo ocorrido a 2 de janeiro.

A análise aprofundada dos dados revela um padrão preocupante. Desde o início de dezembro, foram registados onze eventos distintos de route leak, afetando múltiplos prefixos IP, todos com origem no mesmo sistema autónomo: o AS8048. Embora seja impossível determinar com absoluta certeza o que aconteceu exatamente no dia do incidente, a repetição deste comportamento aponta para um problema estrutural. Tudo indica que a rede da CANTV (AS8048), o principal fornecedor estatal de serviços de Internet na Venezuela, apresenta políticas de exportação e importação BGP mal configuradas. Assim, as anomalias observadas poderão estar mais relacionadas com práticas técnicas deficientes do que com ações deliberadamente maliciosas.

Neste artigo, é feita uma análise detalhada do Border Gateway Protocol (BGP), do conceito de route leaks e do incidente específico detetado na Venezuela, explorando também as possíveis causas técnicas por detrás deste fenómeno.

O que é um route leak em BGP?

Um route leak em BGP pode ser comparado a sair na saída errada de uma autoestrada. Apesar de ainda ser possível chegar ao destino, o percurso torna-se mais longo, mais lento e sujeito a atrasos inesperados. Tecnicamente, os route leaks foram formalmente definidos no RFC7908 como “a propagação de anúncios de routing para além do seu âmbito pretendido”.

Esse “âmbito pretendido” baseia-se nas relações comerciais entre redes, conhecidas como Sistemas Autónomos (AS). Existem dois tipos principais de relações:

Relação cliente-fornecedor: o cliente paga ao fornecedor para ter acesso à Internet global. O fornecedor anuncia todas as rotas ao cliente, enquanto o cliente apenas anuncia as suas próprias rotas e as dos seus clientes diretos.

Relação peer-to-peer: duas redes concordam em trocar tráfego entre si e com os respetivos clientes, sem pagamentos envolvidos.

Estas regras garantem um encaminhamento previsível e eficiente do tráfego, respeitando o chamado princípio de “valley-free routing”, onde o tráfego sobe de clientes para fornecedores, pode atravessar um ponto de peering, e depois desce novamente até aos clientes finais.

Um route leak ocorre quando este princípio é violado. Por exemplo, quando um AS recebe rotas de um fornecedor ou peer e as redistribui indevidamente para outro fornecedor ou peer. Um caso clássico é o chamado Type 1 Hairpin Route Leak, em que um cliente acaba por intermediar tráfego entre dois dos seus próprios fornecedores, algo que nunca deveria acontecer e que pode saturar rapidamente a sua infraestrutura.

O papel do AS8048 (CANTV) na anomalia

Após compreender o conceito de route leak, torna-se mais claro o que aconteceu no caso venezuelano. A newsletter destacou várias anomalias detetadas pelo Cloudflare Radar associadas ao AS8048. Os dados mostram que a CANTV recebeu rotas de um dos seus fornecedores, o AS6762 (Sparkle, uma empresa italiana de telecomunicações), e redistribuiu-as indevidamente para outro fornecedor, o AS52320 (V.tal GlobeNet, da Colômbia). Tecnicamente, isto configura um route leak inequívoco.

A publicação original sugere possíveis “manobras de BGP” e levanta a hipótese de estas falhas poderem ser exploradas para recolha de informação sensível, potencialmente útil para entidades governamentais. No entanto, uma análise mais fria dos dados aponta para uma explicação bem menos conspirativa.

Os prefixos afetados pertencem todos ao mesmo bloco, 200.74.224.0/20, e são originados pelo AS21980 (Dayco Telecom), uma empresa venezuelana. Um detalhe crucial muda completamente a interpretação do incidente: o AS8048 é fornecedor direto do AS21980. Esta relação cliente-fornecedor é confirmada por várias fontes, incluindo o Cloudflare Radar, bgp.tools e ferramentas de análise de relações BGP como o monocle do BGPKIT, que atribuem elevada confiança a esta hierarquia.

Outro elemento relevante é o uso intensivo de AS prepending. Muitas das rotas vazadas continham o AS8048 repetido múltiplas vezes no caminho BGP, tornando-as menos atrativas para outros operadores. Se o objetivo fosse interceptar tráfego de forma maliciosa (ataque man-in-the-middle), faria mais sentido anunciar caminhos mais curtos e atrativos, não o contrário. Além disso, sendo já fornecedor do AS21980, a CANTV teria pouco a ganhar ao tentar intercetar tráfego que já passa pela sua rede.

Os leaks ocorreram em anúncios separados, com cerca de uma hora de intervalo, entre as 15:30 e as 17:45 UTC do dia 2 de janeiro de 2026. Este padrão é consistente com problemas operacionais ou erros de convergência de routing, e não com uma ação coordenada. Importa ainda salientar que estes eventos começaram mais de doze horas antes dos ataques militares dos EUA na Venezuela, afastando uma ligação direta entre os dois acontecimentos.

Um problema recorrente, não um caso isolado

A análise histórica reforça esta conclusão. Nos dois meses anteriores, o AS8048 esteve envolvido em múltiplos incidents semelhantes. Só desde o início de dezembro, foram registados onze route leaks do mesmo tipo. Isto demonstra que não se trata de um evento excecional, mas sim de um problema recorrente na configuração das políticas BGP da CANTV.

Uma explicação plausível é a existência de políticas de exportação demasiado permissivas, possivelmente baseadas apenas em listas de prefixos geradas por IRR, sem validação adicional através de comunidades BGP específicas de clientes. Nestes cenários, quando uma rota direta do cliente falha temporariamente, caminhos indiretos podem ser indevidamente anunciados a montante, originando route leaks.

Validação de origem vs validação de caminho

A newsletter original também destacou o facto de a Sparkle (AS6762) não implementar totalmente RPKI Route Origin Validation (ROV), sendo classificada como “insegura” em plataformas de monitorização. No entanto, esta observação, embora relevante noutros contextos, não teria evitado o incidente em questão.

É fundamental distinguir entre dois tipos de anomalias BGP: erros de origem (misoriginations ou hijacks) e anomalias de caminho. O RPKI ROV é eficaz para o primeiro caso, garantindo que apenas o legítimo detentor de um prefixo o pode anunciar. Aqui, o prefixo foi corretamente originado pelo AS21980. O problema esteve exclusivamente no caminho anunciado, algo que o ROV não consegue mitigar.

Para este tipo de situação, é necessária validação baseada no caminho BGP. É precisamente aqui que entra o ASPA (Autonomous System Provider Authorization), um novo standard em desenvolvimento no IETF. O ASPA permitirá que cada AS declare explicitamente quais são os seus fornecedores autorizados. Com esta informação, outros operadores poderão invalidar automaticamente anúncios que violem essas relações.

Num exemplo prático, um operador Tier-1 como o AS6762 poderia declarar, via ASPA, que não possui fornecedores a montante. Assim, se um cliente anunciar uma rota que inclua esse AS como upstream, o anúncio seria rejeitado automaticamente.

Rumo a um BGP mais seguro

A análise do route leak venezuelano mostra como o BGP, historicamente baseado na confiança e em relações comerciais implícitas, continua vulnerável a erros humanos e falhas de configuração. Embora existam cenários em que estas falhas podem ser exploradas de forma maliciosa, os dados disponíveis apontam, neste caso, para um erro operacional recorrente.

A adoção generalizada de tecnologias como o ASPA, complementadas por mecanismos como Peerlock, Peerlock-lite e o RFC9234 com o atributo Only-To-Customer (OTC), representa um passo decisivo para um ecossistema de routing mais seguro. Estas medidas permitem alinhar a lógica técnica do BGP com a realidade das relações comerciais entre operadores, reduzindo drasticamente a probabilidade de incidentes como o ocorrido na Venezuela.

A segurança do BGP é uma responsabilidade coletiva. Tal como aconteceu com a implementação progressiva do RPKI para validação de origem, o sucesso do ASPA e das novas extensões dependerá da colaboração entre operadores, fabricantes e entidades reguladoras. Só assim será possível evitar que anomalias técnicas se transformem em crises geopolíticas ou em falhas graves da infraestrutura global da Internet.

Hashtags: #BGP #Cibersegurança #InternetGlobal #Venezuela #Routing #Cloudflare #InfraestruturaDigital #SegurançaOnline