March 13 to the RIPE Anti-Abuse Working Group treat BGP hijacking (hjjack) as a violation of RIPE policy. If the offer was accepted, the ISP attacked by intercepting traffic would be able to send a special request to bring the attacker to clean water. If the expert group gathers enough supporting evidence, then such a LIR, which is the source of BGP interception, would be considered an intruder and could be deprived of LIR status. There were some arguments changes.
In this publication, we want to show an example of an attack when not only the real attacker was in question, but the entire list of affected prefixes. Moreover, such an attack again raises questions about the motives for future intercepts of this type of traffic.
Over the past couple of years, only MOAS (Multiple Origin Autonomous System) conflicts have been covered in the press as BGP intercepts. MOAS is a special case where two different autonomous systems advertise conflicting prefixes with corresponding ASNs in AS_PATH (the first ASN in AS_PATH, hereinafter referred to as origin ASN). However, we can name at least interception of traffic, allowing an attacker to manipulate the AS_PATH attribute for various purposes, including for the sake of bypassing modern approaches to filtering and monitoring. Known type of attack - the last type of such interception, but not at all in importance. It is quite possible that we have observed such an attack over the past weeks. Such an event has an explicable character and rather serious consequences.
Those looking for the TL;DR version can scroll down to the "Perfect Attack" subheading.
network background
(to better understand the processes involved in this incident)
If you want to send a packet and you have multiple prefixes in the routing table containing the destination IP address, then you will use the route for the prefix with the maximum length. If there are several different routes for the same prefix in the routing table, you will choose the best one (according to the best path selection mechanism).
Existing filtering and monitoring approaches attempt to parse routes and make decisions by parsing the AS_PATH attribute. The router MAY change this attribute to any value at the time of advertisement. Simply adding the owner's ASN at the beginning of AS_PATH (as the origin ASN) may be sufficient to bypass the current origin verification mechanisms. Moreover, if there is a route from the attacked ASN to you, it is possible to retrieve and use the AS_PATH of that route in your other announcements. Any AS_PATH only validation for your crafted announcements will eventually pass.
There are a few other limitations worth mentioning. First, in case of prefix filtering by an upstream provider, your route can still be filtered (even with correct AS_PATH) if the prefix does not belong to your upstream configured client cone. Second, a valid AS_PATH can become invalid if the created route is advertised in incorrect directions and thus violates the routing policy. Lastly, any route with a prefix that violates ROA length can be considered invalid.
Incident
A few weeks ago we received a complaint from one of the users. We saw routes with his origin ASN and /25 prefixes, while the user claimed he didn't advertise 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 at the beginning of April 2019
NTT in the path for the /25 prefix makes it particularly suspicious. At the time of the incident, LG NTT had no knowledge of this route. So yes, some operator creates a whole AS_PATH for those prefixes! Checking on other routers allows one particular ASN to be identified: AS263444. After looking at other routes with this autonomous system, we came across 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's wrong here
It seems that someone took a prefix from a route, split it into two parts, and advertised a route with the same AS_PATH for those 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 routes for one of the pairs of split prefixes
Several questions arise at once. Has anyone really tried this type of interception in practice? Has anyone taken these routes? What prefixes were affected?
This is where our streak of bad luck begins and another round of frustration with the current health of the internet.
Path of failure
About everything in order. How can we determine which routers have accepted such intercepted routes and whose traffic can be redirected today? We thought to start with /25 prefixes because they "simply can't have a global distribution". As you can guess, we were very wrong. This metric turned out to be too noisy and routes with such prefixes can appear even from Tier-1 operators. For example, NTT has about 50 such prefixes that it distributes to its own customers. On the other hand, this metric is bad because such prefixes can be filtered out if the operator applies , in all directions. Therefore, this method is not suitable for finding all operators whose traffic was redirected as a result of such an incident.
Another good idea we thought to look at . Especially on routes that violate the maxLength rule of the corresponding ROA. Thus, we could find the number of different origin ASNs with status Invalid that were visible to the given AS. However, there is a "small" problem. The mean (median and mode) of this number (number of different ASN origins) is around 150 and even if we filter out the small prefixes, it stays above 70. This state of affairs has a very simple explanation: there are only a few operators that already use ROA- filters with a βdrop Invalid routesβ policy on entry points, so wherever in the real world a route with ROA violation appears, it can propagate in all directions.
The last two approaches allow you to find operators who saw our incident (since it was quite large), but in general they are not applicable. Okay, but can we find the intruder? What are the general features of such AS_PATH manipulation? There are several basic assumptions:
- The prefix has not been seen anywhere before;
- Origin ASN (reminder: first ASN in AS_PATH) is valid;
- The last ASN in AS_PATH is the attacker's ASN (if its neighbor checks the neighbor's ASN on all incoming routes);
- The attack comes from one provider.
If all assumptions are correct, then all bad routes will present the attacker's ASN (other than the origin ASN), and thus this is a "critical" point. Among the true hijackers was AS263444, although there were others. Even when we've dropped the incident routes from consideration. Why? A critical point may remain critical even for valid routes. It can either be the result of poor connectivity in a particular region, or the limitations of our own visibility.
As a result: there is a way to detect an intruder, but only if all of the above conditions are met and only when the interception is large enough to pass the monitoring thresholds. If some of these factors are not met, then can we isolate the prefixes affected by such interception? For certain carriers, yes.
When an attacker creates a more specific route, such a prefix is ββnot advertised by the true owner. If you have a dynamic list of all its prefixes from it, then it becomes possible to compare and find distorted more specific routes. We collect this list of prefixes using our BGP sessions, since we are not only given the full list of routes that the operator sees right now, but also a list of all the prefixes that he wants to announce to the world. Unfortunately, there are now several dozen Radar users who do not complete the last part correctly. We will notify them as soon as possible and try to resolve this issue. Everyone else can join our monitoring system right now.
If we return to the original incident, then both the attacker and the distribution area were discovered by us using the search for critical points. Surprisingly, AS263444 did not send the fabricated routes to all of its clients. There is something even weirder though.
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 intercept our address space
When more specific were created for our prefixes, a specially crafted AS_PATH was used. However, this AS_PATH could not have been taken from any of our previous routes. We don't even have a connection to AS6762. Looking at the other routes in the incident, some of them had the real AS_PATH that was used before, and others didn't, even if they look like the real one. An additional change to AS_PATH does not make any practical sense, since the traffic will be redirected to the attacker anyway, but routes with a "bad" AS_PATH can be filtered out by ASPA or any other inspection mechanism. Here we thought about the motivation of the hijacker. At present, we do not have enough data to state that this incident was a planned attack. Nevertheless, it is possible. Let's try to imagine at least a hypothetical, but potentially quite real situation.
Perfect Attack
What we have? Let's say you are a transit provider broadcasting routes for your customers. If your customers have multiple presence (multihome), then you will receive only a part of their traffic. But the more traffic, the more your income. So if you start advertising subnet prefixes of those same routes with the same AS_PATH, you will get the rest of their traffic. As a result, the rest of the money.
Will ROA help here? Possibly yes, if you decide to completely stop using . Also, it is highly discouraged to have ROA records with overlapping prefixes. For some operators, such restrictions are unacceptable.
Considering other routing security mechanisms, ASPA won't help in this case either (because it uses AS_PATH from a valid route). BGPSec is still not the best option due to the low acceptance rate and the remaining possibility of downgrade attacks.
Thus, we have a clear profit for the attacker and a lack of security. Great mix!
What do we have to do?
The obvious and most radical step is to review your current routing policy. Break your address space into the smallest chunks (no overlaps) you want to advertise. Sign the ROA for them only, without using the maxLength parameter. In this case, the current POV can save you from such an attack. However, again, for some operators, this approach is not reasonable due to the exclusive use of more specific routes. All the problems of the current state of ROA and route objects will be described in one of our future materials.
In addition, you can try to monitor such interceptions. To do this, we need reliable information about your prefixes. Thus, if you establish a BGP session with our collector and pass us information about your Internet visibility, we can find the scope for other incidents. For those who are not yet connected to our monitoring system, for a start, a list of routes with only your prefixes will be enough for us. If you have a session with us, then please check that all your routes have been submitted. Unfortunately, this is worth recalling, as some operators forget one or two prefixes and thus interfere with our search methods. If everything is done correctly, then we will have reliable data about your prefixes, which in the future will help to automatically detect and detect this (and other) types of traffic interception for your address space.
If you become aware of such an interception of your traffic in real time, you can try to counteract it yourself. The first approach is to advertise routes with these more specific prefixes yourself. In case of a new attack on these prefixes, repeat.
The second approach is to punish the attacker and those for whom he is a critical point (for good routes) by cutting off the access of your routes to the attacker. This can be done by adding the attacker's ASN to the AS_PATH of your old routes and thus causing them to avoid that AS using BGP's built-in loop detection mechanism. .
Source: habr.com