- Ao mesmo tempo que a crise de apagão na Venezuela, foram observadas anomalias de roteamento BGP centradas na CANTV (AS8048)
- Segundo dados do Cloudflare Radar, em 2 de janeiro, 8 prefixos IP que incluíam rotas da CANTV foram roteados por caminhos AS anormais
- Esses caminhos incluíam a Sparkle (Itália) e a GlobeNet (Colômbia), e a Sparkle é classificada como uma operadora “insegura” por não aplicar filtragem RPKI
- A análise com
bgpdump mostrou que o número AS da CANTV (8048) foi repetido 10 vezes no caminho AS, em um formato incompatível com as regras normais de seleção de rotas, e confirmou-se que essa faixa de IP pertencia à Dayco Telecom, em Caracas
- Como esse vazamento de rota BGP, o apagão, a explosão e o momento da entrada das forças armadas dos EUA ocorreram em momentos próximos, fica claro que houve atividade anormal em nível de rede
Apagão na Venezuela e anomalias de BGP
- Durante a crise de apagão na Venezuela, ocorreu um vazamento de rota BGP (route leak) centrado na CANTV (AS8048)
- Nos dados do Cloudflare Radar, 8 prefixos IP foram roteados por caminhos anormais passando pela CANTV
- Os caminhos incluíam a Sparkle (Itália) e a GlobeNet (Colômbia)
- O Cloudflare Radar registrou em 2 de janeiro um aumento acentuado de anúncios BGP e uma redução no espaço de endereços IP públicos
- A Sparkle é classificada como operadora “insegura” no isbgpsafeyet.com, e foi confirmada a ausência de filtragem RPKI
Análise dos dados de BGP
- Usando dados públicos do
ris.ripe.net e a ferramenta bgpdump, foram extraídos prefixos ausentes que o Cloudflare não exibiu
- O resultado da análise mostrou que a CANTV (8048) aparecia repetida 10 vezes no caminho AS
- Como o BGP prefere caminhos mais curtos, essa repetição indica uma composição de rota anormal
- Os 8 prefixos estavam todos contidos no bloco
200.74.224.0/20
- A consulta WHOIS confirmou que pertenciam à Dayco Telecom (sediada em Caracas)
- A consulta de DNS reverso mostrou que essa faixa de IP incluía infraestrutura crítica, como bancos, provedores de internet e servidores de e-mail
Linha do tempo do incidente
- 2 de janeiro, 15:40 UTC: vazamento de rota BGP detectado (Cloudflare Radar)
- 3 de janeiro, por volta de 06:00: explosão relatada em Caracas (NPR)
- 3 de janeiro, 06:00: forças armadas dos EUA chegam à residência de Maduro (NBC News)
- 3 de janeiro, 08:29: Maduro embarca no USS Iwo Jima (CNN)
- Durante esse período, há indícios de que o tráfego BGP foi desviado por um terceiro ponto de trânsito, e o controle desse caminho poderia permitir coleta de informações
Análise e observações
- O fato de o AS8048 da CANTV ter sido inserido 10 vezes no caminho provoca o efeito de reduzir a prioridade do tráfego
- Não está claro se foi intencional, mas é evidente que houve manipulação anormal de rota (shenanigans)
- Mesmo apenas com dados públicos, vale a pena aprofundar a análise das atividades anormais de rede daquele momento
- O texto evita interpretações políticas e trata apenas das anomalias técnicas sob uma perspectiva de segurança ofensiva
Outros links relacionados a segurança
- MCP Security: demonstra que servidores MCP maliciosos podem roubar prompts de IA e variáveis de ambiente
- The Year in LLMs (2025): resumo de modelos de raciocínio, agentes de programação, modelos open-weight chineses, adoção de MCP etc.
- Linux is Good Now: discussão sobre 2026 ser o ano do desktop Linux
- No strcpy Either: o projeto curl removeu
strcpy() e introduziu wrappers com tamanho de buffer explícito
- Kubernetes Networking Best Practices: escolha de CNI, políticas de rede, service mesh e guia de troubleshooting
1 comentários
Opiniões do Hacker News
É possível fazer manipulação de roteamento no BGP para que o tráfego vá de A para B passando por C
Se você controlar o ponto C, pode coletar informações, mas no caso da CANTV (AS8048) desta vez parece ter sido apenas AS path prepending
Isso é uma forma comum de engenharia de tráfego para reduzir tráfego, e já foi um padrão usado com frequência no passado
Desta vez, parece que a rota da Telecom Italia Sparkle (AS6762) foi propagada para a GlobeNet Cabos Sumarinos Columbia (AS52320), e há grande chance de ter sido um simples erro de configuração
Não há sinais de sequestro de rota para a Dayco Telecom (AS21980); pelo contrário, o prepending reduziu a chance de passar pela CANTV
O ponto interessante no artigo foi que 7% das consultas DNS para 1.1.1.1 eram do tipo HTTPS
Isso está relacionado à implementação de ECH (Encrypted Client Hello) no TLS 1.3, em que o DNS hospeda a chave pública do servidor para criptografar completamente o nome do servidor em requisições HTTPS
Como os principais servidores web, como o Nginx, ainda não oferecem suporte a isso, é bem provável que esses 7% sejam majoritariamente tráfego da própria Cloudflare
Os dados relacionados podem ser vistos no Cloudflare Radar
Se a conexão estiver lenta, fazem fallback automático para HTTP1/2
Exemplo: https://dns.cloudflare.com/dns-query
Ainda não testei isso diretamente
Acho que países com armas nucleares ficariam de fora de operações de sequestro desse tipo
Incidentes assim provavelmente só aumentam a pressão pela proliferação nuclear
Antes eu achava exagerado, mas agora parece que estamos fazendo papel de palhaço
É de uma ordem completamente diferente de uma ação militar como uma operação de decapitação dos EUA
Meios de entrega e capacidade de defesa são importantes, e é improvável que um incidente como o sequestro de um líder resulte em retaliação nuclear
Tentar usar armas nucleares já é, por si só, um cálculo arriscado
Por exemplo, os ataques com mísseis do Irã já partem do pressuposto de que a maioria será interceptada
Mesmo que a Venezuela tivesse armas nucleares, isso ainda teria acontecido
Neste caso, parece mais um evento não malicioso em que a CANTV (AS8048) enviou um anúncio com prepending para a 52320
Na verdade, parece que problemas nas conexões com peers upstream da MDS (269832) fizeram esse caminho ficar mais visível
Esse caso reforça a sensação de que é impossível evitar totalmente a dependência de tecnologia dos EUA
A frase “mergulhe ainda mais fundo na tecnologia americana” soa ironicamente
Como a Venezuela está sob sanções, é até mais provável que use mais tecnologia chinesa
Ainda assim, concordo que depender da tecnologia de um rival geopolítico é arriscado
Quase não existe mais espaço para aumentar ainda mais essa dependência
Se um país não tiver capacidade própria, no fim vai precisar usar tecnologia de outros
Excluir os EUA só rende uma ‘infraestrutura sem EUA’, e o valor econômico acaba sendo parecido
Um país como a Venezuela só acabaria trocando isso por dependência tecnológica de outra grande potência
A geopolítica da tecnologia, no fim, é a realidade de que “quanto mais pão você tem, menos merda dos outros precisa comer”
Fiquei curioso se a economia do OSRS (Old School RuneScape) foi afetada por esse ataque
Acho que a internet não deve ter caído completamente
Fiquei curioso se houve anomalias de BGP parecidas no Natal ou no Ano-Novo
Para um AS path de comprimento 15 aparecer na internet, todas as rotas melhores precisam ter desaparecido
Parece que isso também aconteceu desta vez, e não parece ter relação com a CANTV
Às vezes rotas BGP ficam ‘presas’ por falhas no processamento de retirada, e nessas situações caminhos longos podem aparecer
A conclusão não é totalmente clara, mas esta investigação e análise foi muito interessante
Parece possível que alguém ainda encontre mais elos de ligação
Acho que, como resultado desse incidente, o tráfego pode ter passado pela Sparkle e permitido interceptação
Mas não conheço bem a arquitetura da rede para afirmar isso com precisão
Em uma situação de crise, isso pode funcionar como bloqueio de meios alternativos importantes de comunicação
Não está claro por que a Telecom Italia Sparkle foi mencionada de forma tão específica