Finding the root cause of this BGP MITM event.
With the above finger print in mind and numerous alerts helping us focusing in on the rather large data set, we started to dig deeper and tried to determine what exactly had happened here.
One of the clues we have when troubleshooting BGP is the ASpath. By looking at the ASpath we can say who originated the prefixes, which network provides transit to the originator and how does the path to the eventual receiver of the BGP update look like.
Let’s take a look at one of the affected prefixes and an ASpath for this prefix
271 6939 35625 6453 3215
A quick look at this path might not show anything strange, however when looking a bit more closely at this ASpath there are a few things that don’t add up.
In this case we know that originator of the prefix, AS3215 France Telecom, does not have a direct peering/transit relationship with Tata (AS6453). This relationship does however show up in the ASpath. The other thing to note is that the ASpath shows that AS35625 (Avenir Telematique) is receiving the route from Tata (6453)(originated by France Telecom, 3215) and then announcing it to HE AS6939 (a peer of 35625) which then announces it to its customers. This means that 35625 (Avenir Telematique) is providing transit for 6453 3215 towards 6939 (Hurricane Electric). Given the size of both Tata (AS6453) and Hurricane Electric (AS6939), AS35625 should never be in the middle of these two.
So to summarize, the reason this update was marked as suspicious and eventually as a possible man in the middle attack is because it was a new more specific, the ASpath is suspicious as it contains non-existing relationships and one AS is leaking between two large providers. Our software has a few other checks and balances in place to prevent false alerts, but this pretty much sums up why it was flagged as suspicious.
Putting the pieces together
When looking closer at the ASpaths for all the events that were flagged as possible MITM we found that all ASpaths had one Autonomous System in common, AS35625 (Avenir Telematique), the same AS that appeared to have leaked the announcement to HE. At that point we focused our attention on this Autonomous System and we presumed that AS35625 was the one introducing these new announcements including the fake ASpaths.
After contacting the team responsible for AS35625 our suspicions were confirmed. As it turned out AS35625 has a “route optimizer” appliance that changes and introduces new BGP announcements, by breaking up prefixes in more specifics and altering the ASpath. All this is done in order to improve reachability and latency. Obviously these announcements are supposed to stay within the boundaries of the autonomous system, but in this case they were leaked to many of its peers.
If we look at the impact and affected networks we see that the number of prefixes that match the fingerprint was 418 unique prefixes of 133 unique Autonomous systems, including Facebook, Microsoft, Cogent, Bell Canada, Verizon, Level3, Shaw, Tata, Comcast, Yahoo, Verisign and many more, see
full list here. The total event lasted for about 30 minutes, although it should be noted that the impact varied per prefix and peering partner.
The new more specific prefixes were announced to numerous peers of AS35625, we detected it via approximately 50 direct peers of AS35625, most notably via AS6327 (Shaw Cablesystems) and AS6939, Hurricane Electric.
As these are more specific prefixes it’s fair to assume that networks that received the BGP update for the affected prefixes, including the large customer base of both Hurricane Electric and Shaw would have rerouted traffic for some of the 400 prefixes towards AS35625 in France for several minutes.
In this case the only thing that limited the impact and prevented more prefixes to be affected were “max prefix filters” on the peering connections. In the case of Hurricane Electric the impact was limited to ~80 prefixes.
This event demonstrates how easy it is to accidentally steal parts of the Internet, and it make you wonder what could be done if an attacker would carefully plan and execute such an attack (would it be detected?).
It’s obvious that once an attacker has access to a Certificate Authority and can issue seemingly valid SSL certificates at will, there are numerous options for redirecting traffic. The event described in this blog show how BGP can help attackers redirect traffic for any network in the world, while staying relatively stealthy.
All this demonstrates the fragility of the current routing, CA and DNS system. The good news is that new technologies are currently underway to make the Internet more secure, DNSSEC, DANE and RPKI & BGPSEC are all technologies to make these the Internet infrastructure more secure, the bad news is that most of these technologies lack significant deployment or are still in the standardization phase.