BGP hijacking by adding the victim's AS to the attacker's AS-SET

The article is divided into three parts. The first one contains general information about what BGP hijacking is and its traditional version. For those who are familiar with this phenomenon, it is recommended to go directly to the second part. In the second part, the method of announcing foreign prefixes will be described by adding a foreign AS to your AS-SET. In the third part, an assessment will be made of the difficulty of using the method described in the second part, to capture the IP address of the torproject.org resource and extract the certificate for it. It is assumed that the reader is familiar with the principles of BGPv4.

Simple bgp hijacking

In a nutshell, BGP hijacking is the capture of foreign IP addresses (accidental or intentional).

Usually, BGP hijacking looks like this: AS, to which some prefix does not belong, starts to announce it (someone else's prefix), uplinks / peers accept it, and it starts to spread over the Internet. They accept it for the reason that there is no filtering of prefixes at the junction (either this is a configuration error or it’s intended (since building a prefix filter at the junction with very large operators is very difficult due to various reasons, this is not important for this article) ). One of the most notorious examples of recent times, when Rostelecom ( AS12389 ) began announcing the prefixes Mastercard ( AS26380 ), Visa and some other financial organizations (according to the official version , as a result of a software crash). How these announcements looked like, you can see in the bgplay history ( view via web , json ( archive )), here’s one of them on one of the RIPE collectors (prefix 216.119.216.0/24 belongs to Mastercard (AS26380)):
')

"source_id": "05-193.203.0.185", "path": [ 6939, 12389 ], "community": [], "target_prefix": 216.119.216.0/24 

And here is what the real announcement looked like:

  "source_id": "05-193.203.0.63", "path": [ 6720, 8447, 32787, 26380, 26380, 26380 ], "community": [ "1120:1" ], "target_prefix": 216.119.216.0/24 

Those. in this case, Rostelecom announced the prefix directly from its AS (the last AS in AS-PATH is 12389). The problems could have been avoided if Rostelecom's uplinks and peers filtered the prefixes from Rostelecom by building prefix lists using AS-SET and / or validating prefixes using ROA RPKI . Building prefix lists between large operators is often not done, and RPKI also implemented not all (but there is progress ). Such hijacking, theoretically, can be done by anyone, but only if the advertised prefix “leaks” through at least one uplink / feast. Usually, large Russian operators set up prefix filters in the direction of their customers and therefore, small AS (small / medium operators, some hosting and some enterprises), almost always, cannot make such an attack (but again, it all depends on the region / country / specific operator).

However, attackers still find places (uplinks) where filtering is not configured (Brazil was the leader in hijacking in 2017) and carry out an attack to capture IP addresses (often, such events get into news feeds), for more effective attack, they can announce more specific prefixes (with a longer mask) than a real originator. Now let's move on to the attack variant, where neither ROA RPKI validation nor AS-SET prefix lists save.

BGP hijacking with AS victim added to your AS-SET

Consider the following scenario:

1. The attacker gets AS and IP-addresses (in fact, technically, IP-addresses are not needed, rather, they are just in order not to cause questions).
2. The attacker connects to various large operators and IXs (minimally - at least to one operator or IX), indicating as a source of data about advertised prefixes not just their AS, but their own AS-SET (this is normal practice for inter-operator interaction (including number when in client-uplink relationship) or to be included on IXs)). In the normal case, AS-SET is indicated, and not just AS, when it is implied that the client is not a dead end, but it itself has (or will have) clients with bgp and its networks.
3. After some time, the attacker adds the victim's AS to his AS-SET and starts announcing his prefix through himself, i.e. The announced AS-PATH looks like this: "AS_activistress AS_sherves." From the point of view of automatically constructed prefix-lists and from the point of view of RPKI, this is a completely valid announcement, therefore, both defense mechanisms will not work here.
4. The announced prefix begins to compete with the real announcement (the announcement of the victim), somewhere it will win and get into the routing table, somewhere it will lose and will not fall (there will remain the announcement of the victim). It depends on how many uplinks and how many IXs the attacker uses. When an attacker connects to an AS as a client, then inside it he (most often) will win over the victim at the expense of greater local-pref (unless the victim is a client of the same uplink, then AS-PATH will win the victim, if not prepend), i.e. An attacker needs to connect to as many uplinks with his AS-SET to maximize the effectiveness of his attack.
   Also, the attacker must connect to the maximum number of IXs, because usually, stub AS expose the largest local-pref on IXs, and if the victim's prefix does not participate in IX, then he will lose to the attacker's announcement in the routing tables of the stub AS.

In theory, this is a pretty strong attack, but fortunately, in practice the following limitations will arise:

1. It is necessary to draw legal entity, at least one, but in fact, most likely will be required in different countries.
2. It is necessary to conclude contracts with operators, IXs, almost always to make a connection fee, with LIR / RIR.
3. Some operators still do not build prefix lists for AS-SET automatically, they need to write letters for this. An experienced administrator will suspect something if an AS-company widely known appears in an AS-SET of an unknown company.
4. After the attack, the equipment used (if it is located in any data center) is likely to be withdrawn in the event of a criminal case being opened.
5. The prefix lists of different operators / IX are updated at different times, so you will need to analyze who updates when, this is also not the easiest job.

Possible protective measures:

1. Theoretically, in order to protect against such an attack, you need to have as many joints with operators (preferably client ones, because local-pref is higher) and IXs. Those. do the same thing that the attacker will do. Of course, in practice it is extremely difficult to implement and will require significant resources. This method is relevant except for services that are engaged in the provision of information security services on a professional basis.
2. If you have a website, use a CAA record with the account task (if your SSL certificate provider supports it. Letsencrypt supports it) (see RFC6844 ). In this case, the attacker will not be able to issue a certificate (unless it can change the CAA record)
3. Theoretically, the widespread adoption of BGPsec should eliminate such an attack, but so far its fate is not clear (in practice it is not yet used or very rarely).
4. Implementing an alternative AS_PATH verification (without BGPsec) (for now, this is a draft that solves the described problem if it is universally implemented).
5. Banning the uncontrolled addition of a foreign AS to your AS-SET (without the permission of the owner of the AS) could reduce the possibility of conducting such attacks in those regions where AS-SETs are used for filtering at the joints. Now there is no such ban.

In fact, for most readers, the only applicable advice for them is No. 2 (regarding the use of an account in CAA records) and partly No. 1 in the context of choosing a hoster with good connectivity. At the same time, you should remember about possible attacks on the DNS service in which you host your records (but this is a separate issue and there are a lot of materials on it)

Is it difficult to capture torproject.org

An attacker needs to solve two problems:

• Redirect traffic to the target audience (Central Asia - who will receive the fake site)
• Generate certificate

Introductory:

 $ dig torproject.org CAA +short 128 issuewild "\;" 0 iodef "mailto:torproject-admin@torproject.org" 128 issue "globalsign.com" 128 issue "letsencrypt.org" $ dig torproject.org +short 95.216.163.36 138.201.14.197 

As you can see, there is a CAA record, you can get a certificate from letsencrypt, there is no CAA record in the binding, so the problem is theoretically solved by an intruder. The IP addresses of the torproject.org domain are owned by a well-known hosting host Hezner.

For example, an attacker's target audience is the clients of some Russian operator. Hezner is not a client of Russian operators (but has peering with large ones - directly or through IXs). In order for an attacker to redirect Central Asian traffic to himself, the easiest way is to become a client of this operator and simply win at the expense of higher local-pref. Here, especially, everything is relatively simple and clear.

To get a certificate in letsencrypt, it is necessary that the provider in which it is hosted letsencrypt began to send traffic to the attacker, and not to Hezner (AS24940). letsencrypt resolves to different addresses for American and European IPs, but let's see how difficult it is to influence the traffic from acme-v02.api.letsencrypt.org/2.19.125.202 to go to the attacker's host. Here we are faced with the fact that letsencrypt is hosted at Akamai CDN, which has very good connectivity around the world (it is present on most large IXs, it has direct joints with a large number of large players). Akamai does not have a public LG, in principle, there is an API for clients with which you can do traceroute / ping, but without a public LG you can take a look at peering db to assess the scale of their presence. Similarly, you can look at hezner . It is easy to see that both ASs have a presence on the same IXs, hence we can conclude that with probability close to one, the AS Hexner prefixes (AS24940) in the Akamai table (AS20940) are visible with AS_PATH 24940. This means that if an attacker If he tries to announce Hezner prefixes through some IX, then they will lose AS_PATH with real announcements from Hezner (since the attacker will be AS of the attacker in AS_PATH). A possible solution could be the organization of a "direct" peering between the attacker and Akamai (if Akamai agrees to this and if it is local-pref higher than at the junctions with IXs).

To summarize, by adding someone else's AS to your AS-SET, you can cause a significant degradation of the torproject.org website (for a large number of clients, but not for everyone in general), but to get the SSL certificate torproject.org at letsencrypt, most likely, it will not work because of the good connectivity between the real originator (Hezner) and the CDN, which is used by letsencrypt (Akamai). However, in other cases, when there are transit ASs between the hosting of the victim site and the certification authority and they are present in AS_PATH, the risk of obtaining a certificate by the described method is significantly increased.