Summarizer

BGP Technical Analysis

AS prepending as traffic engineering, route leak detection, RPKI filtering absence, CANTV routing policies, Cloudflare Radar data interpretation, distinguishing misconfigurations from intentional attacks

← Back to There were BGP anomalies during the Venezuela blackout

While some observers suggest that CANTV’s BGP route leak was a targeted intelligence-gathering effort or a pre-kinetic mapping of critical infrastructure, many experts argue that the excessive AS path prepending points instead to routine traffic engineering or a common configuration error. The absence of RPKI filtering at major transit providers like Telecom Italia Sparkle complicates the situation, as it leaves the network vulnerable to the propagation of such anomalies whether they are accidental "stuck" routes or malicious hijacks. Although the timing relative to a major power outage raises suspicions of cyberwarfare, skeptics note that Cloudflare Radar data shows such routing fluctuations are frequent occurrences that often result from secondary effects like hardware failures or power disruptions. Ultimately, the discourse highlights the inherent insecurity of BGP, where the line between a routine "fat-finger" mistake and a sophisticated state-sponsored operation remains difficult to distinguish.

21 comments tagged with this topic

View on HN · Topics
> When BGP traffic is being sent from point A to point B, it can be rerouted through a point C. If you control point C, even for a few hours, you can theoretically collect vast amounts of intelligence that would be very useful for government entities. The CANTV AS8048 being prepended to the AS path 10 times means there the traffic would not prioritize this route through AS8048, perhaps that was the goal? AS prepending is a relatively common method of traffic engineering to reduce traffic from a peer/provider. Looking at CANTV's (AS8048) announcements from outside that period shows they do this a lot. Since this was detected as a BGP route leak, it looks like CANTV (AS8048) propagated routes from Telecom Italia Sparkle (AS6762) to GlobeNet Cabos Sumarinos Columbia (AS52320). This could have simply been a misconfiguration. Nothing nefarious immediately jumps out to me here. I don't see any obvious attempts to hijack routes to Dayco Telecom (AS21980), which was the actual destination. The prepending would have made traffic less likely to transit over CANTV assuming there was any other route available. The prepending done by CANTV does make it slightly easier to hijack traffic destined to it (though not really to Dayco), but that just appears to be something they just normally do. This could be CANTV trying to force some users of GlobeNet to transit over them to Dayco I suppose, but leaving the prepending in would be an odd way of going about it. I suppose if you absolutely knew you were the shortest path length, there's no reason to remove the prepending, but a misconfiguration is usually the cause of these things.
View on HN · Topics
CANTV (AS8048) is a correct upstream transit provider for Dayco (AS21980) as seen in both https://radar.cloudflare.com/routing/as21980#connectivity and https://bgp.tools/as/21980#upstreams What most likely happened, instead of a purposeful attempt to leak routes and MITM traffic, is CANTV had too loose of a routing export policy facing their upstream AS52320 neighbor, and accidentally redistributed the Dayco prefixes that they learned indirectly from Sparkle (AS6762) when the direct Dayco routes became unavailable to them. This is a pretty common mistake and would explain the leak events that were written about here.
View on HN · Topics
This doesn't look like anything malicious, 8048 is just prepending these announcements to 52320.. If anything, it looks like 269832(MDS) had a couple hits to their tier 1 peers which caused these prepended announcements to become more visible to collectors.
View on HN · Topics
There were reports they had considered Christmas Day and New Year's Day. I wonder if it was far enough along that you could see similar BGP anomalies around those times.
View on HN · Topics
Not from the cloudflare dashboard, you can zoom out. The night of the attack doesnt even really stand out as abnormal when zooming out that far.
View on HN · Topics
From bgp hijacking? Almost certainly not. It would probably rule out the type of decapitation strike the US did, but bgp hijacking is way way below on the escalation ladder.
View on HN · Topics
What would be the result of this? I think it would route data through Sparkle as a way of potentially spying on internet traffic without having compromised the network equipment within Venezuela, but I'm not familiar enough with network architecture to really understand what happened.
View on HN · Topics
The effect of this would be traffic from GlobeNet destined for Dayco would transit over CANTV's network for a period. I'm not sure why the author singled out Telecom Italia Sparkle.
View on HN · Topics
For a length-15 ASpath to show up on the internet, a whole bunch of better routes need to disappear first, which seems to have happened here. But that disappearance is very likely unrelated to CANTV. Furthermore, BGP routes can get "stuck", if some device doesn't handle a withdrawal correctly… this can lead to odd routes like the ones seen here. Especially combined with the long path length and disappearance of better routes.
View on HN · Topics
BGP is so unsecure that almost anyone can create chaos.
View on HN · Topics
Even by accident!
View on HN · Topics
or even by normal load from someone deciding to split a /8 prefix into /24's
View on HN · Topics
Most BGP peers have router filters in place. It's not 1996 anymore. I remember the days of logging into a Cisco connected to a Sprint T1 and seeing a coworker had fat fingered a spammer's route, sending it to null0. Oops. How did that happen?
View on HN · Topics
Alternative theory: Part of the operation caused power outages or disrupted some connections, the BGP anomalies were a result of that. The data would make that more likely, because deliberately adding a longer route doesn't achieve much. It's not usually going to get any traffic.
View on HN · Topics
The BGP anomalies were 24-hours~ before the power outage, so I'm not sure I follow what you're arguing.
View on HN · Topics
What I mean is that cause and effect here could be different then the author thinks. We see some route changes, but those changes make no sense on their own since they wouldn't capture any traffic. That makes it more probable that BGP was not the attack, but that some other action caused this BGP anomalie as a side effect. For example, maybe some misconfiguration caused these routes to be published because another route was lost. Which could very well be the actual cyber attack, or the effect of jamming, or breaking some undersea cable, or turning off the power to some place.
View on HN · Topics
I think what the other commenter is saying is that the BGP changes happened 12 hours before any of the power loss/bomb drop, so that eliminates your primary cause.
View on HN · Topics
There are BGP anomalies every day.
View on HN · Topics
Solid OSINT methodology here. The 10x AS path prepending is the most interesting detail to me b/c typically you'd see prepending used to de-prioritize a route, which raises the question: was this about making traffic avoid CANTV, or was it a side effect of something else? A few thoughts: - The affected prefixes (200.74.224.0/20 block → Dayco Telecom) hosting banks and ISPs feels significant. If you're doing pre-kinetic intelligence gathering, knowing the exact network topology and traffic patterns of critical infrastructure would be valuable. Even a few hours of passive collection through a controlled transit point could map out dependencies you'd want to understand before cutting power. - What's also notable is the transit path through Sparkle, which the author points out doesn't implement RPKI filtering. That's not an accident if you're planning something (you'd specifically choose providers with weaker validation). - The article stops short of drawing conclusions, which is the right call. BGP anomalies are common enough that correlation ≠ causation. But the timing and the specific infrastructure affected make this worth deeper analysis. Would love to see someone with access to more complete BGP table dumps do a before/after comparison of routing stability for Venezuelan prefixes in that window.
View on HN · Topics
Symbolic link to the Cloudflare RPKI status for CANTV. [1]: https://radar.cloudflare.com/routing/as8048ref=loworbitsecur...
View on HN · Topics
I never understood the (now decade old) argument of 'parts of the Internet cannot be shut down' Clearly and empirically, BGP can shut off parts of the Internet, just as Trump wanted to do in 2015. https://finance.yahoo.com/news/dear-donald-trump-no-you-1322...