On March 13, a proposal was brought to the RIPE working group on combating abuses against such changes.
In this publication, we want to present an example of an attack where not only the actual perpetrator was in question but also the entire list of affected prefixes. Furthermore, such an attack raises questions about the motives behind future traffic hijacking of this type.
In recent years, the media has only covered conflicts of the MOAS (Multiple Origin Autonomous System) type as BGP hijacks. MOAS is a special case where two different autonomous systems announce conflicting prefixes with corresponding ASN numbers in AS_PATH (the first ASN in AS_PATH, hereafter referred to as origin ASN). However, we can identify at least of traffic hijacking that allow an attacker to manipulate the AS_PATH attribute for various purposes, including circumventing modern filtering and monitoring approaches. One known type of attack is the latest type of such hijacking, but not the least significant. It is quite possible that this is the type of attack we have been observing over the past few weeks. Such an incident has an understandable nature and quite serious consequences.
Those seeking a TL;DR version can scroll down to the subheading 'The Perfect Attack.'
Network Background
(to help you better understand the processes involved in this incident)
If you want to send a packet and you have several prefixes in the routing table containing the destination IP address, you will use the route for the prefix with the longest length. However, if there are several different routes for one prefix in the routing table, you will select the best one (according to the best path selection mechanism).
Existing approaches to filtering and monitoring attempt to analyze routes and make decisions by scrutinizing the AS_PATH attribute. A router can modify this attribute to any value during announcement. Simply adding the owner ASN at the beginning of the AS_PATH (as the origin ASN) may be sufficient to bypass the current source validation mechanisms. Moreover, if a route exists from the targeted ASN to you, there is an opportunity to extract and utilize the AS_PATH from that route in your other announcements. Any validation of just the AS_PATH for your crafted announcements will ultimately pass.
There are also several noteworthy limitations. First, in the case of prefix filtering by a higher-level provider, your route may still be filtered out (even with a correct AS_PATH) if the prefix does not belong to your client cone configured upstream. Secondly, a valid AS_PATH can become invalid if the created route is announced in incorrect directions, thus violating routing policy. Lastly, any route with a prefix violating ROA length may be deemed invalid.
Incident
A few weeks ago, we received a complaint from one of the users. We observed routes with their origin ASN and prefixes /25, while the user claimed they had not announced 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||
Examples of announcements from early April 2019
NTT is suspicious for the /25 prefix. During the incident, LG NTT was unaware of this route. So yes, some operator is creating an entire AS_PATH for these prefixes! A check on other routers highlights one particular ASN: AS263444. Looking at other routes with this autonomous system, we encountered 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||
Try to guess what is wrong here
It appears that someone took a prefix from a route, split it into two parts, and announced a route with the same AS_PATH 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||
Examples of routes for one of the pairs of split prefixes
Several questions arise immediately. Has anyone actually tried this type of interception in practice? Did anyone accept these routes? What prefixes were affected?
Here begins our series of failures and yet another round of disappointment in the current state of Internet health.
Path of failures
Let's discuss everything in order. How can we determine which routers have accepted such hijacked routes and whose traffic may be redirected today? We thought to start with /25 prefixes, as they "simply can't have global distribution." As you might guess, we were very wrong. This metric turned out to be too noisy, and routes with such prefixes can even come from Tier-1 operators. For example, NTT has about 50 such prefixes that it disseminates among its own customers. On the other hand, this metric is poor because such prefixes can be filtered out if the operator applies , in all directions. Therefore, this method is not suitable for identifying all operators whose traffic has been redirected as a result of such an incident.
Another good idea seemed to be to look at . Specifically, at routes that violate the maxLength rule of the corresponding ROA. This way, we could find the number of different origin ASNs with Invalid status that were visible to this AS. However, there is a "small" problem. The average (median and mode) of this number (the number of different origin ASNs) is about 150, and even if we filter out small prefixes, it will remain above 70. This situation has a fairly simple explanation: there are only a few operators that already apply ROA filters with a policy of 'dropping Invalid routes' at entry points, so wherever a route with ROA violations appears in the real world, it can be distributed in all directions.
The last two approaches allow us to identify operators that noticed our incident (since it was significant enough), but overall they are not applicable. So, can we find the perpetrator? What are the common features of such AS_PATH manipulation? There are several basic assumptions:
- The prefix was never seen anywhere before;
- The Origin ASN (reminder: the first ASN in AS_PATH) is valid;
- The last ASN in AS_PATH is the perpetrator's ASN (assuming its neighbor checks the neighbor's ASN on all incoming routes);
- The attack originates from a single provider.
If all assumptions are correct, then all improper routes will display the attacker’s ASN (aside from the origin ASN), making it a ‘critical’ point. One of the true hijackers was AS263444, although there were others. Even when we disregarded the incident routes. Why? A critical point can remain critical even for valid routes. It may result from poor connectivity in a region or from limitations in our own visibility.
As a result: there is a way to detect the attacker, but only if all the above conditions are met and only when the interception is substantial enough to pass monitoring thresholds. If some of these factors are not met, can we identify the prefixes affected by such interception? For certain operators — yes.
When an attacker creates a more specific route, that prefix is not announced by the legitimate owner. If you have a dynamic list of all their prefixes, it becomes possible to compare and find distorted more specific routes. We gather this prefix list through our BGP sessions, as we are provided not only with a complete list of routes visible to the operator right now but also a list of all prefixes they wish to announce to the world. Unfortunately, there are currently several dozen Radar users who do not fully comply with this final requirement. We will notify them soon and try to address this issue. Everyone else can join our monitoring system right now.
Returning to the original incident, both the attacker and the scope of the spread were detected by us using critical point search. Surprisingly, AS263444 was sending fabricated routes only to some of its clients. Although there’s an even stranger aspect.
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 an attempt to hijack our address space.
When the more specific prefixes for our prefixes were created, a specially constructed AS_PATH was used. However, this AS_PATH could not be derived from any of our previous routes. We even have no connection with AS6762. Let's look at other routes in the incident: some of them had a real AS_PATH that was used earlier, while others did not, even if they seemed genuine. An additional modification of AS_PATH has no practical meaning, as traffic will be redirected to the attacker anyway, but routes with a 'bad' AS_PATH can be filtered out by ASPA or any other verification mechanism. Here we pondered the motivation of the hijacker. Currently, we lack the data to assert that this incident was a planned attack. Nevertheless, it is possible. Let’s try to envision at least a hypothetical, but potentially quite realistic situation.
The Ideal Attack
What do we have? Suppose you are a transit provider transmitting routes for your clients. If your clients have multiple presences (multihome), you will receive only part of their traffic. But the more traffic you handle, the higher your revenue. Therefore, if you start announcing the prefixes of subnets of those same routes with the same AS_PATH, you will capture the remainder of their traffic. As a result, you get the rest of the income.
Will ROA help here? Possibly, yes, if you decide to completely abandon usage. . Moreover, it is highly undesirable to have ROA records with overlapping prefixes in this context. For some operators, such restrictions are unacceptable.
Considering other routing security mechanisms, in this case, ASPA will also not help (because it uses the AS_PATH from an allowed route). BGPSec is still not an optimal choice due to the low adoption rate and the remaining possibility of downgrade attacks.
Thus, we have clear profits for the attacker and a lack of security. A perfect mix!
What needs to be done?
The most obvious and radical step is to rethink your current routing policy. Break your address space into the smallest non-overlapping pieces that you wish to announce. Sign ROAs only for them, without using the maxLength parameter. In this case, the current POV might save you from such an attack. However, again, for some operators, this approach is not sensible due to the heavy use of more specific routes. All issues regarding the current state of ROAs and route objects will be discussed in one of our upcoming materials.
Additionally, you can attempt to monitor such intercepts. For this, we need reliable information about your prefixes. Thus, if you set up a BGP session with our collector and provide us with information about your visibility on the Internet, we can find the distribution area for other incidents as well. For those who are not yet connected to our monitoring system, we will initially only need a list of routes with your prefixes. If you already have a session with us, please ensure that all your routes have been sent. Unfortunately, this is worth reminding, as some operators forget one or two prefixes, thus causing interference with our detection methods. If everything is done correctly, we will have reliable data about your prefixes, which will help automatically identify and detect such (and other) types of traffic intercepts for your address space in the future.
If you have real-time knowledge of such an intercept of your traffic, you can attempt to counteract it yourself. The first approach is to announce routes with these more specific prefixes yourself. In case of a new attack on these prefixes, repeat the announcement.
The second approach is to punish the attacker and those for whom he is a critical point (for good routes) by cutting off your routes' access to the attacker. This can be done by adding the attacker's ASN to the AS_PATH of your old routes, thereby forcing them to avoid this AS using the built-in loop detection mechanism in BGP. .
Source: habr.com
