What is BGP Hijacking?
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.
Partial BGP Hijacking
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 24th, 2008. The Pakistan ISP (AS17557) configured a static route 18.104.22.168/24 pointing to null in order to block YouTube access for AS17557 customers. However, the ISP started to announce the prefix 22.214.171.124/24 towards its upstream provider PCCW Global (AS 3491) that propagated the announcement to its peers. In an hour and twenty minutes, YouTube (AS36561) that had been announcing prefix 126.96.36.199/22 (188.8.131.52/24, 184.108.40.206/24, 220.127.116.11/24, 18.104.22.168/24) so far, started to fight back. YouTube began to announce more specific prefix 22.214.171.124/24. They kept announcing 126.96.36.199/24 for another 11 minutes, however the service would still not be available for a large part of YouTube users. Those were the users whose traffic took a path towards Pakistan Telecom AS17557, thus it could not reach YouTube. The traffic was being backhauled by a static route configured on Pakistan AS17557 edge router.
Complete BGP Hijacking
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 188.8.131.52/24 back. YouTube started to announce this prefix as two sub-prefixes 184.108.40.206/25 and 220.127.116.11/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 18.104.22.168/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.
BGP Hijacking Prevention by IP Prefix Filtering
Below are the common filtering examples. They should not be applied all at once but rather chosen according to the needs.
Limit AS_PATH in Announced Prefixes
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 22.214.171.124 filter-list 1 out
The lines above are applied on the customer router (AS64502) towards ISP (AS64500) BGP peer address 126.96.36.199. 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 188.8.131.52.
ip as-path access-list 1 permit ^64502$
router bgp 64500
neighbor 184.108.40.206 filter-list 1 in
Announce Only Owned Prefixes
Now we create a prefix-list on a customer router that permits the announcement of only the assigned prefix 220.127.116.11/24. The list is applied toward ISP router. All other prefixes are not being sent.
ip prefix-list filter_out seq 10 permit 18.104.22.168/24
router bgp 64502
neighbor 22.214.171.124 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 126.96.36.199/24
router bgp 64500
neighbor 188.8.131.52 prefix-list as64502in in
Filter Own Prefixes and Accept only Prefixes with Length /24 and Less
Customers do not need to know about the path to their own prefixes so they should filter them. However, filtering the single prefix 184.108.40.206/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 220.127.116.11 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.
ip prefix-list filter_in seq 20 permit 0.0.0.0/0 le 24router bgp 64502
neighbor 18.104.22.168 prefix-list filter_in in
Filter Default Route
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.
ip prefix-list filter_defaultin seq 20 permit 0.0.0.0/0 le 32router bgp 64502
neighbor 22.214.171.124 prefix-list filter_defaultin in
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 126.96.36.199
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
Limit Maximum Prefixes
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).
neighbor 188.8.131.52 maximum-prefix number
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.
Detection of BGP Hijacking
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.
Recent BGP Hijacking Incidens
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.
RPKI and BGPsec protocol
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.
Frequency of BGP Leaks and Hijacks
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.
Boost BGP Preformance
Automate BGP Routing optimization with Noction IRP