Everything is very bad or a new type of traffic interception
On March 13, the RIPE anti-abuse working group received a proposal to consider BGP interception (hijack) as a violation of the RIPE policy. If the proposal was accepted, the Internet provider attacked by intercepting traffic would be able to send a special request to bring the attacker to clear water. If the expert group collected enough supporting evidence, then that LIR, which is the source of BGP interception, would be considered a violator and could be deprived of LIR status. There were some arguments against this change.
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 interceptions of this type of traffic.
For the last couple of years, only conflicts such as MOAS (Multiple Origin Autonomous System) were covered in the press as BGP interceptions. MOAS is a special case when two different autonomous systems announce conflicting prefixes with the corresponding ASN numbers in AS_PATH (the first ASN in AS_PATH, hereafter referred to as the origin ASN). However, we can name at least 3 additional types of traffic interception, which allow an attacker to manipulate the AS_PATH attribute for different purposes, including for the sake of circumventing modern approaches to filtering and monitoring. The well-known type of attack Pilosov-Kapela - the last type of such interception, but not at all in importance. It is quite possible that we have observed just such an attack in recent weeks. Such an event has an explicable nature and rather serious consequences.
Those who are looking for a TL; DR version can scroll to the subtitle “Perfect Attack”.
')
If you want to send a packet and you have several prefixes in the routing table containing the destination IP address, then you will use the route for the maximum length prefix. If in the routing table there are several different routes for one prefix, you will choose the best one (according to the mechanism for choosing the best path).
Existing approaches to filtering and monitoring try to analyze routes and make decisions by analyzing the attribute AS_PATH. The router can change this attribute to any value during the announcement. Simply adding the ASN owner at the beginning of the AS_PATH (as the origin of the ASN) can be enough to bypass the current source checking mechanisms. Moreover, if there is a route from the attacked ASN to you, it is possible to extract and use AS_PATH of this route in your other announcements. Any validation of only AS_PATH for your scrapped announcements will eventually be passed.
There are still several noteworthy restrictions. First, in the case of prefix filtering by a higher provider, your route can still be filtered (even with the correct AS_PATH), if the prefix does not belong to your client cone configured for upstream. The second is that a valid AS_PATH can become invalid if the created route is announced in incorrect directions and, thus, violates the routing policy. And the last - any route with a prefix that violates the ROA length can be considered invalid.
A few weeks ago we received a complaint from one of the users. We saw routes with its ASN origin and / 25 prefixes, while the user claimed that they had not announced them.
Examples of announcements at the beginning of April 2019
NTT in transit for the / 25 prefix makes it especially suspicious. During the incident, LG NTT did not know anything about this route. So yes, some operator creates the whole AS_PATH for these prefixes! Check on other routers allows you to select one special ASN: AS263444. Looking at other routes with this autonomous system, we encountered the following situation:
Try to guess what's wrong here.
It seems that someone took the prefix from the route, divided it into two parts and announced the route with the same AS_PATH for these two prefixes.
Examples of routes for one of the pairs of separated prefixes
There are several questions at once. Has anyone actually tried this type of interception in practice? Has anyone taken these routes? What prefixes have been affected?
Here begins our series of failures and another round of frustration with the current state of health of the Internet.
First things first. How can we determine which routers have received such intercepted routes and whose traffic can be redirected today? We thought to start with the / 25 prefixes, because they "simply cannot have global distribution." As you can guess, we were greatly mistaken. This metric turned out to be overly noisy and routes with such prefixes can appear even from Tier-1 operators. For example, NTT has about 50 such prefixes, which it distributes among its own clients. On the other hand, this metric is bad because such prefixes can be filtered if the operator applies filtering of small prefixes in all directions. Therefore, this method is not suitable for finding all operators whose traffic was redirected as a result of a similar incident.
Another good idea we thought to look at POV . Especially on routes with violation of the max. Thus, we could find the number of different ASN origin with Invalid status that were visible to this AS. However, there is a “minor” problem. The average value (median and mode) of this number (the number of different ASN origin) is about 150, and even if we filter out small prefixes, it will remain above 70. This state of affairs has a very simple explanation: there are only a few operators who already use ROA- filters with the “drop Invalid routes” policy at the entry points, so wherever in the real world a route with ROA violation appears, it can spread in all directions.
The last two approaches allow us to find the operators who saw our incident (since it was quite large), but in general they are not applicable. Good, but can we find an intruder? What are the common features of such an AS_PATH manipulation? There are several basic assumptions:
If all assumptions are correct, then the attacker’s ASN will be presented on all the incorrect routes (except for the origin ASN) and, thus, this is a “critical” point. Among the true hijackers was AS263444, although there were others. Even when we dropped the incident routes. Why? The critical point can remain critical even for correct routes. It can be either the result of poor connectivity in any region, or the limitations of our own visibility.
As a result: there is a way to detect an intruder, but only if all 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 respected, can we single out the prefixes affected by such interception? For certain operators - yes.
When an attacker creates a more specific route, this prefix is ​​not announced by the true owner. In case you have a dynamic list of all its prefixes from it, then it becomes possible to make a comparison and find distorted more specific routes. We compile this list of prefixes with the help of our BGP sessions, since we are given not only 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, now there are several dozens of Radar users who do not perform the last part correctly. In the near future we will notify them and try to solve this problem. All others can join our monitoring system right now.
If we go back to the original incident, then both the attacker and the distribution area were discovered by us by searching for critical points. Surprisingly, AS263444 did not send fabricated routes to all of its customers. Although there is a stranger moment.
A recent example of an attempt to intercept our address space.
When more specific'i were created for our prefixes, a specially created AS_PATH was used. However, this AS_PATH could not be taken from any of our previous routes. We do not even have a connection with AS6762. We look at other routes in the incident: some of them had a real AS_PATH, which was used earlier, and others did not, even if it looked like a real one. The additional change of AS_PATH does not make any practical sense, since in any case traffic will be redirected to the attacker, but routes with a “bad” AS_PATH can be filtered by ASPA or any other checking mechanism. Here we are thinking about the motivation of the hijacker. We do not have enough data to claim that the incident was a planned attack. However - it is possible. Let's try to present at least a hypothetical, but potentially quite real situation.
What we have? Suppose you are a transit provider that broadcasts routes to your customers. If your customers have multiple presence (multihome), then you will receive only a fraction of their traffic. But the more traffic - the more your income. Therefore, if you start announcing the prefixes of the subnets of the same routes with the same AS_PATH, you will receive the rest of their traffic. As a result, the rest of the money.
Will ROA help here? Perhaps, yes, if you decide to stop using maxLength completely . In addition, it is highly undesirable to have ROA entries with overlapping prefixes. For some operators, such restrictions are unacceptable.
Considering other routing security mechanisms, in this case, ASPA also does not help (because AS_PATH is used from the 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!
The obvious and most radical step is to revise your current routing policy. Break your address space into the smallest pieces (without intersections) that you just want to announce. Sign ROA only for them, 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 problems with 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. For this we need reliable information about your prefixes. Thus, if you establish a BGP session with our collector and give us information about your Internet visibility, we can find a distribution area for other incidents. For those who are not yet connected to our monitoring system - for starters, we only need a list of routes with your prefixes. If you have a session with us, then please check that all your routes have been sent. Unfortunately, it is worth recalling this, since 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 such (and other) types of traffic interception for your address space.
If you know in real time about such interception of your traffic, you can try to counteract on your own. The first approach is to announce routes with these more specific prefixes yourself. In the 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), cutting off the access of your routes to the attacker. This can be done by adding the attacker's ASN to AS_PATH of your old routes and, thus, forcing them to avoid this AS using the built-in loop detection mechanism in BGP for their own benefit .
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 interceptions of this type of traffic.
For the last couple of years, only conflicts such as MOAS (Multiple Origin Autonomous System) were covered in the press as BGP interceptions. MOAS is a special case when two different autonomous systems announce conflicting prefixes with the corresponding ASN numbers in AS_PATH (the first ASN in AS_PATH, hereafter referred to as the origin ASN). However, we can name at least 3 additional types of traffic interception, which allow an attacker to manipulate the AS_PATH attribute for different purposes, including for the sake of circumventing modern approaches to filtering and monitoring. The well-known type of attack Pilosov-Kapela - the last type of such interception, but not at all in importance. It is quite possible that we have observed just such an attack in recent weeks. Such an event has an explicable nature and rather serious consequences.
Those who are looking for a TL; DR version can scroll to the subtitle “Perfect Attack”.
')
Network Background
(so 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, then you will use the route for the maximum length prefix. If in the routing table there are several different routes for one prefix, you will choose the best one (according to the mechanism for choosing the best path).
Existing approaches to filtering and monitoring try to analyze routes and make decisions by analyzing the attribute AS_PATH. The router can change this attribute to any value during the announcement. Simply adding the ASN owner at the beginning of the AS_PATH (as the origin of the ASN) can be enough to bypass the current source checking mechanisms. Moreover, if there is a route from the attacked ASN to you, it is possible to extract and use AS_PATH of this route in your other announcements. Any validation of only AS_PATH for your scrapped announcements will eventually be passed.
There are still several noteworthy restrictions. First, in the case of prefix filtering by a higher provider, your route can still be filtered (even with the correct AS_PATH), if the prefix does not belong to your client cone configured for upstream. The second is that a valid AS_PATH can become invalid if the created route is announced in incorrect directions and, thus, violates the routing policy. And the last - any route with a prefix that violates the ROA length can be considered invalid.
Incident
A few weeks ago we received a complaint from one of the users. We saw routes with its ASN origin and / 25 prefixes, while the user claimed that 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 at the beginning of April 2019
NTT in transit for the / 25 prefix makes it especially suspicious. During the incident, LG NTT did not know anything about this route. So yes, some operator creates the whole AS_PATH for these prefixes! Check on other routers allows you to select one special 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's wrong here.
It seems that someone took the prefix from the route, divided it into two parts and announced the 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 separated prefixes
There are several questions at once. Has anyone actually tried this type of interception in practice? Has anyone taken these routes? What prefixes have been affected?
Here begins our series of failures and another round of frustration with the current state of health of the Internet.
Failure Path
First things first. How can we determine which routers have received such intercepted routes and whose traffic can be redirected today? We thought to start with the / 25 prefixes, because they "simply cannot have global distribution." As you can guess, we were greatly mistaken. This metric turned out to be overly noisy and routes with such prefixes can appear even from Tier-1 operators. For example, NTT has about 50 such prefixes, which it distributes among its own clients. On the other hand, this metric is bad because such prefixes can be filtered if the operator applies filtering of small prefixes in all directions. Therefore, this method is not suitable for finding all operators whose traffic was redirected as a result of a similar incident.
Another good idea we thought to look at POV . Especially on routes with violation of the max. Thus, we could find the number of different ASN origin with Invalid status that were visible to this AS. However, there is a “minor” problem. The average value (median and mode) of this number (the number of different ASN origin) is about 150, and even if we filter out small prefixes, it will remain above 70. This state of affairs has a very simple explanation: there are only a few operators who already use ROA- filters with the “drop Invalid routes” policy at the entry points, so wherever in the real world a route with ROA violation appears, it can spread in all directions.
The last two approaches allow us to find the operators who saw our incident (since it was quite large), but in general they are not applicable. Good, but can we find an intruder? What are the common features of such an AS_PATH manipulation? There are several basic assumptions:
- The prefix was not seen anywhere else;
- Origin ASN (reminder: the first ASN in AS_PATH) is valid;
- The last ASN in AS_PATH is the attacker's ASN (in case its neighbor checks the neighbor's ASN on all incoming routes);
- The attack comes from a single provider.
If all assumptions are correct, then the attacker’s ASN will be presented on all the incorrect routes (except for the origin ASN) and, thus, this is a “critical” point. Among the true hijackers was AS263444, although there were others. Even when we dropped the incident routes. Why? The critical point can remain critical even for correct routes. It can be either the result of poor connectivity in any region, or the limitations of our own visibility.
As a result: there is a way to detect an intruder, but only if all 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 respected, can we single out the prefixes affected by such interception? For certain operators - yes.
When an attacker creates a more specific route, this prefix is ​​not announced by the true owner. In case you have a dynamic list of all its prefixes from it, then it becomes possible to make a comparison and find distorted more specific routes. We compile this list of prefixes with the help of our BGP sessions, since we are given not only 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, now there are several dozens of Radar users who do not perform the last part correctly. In the near future we will notify them and try to solve this problem. All others can join our monitoring system right now.
If we go back to the original incident, then both the attacker and the distribution area were discovered by us by searching for critical points. Surprisingly, AS263444 did not send fabricated routes to all of its customers. Although there is a stranger moment.
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'i were created for our prefixes, a specially created AS_PATH was used. However, this AS_PATH could not be taken from any of our previous routes. We do not even have a connection with AS6762. We look at other routes in the incident: some of them had a real AS_PATH, which was used earlier, and others did not, even if it looked like a real one. The additional change of AS_PATH does not make any practical sense, since in any case traffic will be redirected to the attacker, but routes with a “bad” AS_PATH can be filtered by ASPA or any other checking mechanism. Here we are thinking about the motivation of the hijacker. We do not have enough data to claim that the incident was a planned attack. However - it is possible. Let's try to present at least a hypothetical, but potentially quite real situation.
Perfect attack
What we have? Suppose you are a transit provider that broadcasts routes to your customers. If your customers have multiple presence (multihome), then you will receive only a fraction of their traffic. But the more traffic - the more your income. Therefore, if you start announcing the prefixes of the subnets of the same routes with the same AS_PATH, you will receive the rest of their traffic. As a result, the rest of the money.
Will ROA help here? Perhaps, yes, if you decide to stop using maxLength completely . In addition, it is highly undesirable to have ROA entries with overlapping prefixes. For some operators, such restrictions are unacceptable.
Considering other routing security mechanisms, in this case, ASPA also does not help (because AS_PATH is used from the 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 revise your current routing policy. Break your address space into the smallest pieces (without intersections) that you just want to announce. Sign ROA only for them, 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 problems with 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. For this we need reliable information about your prefixes. Thus, if you establish a BGP session with our collector and give us information about your Internet visibility, we can find a distribution area for other incidents. For those who are not yet connected to our monitoring system - for starters, we only need a list of routes with your prefixes. If you have a session with us, then please check that all your routes have been sent. Unfortunately, it is worth recalling this, since 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 such (and other) types of traffic interception for your address space.
If you know in real time about such interception of your traffic, you can try to counteract on your own. The first approach is to announce routes with these more specific prefixes yourself. In the 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), cutting off the access of your routes to the attacker. This can be done by adding the attacker's ASN to AS_PATH of your old routes and, thus, forcing them to avoid this AS using the built-in loop detection mechanism in BGP for their own benefit .
Source: https://habr.com/ru/post/447876/
All Articles