A huge BGP hijack by Russian state telecommunications provider Rostelecom diverted the traffic from more than 200 networks - including Google, Amazon, Facebook and Cloudflare - to Russian servers on April 1. It may have been accidental, it may not.
Internet traffic routes are managed by the Border Gateway Protocol (BGP), which controls the way in which internet traffic moves from one autonomous system (AS) network to the next on its way to its destination. Each AS has its own number (ASN), and as of February 2020, there were more than 94,000 allocated. With this number and complexity, there are many possible routes from source to destination -- BGP determines the best route at any given time.
BGP-enabled devices advertise, or share, information on the routes they can offer to the BGP devices on neighboring networks. These networks then share that information to their own neighboring networks. Changes to 'best routes' thus rapidly get promulgated throughout the internet. But BGP was first created in 1989 and in use 1994 -- at a time when the internet was still largely a club of friends who did not require security. It is based on trust between devices, and when one network advertises a new 'best route', it is implicitly accepted by neighboring networks and re-advertised.
A BGP-based hijack of internet traffic can be as simple as that -- the hijacking BGP device advertises to its neighbors that they should send certain traffic to their own servers. Here the traffic could be stored or dropped. Most of the hijacks are thought to be accidental. Simply mistyping a number that is advertised to peers would be believed and incorrect routing information spread throughout the internet. The problem is that it is almost impossible to distinguish between an accidental mistyping and a planned malicious mistype. Given current geo-political tensions, any BGP hijack emanating from Russia or China will inevitably raise eyebrows -- and both nations are serial hijackers. In 2017, Rostelecom curiously managed to accidentally hijack only major financial entities.
In this case, there was a further co-incidental event involving the Internet Routing Registry (IRR) that could raise eyebrows over last week's Rostelecom hijack. The IRR is a globally distributed routing information database where network operators can publish their routing policies and routing announcements. In theory, new advertisements from one peer could be checked against IRR records to see if they might be incorrect. However, the IRR operated by RIPE accidentally deleted 2,669 route origin authorization (ROA) records on the same day as the Rostelecom hijack.
There is no suggestion of anything malicious in the RIPE incident. RIPE's routing security program manager Nathalie Trenaman explained on April 3, "This was caused by our registry software classifying these assignments as not-certifiable. From our logs, we can confirm that these blocks never left the RIPE Registry, and within 15 minutes the registry was back to normal. However, by that time the ROAs had already been deleted and could not be restored without intervention from our engineers." That restoration wasn't complete until 13:15 on April 2.
It would be a reasonable assumption that Rostelecom was aware of the RIPE incident -- which would inevitably make a hijack easier and more extensive. So, put bluntly, April 1 was the perfect opportunity for a BGP hijack that could be claimed as an accident with almost absolute plausible deniability for anything malicious.
Over the years, there have been numerous attempts to solve the accidental hijack. One that is currently gaining attraction, supported by The Internet Society, is the Mutually Agreed Norms for Routing Security (MANRS) program. If MANRS is widely -- ideally, universally -- adopted by network operators, its series of actions or commitments would make accidental hijacks a thing of the past. It would also, Andrei Robachevsky, senior technology program manager at the Internet Society, told SecurityWeek, differentiate between accidental and malicious hijacks. With no accidents, anything left would be malicious.
On this latest Rostelecom incident, he added, "One point we can clearly make is that MANRS actions (and specifically Action: Filtering) could have certainly prevented this incident from happening, or at least spreading widely. Another point, and this is referring to the recently launched MANRS program for CDNs and Cloud providers, is that for them, encouraging MANRS adoption by their peers has a clear benefit - fewer incidents of this sort negatively impacting their operation. This is covered by Action #5: 'Encourage MANRS adoption'."
While MANRS might have prevented this hijack if it was accidental, it isn't yet sufficiently adopted to give any clue on whether it might have been a malicious hijack. There is little doubt that mass misdirected traffic could be valuable to an adversarial nation. The traffic content would have been encrypted with https, but the metadata would be immediately available. Metadata from Facebook, for example could be useful in planning attempts to use the social network to interfere with U.S. elections, now just 9 months away.
But it is also worth noting that encrypted traffic can be slowly brute forced, while the arrival of quantum computing in the future will make cracking RSA simple and quick on stored data.
Despite the obvious benefits of such a massive hijack, it should be stressed that current indications suggest that the Rostelecom hijack was an accident. According to Rostelecom itself, the incident occurred when an internal traffic optimization system exposed incorrect routes to the public internet rather than simply within its own private network. Once this happened, BGP ensured the errors spread round the internet within minutes.
The 'accident' theory gains further weight from an analysis of the incident by Job Snijders, an IP development engineer at NTT Communications. "Were these prefixes just unlucky because some BGP optimizer algorithm had chosen them for the purpose of traffic engineering? Was this the result of sophisticated planning?"
He compared the data lost by RIPE to the most affected networks, and notes that the top ten most impacted networks are U.S.-based under ARIN rather than RIPE. Furthermore, he could find no correlation between RIPE's deleted records and the mis-directed network traffic. "This leads me to believe," he concluded, "this was not a deliberate plan dependent on a process failure inside RIPE NCC, the incident's BGP data just doesn't seem to show the incident maximally capitalized on the [records] outage."
"Most of the impacted prefixes were registered in ARIN, for example Amazon, Akamai, Cloudflare etcetera," Aftab Siddiqui, senior manager internet technology at the Internet Society, told SecurityWeek. "Job Snijder did the analysis on the correlation between RIPE RPKI incident and this hijack and only found a very small number of prefixes impacted by both (12). It is safe to say it was just a coincidence that both happened nearly at the same time."
But even if the Rostelecom incident was an accident, it was an accident that should not have happened -- and similar will undoubtedly happen again without a solution like MANRS.
Related: BGP Hijacking Attacks Target US Payment Processors
Related: Internet Society Calls on IXPs to Help Solve Internet Routing Problems
Related: Free MANRS Tool Helps Improve Routing Security
Related: Embrace RPKI to Secure BGP Routing, Cloudflare Says
Tags:
