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 hijack as a violation of the RIPE policy. If the offer was accepted, the Internet provider attacked by intercepting traffic would be able to send a special request to bring the attacker to clean water. If the expert group collects 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 against this change.

    In this publication, we want to show an example of an attack when not only the real attacker was in doubt, 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.

    Over the past couple of years, only conflicts like MOAS (Multiple Origin Autonomous System) have been reported in the press as BGP intercepts. 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, hereinafter referred to as origin ASN). However, we can name at least 3 additional typesinterception of traffic that allows an attacker to manipulate the AS_PATH attribute for various purposes, including for the sake of circumventing modern approaches to filtering and monitoring. The well-known type of Pilosov-Kapela attack is the last type of such interception, but not at all in significance. It is possible that this is precisely the attack we have observed over the past weeks. Such an event has an understandable character and rather serious consequences.

    Those who are looking for a TL; DR version can scroll to the subheading “Perfect Attack”.

    Network background

    (so that 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 prefix with the maximum length. If in the routing table there are several different routes for one prefix, you will choose the best one (in accordance with the mechanism for choosing the best path).

    Existing filtering and monitoring approaches try to analyze routes and make decisions by analyzing the AS_PATH attribute. The router can change this attribute to any value during the announcement. Just adding the owner ASN at the beginning of AS_PATH (like origin ASN) may be enough to bypass the current source verification mechanisms. Moreover, if there is a route from the attacked ASN to you, it becomes possible to extract and use the AS_PATH of this route in your other announcements. Any validation of only AS_PATH for your crafted announcements will eventually be passed.

    There are several noteworthy limitations. Firstly, in the case of filtering prefixes 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 in upstream. Second, a valid AS_PATH can become invalid if the created route is advertised in the wrong 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 origin ASN and / 25 prefixes, while the user claimed that they had not announced them. Examples of announcements at the beginning of April 2019 NTT on the way for the / 25 prefix makes it especially suspicious. During the incident, the LG NTT knew nothing about this route. So yes, some kind of operator creates an entire AS_PATH for these prefixes! Testing on other routers allows you to highlight one special ASN: AS263444. Looking at other routes with this autonomous system, we came across 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 .

    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||





    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||





    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 divided 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 series of failures begins and another round of disappointment in the current health of the Internet.

    The path of failure


    First things first. How can we determine which routers have accepted 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 very wrong. This metric was 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 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 searching for all operators whose traffic was redirected as a result of such an incident.

    Another good idea we thought was to look at POV. Especially on routes that violate the maxLength rule of the corresponding ROA. Thus, 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 value (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 very simple explanation: there are only a few operators that already use ROA- filters with the “reset Invalid routes” policy at entry points, so wherever a route with an ROA violation appears in the real world, 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. Ok, but can we find the attacker? What are the common 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 ASN of the attacker (if his neighbor checks the ASN of the neighbor on all incoming routes);
    • The attack comes from one provider.

    If all the assumptions are true, then on all incorrect routes the attacker's ASN will be presented (except for the origin of 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 from consideration. Why? A 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 attacker, but only if all the above conditions are met and only when the interception is large enough to pass the monitoring thresholds. If any of these factors are not respected, can we single out the prefixes affected by such an interception? For certain operators, yes.

    When an attacker creates a more specific route, such a prefix is ​​not announced by the true owner. If you have a dynamic list of all of its prefixes from it, then you can make a comparison and find distorted more specific routes. We collect this list of prefixes using our BGP sessions, as we are given not only a complete list of routes visible to the operator right now, but also a list of all the prefixes that he wants to announce to the world. Unfortunately, now there are several dozen Radar users who do not complete the last part correctly. In the near future we will notify them and try to solve this problem. Everyone else can join our monitoring system right now.

    If we return to the original incident, then the attacker and the area of ​​distribution 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 more strange moment. A recent example of an attempt to intercept our address space

    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||



    When more specific for our prefixes were created, the 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, while others did not, even if they look like real. An additional change to AS_PATH makes no practical sense, since in any case the 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 thought about the motivation of the hijacker. Now we do not have enough data to claim that this incident was a planned attack. Nevertheless, it is possible. Let’s try to imagine a hypothetical one,

    Perfect attack


    What we have? Suppose you are a transit provider that broadcasts routes for your customers. If your customers have multiple presence (multihome), then you will receive only part of their traffic. But the more traffic - the more your income. Therefore, if you start announcing subnet prefixes 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 completely abandon the use of maxLength . In addition, it is highly undesirable to have ROA entries with intersecting prefixes. For some operators, such restrictions are unacceptable.

    Considering other routing security mechanisms, ASPA will not help in this case either (because AS_PATH is used 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 pieces (without intersections) that you only want to announce. Sign ROAs for them only, not 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 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 give us information about your visibility of the Internet, we can find the distribution area for other incidents as well. 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 sent. 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,

    If you find out in real time about such an interception of your traffic, you can try to counter 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 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 ASN of the attacker to the AS_PATH of your old routes and thus making them avoid this AS using the built-in loop detection mechanism in BGP for their own benefit .

    Also popular now: