The Border Gateway Protocol (BGP) is considered by most to be the backbone of the Internet. The protocol has been around for about twenty-five years, a presence that preceded the need for dedicated cybersecurity teams. The connections made by BGP routers are inherently trusted, but that trust comes with many problems including BGP hijacking and leaks. But what exactly is BGP, are hijacking and leaks such a big deal? If so, can we fix it?
The Internet is a complex mesh of interconnected systems that we use to communicate regularly from email to social media and file sharing services. These services are hosted by various Internet Service Providers (ISPs) that are responsible for identifying, creating and maintaining routes across the Internet for their various customers; whether residential, corporations, educational institutions or governments. The networks that ISPs host are divided into groups called Autonomous Systems (AS). Autonomous Systems (AS) are groups of routers that are under the control of a single administration; typically, an ISP, and are identified by an Autonomous System Number (ASN).
Autonomous systems may utilize various routing protocol options internally, including OSPF (Open Shortest Path First), EIGRP (Enhanced Interior Gateway Routing Protocol) and IBGP (Internal Border Gateway Routing Protocol). For external routes, an organization’s ISP would choose to use BGP to determine routes between other ISPs or organizations. Border Gateway Protocol (BGP) is a connection oriented routing protocol. It makes routing decisions by exchanging information about route paths between external BGP systems. The decisions for these routes are based on a number of predefined rules including agreements between ISPs to allow connections or simply the distance of the route, which is usually measured in hops.
BGP Weaknesses
BGP is an inherently weak protocol. There were no security controls built into the protocol upon creation and it appears to be intentionally designed as simplistically as possible. It uses TCP over port 179 making it susceptible to all TCP based attacks, e.g. SYN Attacks, Distributed Denial of Service (DDOS), etc. External BGP routers are designed to accept advertised routes from other BGP systems across the Internet making it vulnerable to route leaks. RFC 7908 creates a working definition of route leaks stating, “A route leak is the propagation of routing announcement(s) beyond their intended scope.”
BGP routers announce themselves to other BGP systems indicating IP Addresses they control and their routes. If a BGP system announces a route for a certain group of IPs and can convince the other BGP systems that they are in fact a closer route, sometimes by announcing more specific IP space, the traffic will often decide to take that route. These routers are implicitly trusted and added to routing tables that then propagate across the Internet to other routing tables.
Though these leaks are often unintentional they still carry quite a consequence for either the offending system or the victim system. An incorrect route announcement can send a large increase in traffic through the offending routers making it susceptible to a possible DDOS. Traffic directed through offending systems then becomes vulnerable to eavesdropping. These route changes can last anywhere from a few minutes to several days. The traffic can be stored by threat actors for later sifting or possible decryption and continue its path to the intended destination, or the traffic could be dropped and never make its destination. This could also lead to outages for the victim’s network.
BGP Hijacking Profiles
There are several reports over the years dating back to 1997 that made headlines for the intentional and unintentional rerouting of traffic across the world. Beginning with AS 7007 that had a bug that took various prefixes divided into /24 CIDR ranges and sending them to its upstream ISP. Within just the past couple of years, this trend does not show a sign of stopping. This continues to be a plausible avenue for attackers to redirect traffic or be made painfully obvious of an administrator’s mistake.
In April 2017, BGP monitoring service, BGPMon, reported Russian ASNs that began advertising for over 30 Autonomous Systems that included several financial organizations like MasterCard, VISA and HSBC. The rerouting lasted for about seven minutes and was not confirmed as a malicious hijacking, but was certainly suspicious.
In 2018, a Nigerian ISP advertised the routes for Google’s Cloud Platform, essentially routing the traffic to any BGP systems without safeguards in place. Thousand Eyes reported seeing the traffic route through Russia and China to the Nigerian ISP. It was shortly determined to have been a mistake on the part of the Nigerian ISP and was fixed shortly thereafter.
Beginning in 2016 into 2017, Google, White Ops and a number of other organizations tracked an ad fraud campaign dubbed 3VE and described as “one of the most widespread ad fraud operations ever uncovered.” The campaign conducted BGP hijacking of several defunct and legitimate AS prefixes in order to win bids of web ads and provide fake residential and end user connections for ad revenue.
Chris C. Demchak from the U.S. Naval War College and Yuval Shavitt from Tel Aviv University monitored BGP announcements and were able to determine suspicious reroutes of BGP sessions. They noted how China Telecom maintained 10 points of presence (POP) across North American Internet infrastructure alone, as well as other continents around the globe. These strategic locations allow for unsuspecting and largely undetectable rerouting of traffic through China Telecom controlled access points, even if encrypted, pointing out that these could possibly still be decrypted like in other documented encryption attacks.
Demchak and Shavitt identified hijacks that varied from days to sometimes months. Including traffic between governments, traffic to large banks, and news organizations. The routes identified in these transactions took unusual routes that would indicate a malicious intent and not an unintentional one. Shortly after, an Oracle researcher verified the rerouting of traffic by China Telecom and their efforts to stop it.
In April 2018, for almost two hours, the prefixes for Amazon’s cloud DNS web service, Route 53 were hijacked. The prefixes were redirected to a malicious DNS server in a successful effort to redirect users of myetherwallet.com and steal cryptocurrency.
Bgpstream.com identified over 70 possible hijacks in May 2019 alone. Including a possible hijack of a Dept of Defense AS by a Russian AS on May 10, 2019.
On the morning of June 24, 2019, Cloudflare reported that a Verizon owned BGP optimizer; propagated routes from over 20k prefixes including major sites like Cloudflare, Facebook and Amazon through AS396531 (Allegheny Technologies), a small Pennsylvania company. After being announced to them through their Internet Service Provider (ISP) DQE the information was provided to Allegheny Technologies’ additional transit provider Verizon. Since the routes were more specific they were announced to other networks; propagating the route across the internet and sending tons of traffic their way.
An ounce of prevention or a pound of cure?
To handle the problem of BGP hijacks and leaks an organization can take a monitoring approach to determine when another ASN has announced your address space. When it’s identified, an organization can contact their ISP to take actions such as announcing more specific address space (this is purely a reactive action). That upstream ISP will also likely have several controls in place to protect a customer’s connection against DDOS, SYN Floods and other typical TCP attacks.
For monitoring of route leaks and hijacks there are currently several tools, free and paid services available that will provide monitoring and alerts for your Autonomous System and their external routes including OpenDNS’ bgpmon. As well as threat intelligence services that will identify all systems that are announcing membership of your ASN whether intentionally or by mistake.
Another method to handle leaks and hijacks is more of a preventive approach.
Method 1: Route Origin Authorization (ROA) is part of the Resource Public Key Infrastructure (RPKI) framework. It is a means of verifying if an Autonomous System is allowed to originate from an advertised prefix. A ROA is a signed object that validates that an ASN is authorized to originate or advertise a route for an AS or group of IPs addresses. This object identifies the IP group belonging to the ASN and is signed by its originators private key. The ROA is stored by one of the five Regional Internet Registries (RIR), ARIN, RIPE, APNIC, LACNIC, AFRINIC, which are also considered Trusted Anchors (TA), the equivalent of a Certification Authority (CA).
RPKI would allow the distribution of these ROAs to a cache that a router checks it against to determine when to accept or drop a route change. One protocol to explain this process in detail is the RPKI to Router (RTR) in RFC 6810. Successful implementation will require adoption of a majority of ASNs by both providing ROAs and checking signatures of incoming routes.
Method 2: BGPsec allows a route to validate that each ASN in the chain is authorized to advertise that route. BGPsec validates these routes using the data in RPKI certificates for verification requiring the AS number, the public key and subject key identifier along with other validation checks. RFC 8205 is likely to cause at least a small increase in overhead as the protocol is going from accepting the advertised routes to verifying each advertised route. However, it uses a cache of routes held locally and does not reach out to check each in real time.
Conclusion
BGP hijacking and leaks are still a very prevalent problem across the Internet. With the implementation of a few best practices like monitoring of Autonomous Systems and implementations of route securing using tools like RPKI and BGPSec by larger groups of Internet space, we can begin to combat BGP hijacking and leaks that could lead to rerouting and possible theft of data.