On the (in)security of Internet routing

How is routing done in the Internet today?

Today, we live a connected life, and we often take the Internet for granted. But if you think twice about it, Internet is a kind of little miracle. Indeed, for the Internet to work properly, thousands of networks need to cooperate. Those networks are built and administrated by different companies, universities or individuals. Yet, their loose cooperation is needed in order for you to be able to see the cat GIF image that someone else has posted on a website.

A schematic representation of the Internet

In more serious terms, network engineers say that the Internet consists in a set of interconnected networks, the autonomous systems (or ASs). Those ASs are built independently, and they have the responsibility for managing a slice of the global Internet Protocol (IP) address space. This slice of the address space takes the form of one or several prefixes, i.e. a set of addresses that begin with the same bits. The various autonomous systems in the Internet are given a unique number, their AS number (ASN), by the regional registries that are responsible for administrating the addressing resources in the Internet.

When the Internet grew from a few autonomous systems to hundreds, and even thousands of interconnected ASs, it became necessary to design an automatic and manageable method to exchange prefixes and their reachability among ASs. In 1989, during an IETF meeting, an evening discussion between two engineers from Cisco and IBM and a few drawings on two napkins gave birth to the first version of the Border Gateway Protocol (BGP).

BGP in its 4th version is still in use today, and its operation drives the way traffic is routed across the Internet among ASs. In BGP, two networks, the BGP neighbors, establish a session manually by creating TCP sessions on port 179. Those TCP sessions are used to exchange path information messages by which each network advertises the prefixes it can reach. Those messages carry a set of information set by network administrators at both ends of the peering connection that will be used by each network to take informed routing decisions:

• The Origin of the path
• The AS path, i.e. the list of AS that are crossed on the path to a destination
• The Next hop, i.e. the IP address of the BGP router that has sent the path information announcement
• The Local Preference, a metric indicating the preference of this path for the network that sent the path information announcement
• The path’s weight, which is a local parameter set at the router level for the paths it receives.

as well as a set of other parameters.

When a router in an autonomous system builds its routing table to reach another AS, it gathers all the announcements received and take its decision according to a set of rules. Those rules might depend on what is decided by the network administrator managing the router but, overall, they follow the same first steps. First of all, for a given IP destination, the messages announcing the least specific prefixes are ignored: for instance, a /24 prefix (IP addresses starting with the same 24 bits) will be preferred over a /22 prefix. Then equally specific prefix announcements are classified based on their weight, their local preference, the length of their AS path or their origin type.

BGP weaknesses and prefix hijacking, the reason for routing insecurity in the Internet

As many things in the Internet, BGP is prone to errors, and misconfigurations. Involuntary errors may lead to the inability to reach some prefixes in the Internet, yet, if they result from involuntary errors they are detected quite quickly by the community which reacts to cope with this temporary failure. This informal collaboration is working quite well because of the sense of responsibility and of information exchange in the community. Yet, some weaknesses of the BGP protocol might be used by evil attackers to hijack Internet traffic directed to a given AS. There are mainly two types of such hijacking attacks:

• Prefix hijacking attacks, often dubbed “fat finger attacks” given their similarity with involuntary configuration mistakes, are attacks in which a malicious AS announces a prefix that belongs to a legitimate AS to capture traffic towards this prefix. This attack can be performed by an attacker that aims at doing a Man in the Middle attack, wants to cut the victim from the Internet, wants to listen to the victim’s traffic to see what it is doing or, at a state level, to censor contents.

• AS hijacking attacks, which are more elaborated attacks where a malicious AS uses social engineering and specifically target victims in order to claim ownership of the IP prefixes managed by the victim and use them for malicious purposes such as sending Spam or performing Denial of service attacks (or denial-of-service according to Wikipedia).

Anatomy of a prefix hijacking attack

Given their relative simplicity, prefix hijacking attacks tend to happen more frequently than AS hijacking ones. Let’s now look at a prefix hijacking attack to see how an attacker can redirect and get access to an AS’s Internet traffic. On the 26th of April 2017, at 22:36:40 CET, Worldline (AS 8677) has been targeted by such an attack from a Russian AS, Rostelecom (AS 12389). Given that Worldline was only one of the 37 AS victims of this attack which targeted specifically several players in the payment ecosystem, this attack has been reported by IT news websites. While I consider this example given that Worldline has been targeted, this is not the only occurence of such an attack. More recently, on the 12th of December, another Russian ISP hijacked IP prefixes from Google, Apple or Facebook.

A visualization of Rostelecom’s hijacking attack. Source: BGPMon

In this specific attack, described in details by BGPMon, Rostelecom announced a route for a prefix, 160.92.181.0/24, a specific subset of 160.92.176.0/21 which was announced by Worldline. As one can observe on post-mortem incident reports from BGPStream, this announcement reached most of Rostelecom’s providers, including Core-backbone, Hurricane Electric, Interoute or Swisscom which are among the most connected ASs on the Internet. Following the rules that we presented previously, those providers considered the more specific announcement done by Rostelecom and started spreading the wrong route associating 160.92.181.0/24 to Rostelecom. This hijacking attack’s effects peaked around 22:39:30, when counter measures taken by our networking teams began to be taken into account by Rostelecom’s peers and recipients of this mistaken announcement, with a return to the normal situation at 22:44:00.

This attack is representative of a very commonly used prefix hijacking technique which consists in announcing a more specific prefix than the one announced by the victim AS. Indeed, there is a consensus among the community to announce as generic prefixes as possible. By doing so, the community aims at reducing the number of entries that BGP routers have to manage, which increased a lot in the past few years. In the attack presented before, the attacker has taken advantage of this weakness to announce a more specific prefix, and thus take precedence over the BGP prefix announcements done by Worldline.

A specific prefix attack

The other method by which an attacker might hijack an IP prefix is by announcing a shorter AS route to this prefix, resulting in a redirection of the traffic towards those prefixes in part of the Internet.

A shorter AS path attack

What is at risk with those attacks?

BGP hijacking attacks can have very serious consequences. First of all, an attacker might want to cut you from the Internet by redirecting the traffic it captured from you to /dev/null. In this case, the attacker behaves as a vandal. Even if such attacks are annoying, they are not the most preoccupying. Indeed, BGP hijacking can be used to perform “Man in the middle” attacks. Yet, as explained by Alexander Azimov in a recent presentation, a problem might occur if the web service is accessed in HTTPS using a redirection from HTTP. Then, as explained in the figure below, the attacker might be able to catch user credentials by acting as a proxy between the web service using HTTPS and the user that is using HTTP while thinking he navigates in a secure environment. Such an attack is unfortunately possible, given that secure web services users do not verify that they are on a secured website checking the certificate exposed by the web site all the time.

A possible exploitation of a “Man in the middle” attack on a secured web site. Source: BGP Flexibility and… Its Consequences, Alexander Azimov

How to react to such an attack?

To react to such an attack, the first key principle we follow, and that is followed by most operators in the Internet is to monitor the prefixes that belong to us and how they are seen in the Internet. Indeed, a quick discovery of a prefix hijacking is necessary to ensure a quick response to the incident and to limit its consequences. A set of tools either freely available from the community (Routeviews, RIPE’s MyASN service, IIJ labs’s Internet Health Report) or from commercial providers can help network administrator in monitoring how their prefixes are announced and seen from distant parts of the Internet.

Then, once an attack is detected, the victim AS can either announce an even more specific prefix, or announce an equally specific prefix with a higher priority or a lower cost. In any case, it is important to contact the AS originating the bad prefix announcement in order to warn him that a potential error has happened in its router configuration, or the AS’s providers in order to filter the improper announcement as quickly as possible. Given the prefix announcements propagation time and BGP’s convergence time, it can take up to a few minutes before counter measures take full effect, so a timely response is key to limit the attack’s effects.

In order to mitigate the potential consequences of a prefix hijacking attack, it can be interesting to warn the users of a potential issue, and take time to write a note allowing them to check that they connect to a legitimate resource, by checking the certificate for instance. In the worst case, a victim AS can limit the access to its most sensitive resources during the hijacking attack, for instance by controlling that a given service has not been accessed by a user after a redirection from a vulnerable channel.

The IP routing community is working to answer the vulnerabilities of the BGP protocol, and has standardized a set of technologies to solve the problems that make prefix hijacking possible: in 1995, the Internet Routing Registry, a hierarchy of registries where the ownership of the various IP prefixes can be looked for, has been described. Today this Internet Routing Registry consists in roughly 35 hierarchically organized registries that ASs can use to assess the validity of prefix origins. Later, the Routing Public Key Infrastructure (RPKI) has been designed in order to allow BGP routers to validate the updates they receive from their peers. Based on RPKI, BGPSec is an evolution of BGP that aims at making sure that the AS path is not tampered with in order to hijack prefixes. When they are used in coordination, those three technologies can increase the confidence an AS can have in the prefix announcements it receives. Yet, they are not widely deployed yet, and network administrators still rely on monitoring and reactive methods to ensure their network is correctly reachable. In the meantime, several people in the inter-domain routing community advocate for the wider deployment of MANRS, a set of routing announcements filtering rules aiming at reinforcing routing security in the Internet.

Conclusion

Even if, by its importance and the number of targeted ASs, the attack presented in this post has made it to the headlines of some IT news websites, such attacks or misconfigurations are not a rare event. Even if the routing community is working on a set of techniques to secure BGP routing, as a user or as a developer of connected applications, it is safe to assume that the “Man in the middle” attack that we have seen in our network security textbooks impersonated by the evil Carol is a possible risk for the integrity of communications over the Internet. Thus, if you ever want to keep your exchanges confidential, it is safe to assume that the Internet can’t be trusted for that, and you should use an end to end security approach.