On March 13, a proposal for the RIPE anti-abuse working group was submitted, stating that a BGP hijacking event should be treated as a policy violation. In case of acceptance, if you are an ISP attacked with the hijack, you could submit a special request where you might expose such an autonomous system. If there is enough confirming evidence for an expert group, then such a LIR would be considered an adverse party and further punished. There were some arguments against this proposal.
With this article, we want to show an example of the attack where not only the true attacker was under the question, but the whole list of affected prefixes. Moreover, it again raises concerns about the possible motives for the future attack of this type.
BGP hijacks - when an ISP originates an advertisement of address space that does not belong to it;
BGP route leaks - when an ISP advertises prefixes received from one provider or peer to another provider or peer.
This week it has been 11 years since the memorable YouTube BGP incident, provoked by the global propagation of a more specific prefix announce, originated by the Pakistan Telecom, leading to an almost 2 hour in duration traffic disruption in the form of redirecting traffic from legitimate path to the bogus one. We could guess if that event was intentional, and even a correct answer wouldn’t help us completely prevent such incidents from happening today. While you read this, a route leak or a hijack is spreading over the networks. Why? Because BGP is not easy, and configuring a correct and secure setup is even harder (yet).
In these eleven years, BGP hijacking became quite damaging attack vector due to the BGP emplacement in the architecture of modern internet. Thanks to BGP, routers not only acquire peer information, and therefore all the Internet routes - they are able of calculating the best path for traffic to its destination through many intermediate (transit) networks, each representing an individual AS. A single AS is just a group of IPv4 and/or IPv6 networks operating under a single external routing policy.
And thanks to BGP in its current state attackers are capable of conducting massive heists of traffic, efficiently hijacking target network’s prefixes, placing themselves in the middle. And that’s just the beginning - in the era of state-sponsored cyber actors, it is evident that the keystone of Border Gateway Protocol, which is trust, is no longer sufficient enough to prevent malicious outbreaks of routing incidents, deliberate or not, to occur. Since BGP plays such an essential role in the existence of the internet as we know it (it is the only exterior gateway protocol to control traffic flow between different Internet Service Providers all over the world), for a decade we’ve seen attempts to patch things up.
Several times in our posts we discussed consequences of lack of ingress filtering. Such mistake configuration can work fine most of the time, but one day may result in an outage at regional or even global scale. And yesterday, 25.11.2018, it happened again, this time in Russia.
Three Mistakes in a Boat (To Say Nothing of the Outage)
Yesterday, on 12.11.2018 a BGP configuration mistake happened at Mainone Cable Company (AS37282), a Nigerian ISP. It mainly hit two content providers: Google (AS15169, AS36384, AS36492, AS43515) and Cloudflare (AS13335). Leaked routes were accepted by its direct upstream, China Telecom (AS4809), further advertised in Russia to TTK (AS20485) and finally learned by NTT (AS2914) in Europe. After reaching the Tier-1 providers level leaked prefixes propagated globally, redirecting traffic to unusual Europe-Russia-China-Nigeria route.
For the last 30 years basic idea behind the Internet’ design hasn’t changed - it connects people and services with each other. However, some authorities may have a different angle on what services their citizens should be able to connect to. A regulator might require ISPs to block off selected content or IP-address space for the end-users. How is that implemented? There are many options, but the most popular one is with the help of static routes, that may be propagated locally in BGP. Mistakes in this ‘local propagation’ have happened before: most notable was the YouTube hijack back in 2008, but less famous events were continually happening all over the decade. Today we observed another one, created by Iranian ISP that affected Telegram messenger.
Dear colleagues, we are glad to inform you that our team has finished integration with IRR data sources and ROA records. It should significantly increase the quality of hijacks detection, plus improve transparency of what is happening to route objects in different registries.
Recently, several severe routing incidents were spreading globally: hijack of the 5% of an entire IPv4 address space from Brazil, route leak between Russia and Asia through Kyrgyzstan, and at last, previous Friday there was an event that could lead to an outage of a significant part of all the BGP ecosystem. Fortunately, it didn’t happen.
A few days ago several cybersecurity resources reported details of an entirely malicious traffic redirection that combined DNS, and BGP hijacking. The primary goal of this attack was to steal money from different cryptocurrency wallets and services. Moreover, it was successful, since Amazon did not detect it in time. Today, on April 26, another significant incident happened that seems to be also unnoticed by the majority of players.
The situation we observed last week was both peculiar and strange when panic for Cisco Smart Install Protocol remote code execution vulnerability (cisco-sa-20160323-smi) started circling. There was confirmed botnet activity that was wiping configuration files exploiting this vulnerability and leaving a message “Don’t mess with our elections.” Moreover, there were rumors that significant amount of ISPs and even Internet segments get down due to this malicious actions.