BGP hijacking is an illicit process of taking control of a group of IP prefixes assigned to a potential victim. Either intentionally or accidentally, it is achieved by changing paths used for forwarding network traffic, exploiting the weaknesses of BGP. The aim of this blog post is to explore these weaknesses and to discuss possible countermeasures.
BGP exchanges routing and reachability information among Autonomous Systems (AS). Information is exchanged between BGP speaking routers called BGP peers (neighbors). BGP peers are explicitly defined with the neighbor command and they trust each other. It means that IP prefix announced by a router is accepted by its neighbor by default (except for when the neighbor detects its own AS number in the AS_PATH attribute (BGP loop prevention mechanism)). The IP prefix is then installed into the peer routing table and is advertised to the other BGP peers. The prefix is then propagated to other ASs without checking if an origin AS owns the prefixes which it announces. In fact, everyone who has been assigned an AS number or gained access to a BGP speaking router can announce any prefix.
A partial BGP hijacking occurs when two origin Autonomous Systems announce an identical IP prefix with the same prefix length. The BGP best path selection rules, such as preferring the shortest AS path, determine which path is the best.
The partial BGP hijacking was committed in the process of YouTube prefix hijacking by Pakistan Telecom on Sunday, February 24
The complete BGP hijacking occurs when an attacker announces de-aggregated thus a more specific IP prefix than the actual owner of the prefix.
This tactic, however, was put to good use by YouTube in the incident described above, to bring the hijacked prefix 208.65.153.0/24 back. YouTube started to announce this prefix as two sub-prefixes 208.65.153.0/25 and 208.65.153.128/25. They knew that the longest prefix match rule prefers more specific route. Paths toward these prefixes were preferred so the YouTube service could be reachable again. After the PCCW Global (AS3491) withdrew all prefixes originated by AS 17557 (Pakistan Telecom), YouTube could announce the aggregate route 208.65.152.0/22 again instead of the more specific prefixes.
The AS17557 incident is a result of misconfiguration caused by lack of proper filtering on AS17557 side and possibly AS3491 side. It is worth mentioning, that filtering Tier 2 ISP (PCCW) is certainly a much harder task than filtering a Tier 3 ISP (Pakistan Telecom) due to enormous number of IP prefixes.
Filtering IP prefixes on Tier 3 ISP and customer side, however, can reduce occurrence of BGP hijacks. So, let’s review the known best practices in the following part.
Below are the common filtering examples. They should not be applied all at once but rather chosen according to the needs.
We can limit the AS_PATH in announced prefixes using BGP AS path filter. The regular expression ^$ in ACL statement matches empty AS_PATH thus it allows only locally announced prefixes being sent to ISP.
ip as-path access-list 1 permit ^$
router bgp 64502
neighbor 200.1.1.1 filter-list 1 out
The lines above are applied on the customer router (AS64502) towards ISP (AS64500) BGP peer address 200.1.1.1. The AS64502 is added to ASP_PATH after the filter is applied. The configuration prevents customer AS64502 to become transit AS in case of a multihomed connection. As a result, traffic sent from another ASs is not routed through customer but uses a high-speed link of upstream providers instead.
The ISP can also configure the AS_PATH filter towards customer BGP router 200.1.1.2.
ip as-path access-list 1 permit ^64502$
router bgp 64500
neighbor 200.1.1.2 filter-list 1 in
Now we create a prefix-list on a customer router that permits the announcement of only the assigned prefix 199.1.1.0/24. The list is applied toward ISP router. All other prefixes are not being sent.
ip prefix-list filter_out seq 10 permit 199.1.1.0/24
router bgp 64502
neighbor 200.1.1.1 prefix-list filter_out out
The ISP should only accept prefixes which have been assigned or allocated to its customer.
ip prefix-list as64502in seq 10 permit 199.1.1.0/24
router bgp 64500
neighbor 200.1.1.2 prefix-list as64502in in
Customers do not need to know about the path to their own prefixes so they should filter them. However, filtering the single prefix 199.1.1.0/24 is not sufficient. If someone announces customer prefix with the longer prefix length than /24 it would be installed into customer routing table. For this reason, we need to specify the prefix length to 32. The sequence 10 denies customer prefix 199.1.1.0 within the length from 24 to 32. The sequence 20 accept only prefixes that are not denied by a rule 10 and their prefix length is /24 and less.
Unless customers do not need a default route they should block it. Sequence 10 denies a default prefix. All other routes are matched and permitted by sequence 20.
Bogons are IP prefixes that should not be announced on the public Internet. There are two types of bogons. First category of bogons are unallocated IP prefixes that have not been assigned to RIR by IANNA and allowed for public use. As the public IP address pool is depleating, these bogons become less common. The second category of bogons are the so called Martians. Those are prefixes for private use such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 and reserved IP addresses used for loopbacks.
We can filter bogons by manually entering prefixes that should be blocked. However, as the bogons list is updated from time to time it is better to automate the peering process with Bogon Route Server project offered by Team CYMRU.
The Bogon route server advertises a list of bogons via eBGP multihop session using a private AS 65333. The configuration below establishes eBGP peer session with two Bogon Route Servers. The community list 65333:888 accepts all bogons and it is matched by a route map CYMRUBOGONS. The route map sets a next-hop 192.0.2.1 for bogons learned from CYMRU Route Servers. The route map is applied towards CYMRU peers for all incoming routes received from them. Bogon packets are discarded thanks to a static route 192.0.2.1/32. The prefix-list cymru-out filters all prefixes to Bogon route server.
router bgp 64502
bgp router-id 200.1.1.2
neighbor cymru-bogon peer-group
neighbor cymru-bogon remote-as 65333
neighbor cymru-bogon ebgp-multihop
neighbor cymru-bogon prefix-list cymru-out out
neighbor cymru-bogon route-map CYMRUBOGONS in
neighbor cymru-bogon maximum-prefix 100neighbor CYMRU_PEER_1_IP peer-group cymru-bogon
neighbor CYMRU_PEER_2_IP peer-group cymru-bogonip route 192.0.2.1 255.255.255.255 null0
ip bgp-community new-format
ip community-list 10 permit 65333:888
route-map CYMRUBOGONS permit 10
match community 10
set ip next-hop 192.0.2.1
ip prefix-list cymru-out seq 5 deny 0.0.0.0/0 le 32
To avoid flooding BGP advertisements from a customer, we can control how many prefixes can be received from a neighbor. Once the neighbor sends more prefixes than a configured limit, the session will switch from Established to Idle (PfxCt).
The session will remain in Idle state until it’s cleared/reset with the command below.
If we want to automatically reestablish a BGP session after the limit is reached, we add keyword restart and define a restart interval in minutes. In case, restart/shutdown of BGP session is not acceptable, we can produce only a syslog message with the keyword warning-only once a limit of prefixes is reached.
When the IP prefixes are hijacked, connection might be redirected and discarded as in the Pakistan Telecom incident. In this case detection of hijacking is an easy task since a service becomes unavailable. As for the BGP Man in the Middle attacks, when data might be intercepted or modified, detection is not so straightforward because the connection is working. BGP hijacking, however, can still be detected since the BGP AS_PATH attribute gets changed. Moreover, network traffic takes different (not optimal) path which leads to degraded performance and the increased round-trip time (RTT). Providers’ Looking Glass (LG) servers or Route Views are great tools to discover a change in the routing paths. We covered LG topic here in more detail.
One of the most recent BGP hijacking events happened on April 24th, 2018. The attackers used BGP and DNS vulnerabilities to intercept and reroute traffic to Amazon’s Route 53 DNS infrastructure service. The only known victim so far is MyEtherWallet.com. Traffic to this cryptocurrency website was redirected to a server hosted in Russia for as long as 2 hours, serving a phishing site where the private keys to accounts got thieved. (Read about the other types of attacks against Cryptocurrency Networks using BGP hijacking here). A relatively small amount of cryptocurrency from MyEtherWallet.com was stolen, however the incident once again alerted the networking community to the existing BGP and DNS security vulnerabilities at scale.
Another BGP hijacking events happened on April 26th, 2017 when the AS12389 (PJSC Rostelecom), one of the largest national telecommunications operators in Russia started to announce 37 prefixes belonging to various financial institutions and credit card processors (Visa International, MasterCard Technologies LLC, etc.). Even though the possible hijacking lasted no more than 7 minutes it is still not clear if the traffic got intercepted or modified. List of all the affected institutions can be found here.
The current BGP design is based on unconditional trust between BGP peers. The BGP has no ability to verify the accuracy of routing information thus everybody can announce anything. Even the best safeguards that we have already mentioned cannot fully protect us against hijacking if they are not implemented globally in the Internet. The Resource Public Key Infrastructure (RPKI) and BGPsec are solutions to these problems.
RPKI allows network operators to cryptographically define who is allowed to announce prefixes and verify whether an Autonomous System (AS) is authorized to announce a specific prefix. For this purpose, Routing Origin Authorization (ROA) is created by operators of ASs and signed by a private key. ROA contains a set of prefixes tied with the origin AS. BGP speaking routers then validate advertised prefixes against ROA. Based on a result, if there are multiple paths to the prefixes, a lower local preference can be configured for unauthorized prefix so the path via authorized origin is proffered. BGP routers do not do validation by themselves but they ask a remote validator (RPKI server) if an origin AS is authorized to announce a prefix. We covered RPKI topic in more details in a separate article
RPKI only validates if an origin AS is authorized to announce a prefix. However, RPKI does not check if the entire path is correct. Attacker can bypass it by adding the origin AS at the end of AS_PATH in a BGP update message. The BGPsec protocol addresses this problem ensuring that the entire path from the origin AS to the destination is valid. Each router on the path adds not only its local AS along with prefix but also the AS number of receiving neighbor to whom it is going to send an update message. This information is signed by a private key and a router attaches a digital signature together with the hash of its public key to the BGPsec update message as BGPsec_Path attribute. The BGPsec update message is sent to the neighbor which do the same and it adds its own signature signed with its own private key, plus hash of its public key. Every edge router on the path validates all the signatures in a message to determine the authenticity of the path information contained in the BGPsec_Path. We covered BGPsec in a separate article.
BGP Stream monitoring service offers a detailed look at the BGP leaks and hijacks. For instance, from November 28th of 2015 up to 31st of May, 2017 there were 2615 BGP leaks detected by the service. The map below illustrates the geographic locations of BGP leaking ASs for the discussed period, with the darkest colored countries having the most leaks.
These illegitimate advertisements have no malicious purpose and they are caused by misconfiguration, mostly due to improper filtering. The AS that leaks the prefix inserts itself somewhere in the AS path. As a result, traffic is redirected through the leaker AS which can impact network performance.
The chart below illustrates a disappointing situation with the ongoing BGP leaks incidents over the previous 19 months, which could have been avoided with proper IP prefix filtering.
In contrast with BGP leaks, the AS that hijacks the prefix claims that it is an originator of prefix. In this case, the AS number of the hijacker is placed on the right side of AS path. Traffic can be completely redirected, specially if the announced prefix length is longer than the prefix length announced by the legitimate origin AS. From November 28th of 2015 up to 31st of May, 2017, BGP Stream service detected 3482 possible hijacks. The map below shows the geographic locations of possible hijackers victims and the density of hijacks (darkest colors representing the most incidents) for the mentioned period. There is a strong correlation between leaks and hijacks in terms of where they occur, leading to the likely conclusion that most BGP Hijacking incidents are more like to be user error, rather than malicious.
The chart below illustrates the frequency of possible BGP hijacks over the past 19 months.
BGP hijacking happens almost on a daily basis and represents a serious security threat to public Internet. This situation should no longer be overlooked, especially in the Internet of Things (IoT) era, when more and more devices are connected to the Internet.
Unfortunately, we live in an imperfect routing security world. The BGP hijacking prevention options described above do not represent the universal remedy for the problem. The benefits of BGPsec implementation can only be obtained once a large number of ASes deploy it, which in its turn depends on individual ASes business objectives.
Nevertheless, the combination of RPKI and Prefix Filtering can still significantly lower the amount of BGP hijacking incidents, improving the overall state of routing security, thus should be looked at with much consideration.
While RPKi and BGPsec are admirable proposed solutions, they are far from within reach of being fully utilized. Prefix filtering on the client side should help prevent most instances of leaks and accidental hijacking, along with adequate filters on the connected provider side.
For truly malicious hijacking, the only option is to hope that the connected provider has adequate filters, to monitor where your prefixes are being announced from and, if needed, announce smaller prefixes so that control can be regained, until the incident can be resolved with the malicious announcers’ upstream providers.