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.

For the last couple of years, when our colleagues or we were describing BGP hijacking events, mostly MOAS conflicts were covered. MOAS (Multiple Origin Autonomous System) is a case when two different autonomous systems announce the conflicted prefixes with their respective ASNs in the origin of the AS_PATH (first ASN in AS_PATH, further in the text - origin ASN). However, we can name 3 additional hijack types allowing a malicious party to manipulate AS_PATH for different reasons, including bypassing today’s filtering and monitoring services. The famous Pilosov-Kapela type of attack is last, but not least. A possible example of this attack is what we think we saw for the last few weeks, observing for the first time in the wild. Such an event could have an understandable nature and severe consequences. For those looking for the TL;DR version, scroll down to “The Ideal Attack.”

Networking Background
(for you to better understand the processes behind the incident)

If you want to send a packet and have several prefixes in your forwarding table that includes a destination IP-address, you’ll use a route to prefix with the maximum length. If you have several different routes in your routing table for one prefix, you’ll choose the best one (under best path selection mechanism) to include in forwarding.

Existing filtering and monitoring services try to analyze routes and make their decisions by looking on routes’ AS_PATH attribute. BGP speaker can change this attribute to any value during the announcement. Simple adding of the owner ASN at the beginning of an AS_PATH (as origin ASN) might be enough to bypass modern origin validation mechanism. Moreover, if there is any route from a target ASN to you, you can retrieve and use AS_PATH from this route in your other announcements. Any validation check of solely AS_PATH for this route would fail.

There are several limitations that we want to mention. First - in case of prefix filtering by your upstream, your route can still be filtered out (even with the valid AS_PATH) if the prefix does not belong to upstream’s customer cone. Second - valid AS_PATH can become invalid if the crafted route is announced in wrong directions and thus start breaking routing policies. The last one - any route that has a prefix that is violating the ROA maxLength could be considered Invalid.

The Incident

A few weeks ago our user wrote us a complaint. We have seen routes with his origin ASN and /25 prefixes in it while the user claimed that he didn’t announce them.

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||

Announces example by the beginning of April 2019

NTT in a way for a /25 prefix route makes it especially suspicious. During the incident, NTT's LG knew nothing about this route. So yeah, some operator creates the whole AS_PATH for these prefixes! Other speakers highlight one special ASN: AS263444. After looking at other routes with this ASN, we run into the following situation.

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||

You can try to guess what is wrong

It seems that someone took a prefix from the route, split prefix onto two parts and announce the route with same AS_PATHs for these two prefixes.

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||

Example of routes for one of the split pairs of prefixes

Several questions arise. Who probed such hijack type? Did anyone accept these routes? Which prefixes were affected?

So here starts our path of failure and yet another round of disappointment in the current state of the Internet health situation.

Path of Failure

However, first things first. How can we find which speakers accepted such hijacked routes and whose traffic is redirected already? We were thinking about /25 prefixes because “they just can not appear in the wild.” You can guess it - we were very wrong about it. It’s a very noisy metric, and routes with such prefixes can even appear from Tier-1 operators. Even NTT have around 50 prefixes that it propagates to its customers. On the other hand, this metric is terrible because these prefixes could be filtered out if the operator applies one of the BGP best practices, namely small prefixes filtering, in all directions. So we cannot use this method to find all of the operators whose egress traffic was redirected by an incident.

Another wild thought was to look at the ROV. Specifically at routes with violation of the maxLength rule of a corresponding ROA. So we can look for some different origin ASN with Invalid status that was seen by the AS. Still, there is a “little” problem. The average (median and mean) of this number is around 150, and even if we filter out small prefixes, it will remain higher than 70. There is a simple explanation for this result: there are only a few operators who already apply a ROA based filter with “drop Invalid routes” policy on their ingress points, so wherever route with such violation appeared in the wild, it can spread in all directions.

Last two approaches highlight accepted parts of the recent incident (because it was massive enough), but they are not generally applicable. However, maybe we can find an attacker? What are the general features of such an AS_PATH manipulation? There are several assumptions:

• The prefix did not appear previously in the wild;

• Origin ASN (reminder: the first ASN in the AS_PATH) is the valid one;

• The last ASN in AS_PATH is the ASN of the attacker (in case if his neighbor make a neighbor ASN check in all incoming routes);

• The attack comes from one ISP.

If all assumptions are correct, then in all malformed routes the hijacker ASN would be presented (besides origin ASN) and thus may be claimed as critical one. We can take any of previous feature (“/25” or “Invalid routes”), and for any ASN count, the number of different origin ASN whose routes matching this feature have a critical point in it. Among the true hijacker - AS263444, some others were highlighted even when we dropped routes with him from consideration. Why? Critical point can be critical even for reasonable routes. It could be a result of connectivity lack in some region or some limitations in our visibility.

There is a way to detect an attacker, but only meeting several conditions, and only when the hijack is enormous to bypass monitoring thresholds. However, can we found out prefixes that suffered hijack regardless of all the above factors? Actually - yes.

When hijacker creates a route with more specific, such prefix is not announced by the original ISP so, if you can somehow get a trustful list of all announced prefixes made by this operator itself, then for such operators you can make a comparison and find malformed routes with more specifics. We gather this list of prefixes from our BGP sessions. It’s simple enough - you're announcing not only the full view of routes that you see right now but also the list of all the prefixes that you are willing to announce in the world. Sadly enough, right now there are several dozens of our users, that don’t do the last part correctly. We’ll notify them in the nearest future and try to solve this problem. For all the others - you can join our monitoring system today. That is how we gather this particular data, represented in this article.

If we return to the initial incident, the attacker and accepted parts were found out with critical points method. It’s strange, but not all the customers of AS263444 have seen these routes. Also, there is another strange point.

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||

BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||

A recent example of our address space hijack

When this hijacker creates more specific for our prefixes, it used crafted AS_PATH. However, this AS_PATH was not taken from any of our previous routes. We even don’t have a link with AS6762. We look at other routes in the incident: some of them were having real AS_PATH that was used previously, but others - not, even if they look like real. There is no practical meaning in this change because in any case, traffic would be redirected to an attacker, but routes with bad AS_PATH can be filtered out by ASPA or another verification mechanism. It raises questions about hijacker motives. As for now, we can’t claim that this incident was a planned attack. It could be, though. Let’s try to imagine a possible IRL situation.

The Ideal Attack

What do we end up with? You are a transit provider, announcing routes to customers. If they are multihomed, you will get only a part of their traffic — however, the more traffic — the more revenue. So, if you announce subnet prefixes of these routes with the same AS_PATH, you’ll get the rest of the traffic. Also, the rest of the money.

Could ROA help? Possibly yes, if you decide not to use maxLength at all. Also, you don’t have any ROA records with intersected prefixes in them. For some of the operators, it’s not a possible option.

Looking at other security mechanisms, ASPA wouldn't help (because AS_PATH is from the valid route) with this particular hijack. BGPSec is still a bad option due to deployment rate and remaining possibility of downgrading attack.

So we have a clear profit for an attacker and the lack of security. A great mix!

What should be done?

The obvious and the most radical possible step - you can make a review of your current routing policy. Also, split your address space onto the smallest chunks (without intersections), that you have a desire to announce. Sign a ROA only for them without using a maxLength option. Then current ROV can and would save you from this attack. But again, for some operators, this is not a reasonable approach because of an exclusive use for more specific routes (all the problems in the current state of ROA and route objects would be described in one of our future articles).

Also, we can try to monitor this kind of situation. To do so, we need ground truth about your prefixes. So you can contact us, set a BGP session with our collector and pass us information about your view of the Internet. We’ll highly appreciate if you send us a full-view (so we can find propagation scope of other incidents), but the whole list of routes with your prefixes should be enough for the beginning. If you have already set a session with us, please check that all your routes are sent. We find around a few dozen of operators, that forget one or two of their prefixes and create noise in our finding methods. So we would have a reliable data about your prefixes and in the future can automatically detect this type of hijacks for your address space.

When you find out about this situation, you can also try to mitigate it. The first approach - announce routes with these more specific prefixes by yourself. In case of a new attack on these prefixes - repeat. The second approach - punish an attacker and those for whom he is a critical point (for good routes) by restricting access of your routes to him. You can do this by adding their ASN in AS_PATH of your old routes and thus avoiding their AS by exploiting BGP route loop detection mechanism for your good, which we described earlier.