Share this story

On Wednesday, large chunks of network traffic belonging to MasterCard, Visa, and more than two dozen other financial services companies were briefly routed through a Russian government-controlled telecom under unexplained circumstances that renew lingering questions about the trust and reliability of some of the most sensitive Internet communications.

Anomalies in the border gateway protocol—which routes large-scale amounts of traffic among Internet backbones, ISPs, and other large networks—are common and usually the result of human error. While it's possible Wednesday's five- to seven-minute hijack of 36 large network blocks may also have been inadvertent, the high concentration of technology and financial services companies affected made the incident "curious" to engineers at network monitoring service BGPmon. What's more, the way some of the affected networks were redirected indicated their underlying prefixes had been manually inserted into BGP tables, most likely by someone at Rostelecom, the Russian government-controlled telecom that improperly announced ownership of the blocks.

"Quite suspicious"

"I would classify this as quite suspicious," Doug Madory, director of Internet analysis at network management firm Dyn, told Ars. "Typically accidental leaks appear more voluminous and indiscriminate. This would appear to be targeted to financial institutions. A typical cause of these errors [is] in some sort of internal traffic engineering, but it would seem strange that someone would limit their traffic engineering to mostly financial networks."

Normally, the network traffic bound for MasterCard, Visa, and the other affected companies passes through services providers that the companies hire and authorize. Using BGP routing tables, the authorized providers "announce" their ownership of the large blocks of IP addresses belonging to the client companies. On Wednesday afternoon at around 3:36pm Pacific time, however, Rostelecom suddenly announced its control of the blocks. As a result, traffic flowing into the affected networks started passing through Rostelecom's routers. The hijacking lasted five to seven minutes. When it was over, normal routing was restored. The event is nicely captured in a graphic here, which uses BGPlay.

The hijacking could have allowed individuals in Russia to intercept or manipulate traffic flowing into the affected address space. Such interception or manipulation would be most easily done to data that wasn't encrypted, but even in cases when it was encrypted, traffic might still be decrypted using attacks with names such as Logjam and DROWN, which work against outdated transport layer security implementations that some organizations still use.

Madory said that even if data couldn't be decrypted, attackers could potentially use the diverted traffic to enumerate what parties were initiating connections to MasterCard and the other affected companies. The attacker could then target those parties, which may have weaker defenses.

The affected company networks also included those belonging to security provider Symantec and technology company EMC. A list of 36 affected network prefixes and registered owners and locations of those prefixes are:

202.138.100.0/24 Reliance Communications Bangalore State of Karnātaka IN

Further Reading

Both Madory and the BGPmon blog post leave open the possibility that the hijacking was inadvertent. Assuming it wasn't an accident, it wouldn't be the first time BGP traffic was intentionally diverted. In 2013, Renesys—which was later acquired by Dyn—reported that huge chunks of Internet traffic belonging to financial institutions, government agencies, and network service providers had been repeatedly redirected to distant locations before finally being passed on to their final destination. Over a nine-month span, the Renesys researchers counted 38 distinct diversions to routers at Belarusian or Icelandic service providers. The hacks affected "major financial institutions, governments, and network service providers" in the US, South Korea, Germany, the Czech Republic, Lithuania, Libya, and Iran.

Such hijacks underscore the implicit trust governments and corporations all over the world place in BGP routing announcements. For years, engineers have proposed a variety of measures to ensure service providers can announce only those networks they're authorized to carry. At the moment, however, there is no authoritative way to do so. Dyn, BGPmon, and similar services do a good job detecting when unauthorized announcements are made, but those detections inevitably come after improper redirections or hijackings have already occurred.

Promoted Comments

I'm surprised there hasn't been some kind of check put in where when a new entity announces ownership, the old owner has to approve it before the change goes into effect. In the meantime, traffic runs over the old BGP routes as if nothing has changed.

What I'm curious about is how can 2 entities can claim to own the same blocks of IPs. Wouldn't that cause some kind of routing conflict?

Regarding the question around routing conflict:Two Network originating the same prefix is not super common but it happens. When a router is presented with 2 similar options it will select the best (typically shortest AS) path. Since different routers will make different decisions, it essentially will result in a way of doing global load balancing. Some DNS operators use exactly this mechanism to achieve global load balancing.

The above is true if the 2 routing options are for the same identical prefix, say 10.10.10.0/23. However if ones of the options is a more specific say 10.10.10.0/24, then the more specific is chosen. You often see this for example with DDOS mitigation setups, where a ddos mitigation supplier announces the more specifics, and traffic is redirected to the mitigation center. The bgpmon blog refers to this as Traffic engineering or redirection. It is also why the new more specific prefixes are kinda scary in this incident. Because more specifics are always preferred you can be sure traffic was redirect to this Russian network.

Regarding prevention and authorization of BGP announcements. The IETF has for years been working on RPKI and ROA's. The goal of that is to create an authoritative distributed database of attestations about who is allowed to originate what networks. Although network operators have started populating these databases, it's still far from complete and accurate (and hence not super reliable). The next step is to actual do something with the data, such as for example ignoring routes with the wrong origin network. The deployment of that is still very low and there are some questions about if or when this will happen. Some will also argue it's not a full proof solutions, making the incentive to deploy a bit less.