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

The article is divided into three parts. The first contains general information about what BGP hijacking and its traditional version are. For those who are familiar with this phenomenon, it is recommended to go directly to the second part. The second part will describe the method of announcing foreign prefixes by adding a foreign AS to your AS-SET. In the third part, an assessment will be made of the complexity of using the method described in the second part to capture the IP address of the torproject.org resource and issue a 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 capturing someone else's IP addresses (random or intentional).

Usually, BGP hijacking looks like this: an AS that does not own a prefix starts to announce it (someone else's prefix), uplinks / peers accept it, and it begins 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 so conceived (since it is very difficult to build a prefix filter at the junction with very large operators due to various reasons, this is not important for this article) ) One of the most high-profile examples of recent times when Rostelecom ( AS12389 ) began to announce the prefixes Mastercard ( AS26380 ), Visa and some other financial organizations (according toofficial version , as a result of a software failure). You can see how these announcements looked in the bgplay history ( viewing via web , json ( archive )), here is one of them on one of the RIPE collectors (the 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 a prefix directly from its AS (the last AS in AS-PATH is 12389). Problems could be avoided if uplinks and feasts of Rostelecom filtered prefixes from Rostelecom by building prefix lists according to AS-SET and / or validating prefixes according to ROA RPKI . The construction of prefix lists between large operators is often not done, and not all have implemented RPKI (but progressthere is). Such hijacking, theoretically, can be done by anyone, but only if the announced prefix “leaks” through at least one uplink / feast. Usually, large Russian operators configure prefix filters in the direction of their customers and therefore, small AS (small / medium-sized operators, some hosting and some enterprises), almost always, cannot perform 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 (In 2017, the hijacking leaderwas Brazil) and carry out an attack by grabbing IP addresses (often, such events fall into the news feeds), for a 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 version, where neither ROA RPKI validation nor AS-SET prefix lists save.

BGP hijacking with the addition of AS victim in its AS-SET

Consider the following scenario:

1. An attacker obtains AS and IP addresses (in fact, technically, he does not need IP addresses, they are more likely just to not cause questions).
2. The attacker connects to various large operators and IXs (at least one operator or IX), specifying not just his AS, but his AS-SET as a source of data about the announced prefixes (this is normal practice for inter-operator interaction (including including when in a client-uplink relationship) or for inclusion on IX-ah)). In the normal case, AS-SET is specified, and not just AS, when it is assumed that the client is not a dead end, but it itself has (or will have) clients with bgp and their own networks.
3. After some time, the attacker adds the victim's AS to his AS-SET and begins to announce his prefix through himself, i.e. the announced AS-PATH looks like this: “AS_ attacker AS_ victims”. From the point of view of automatically constructed prefix lists and from the point of view of RPKI, this is a completely valid announcement, so both protection mechanisms will not work here.
4. The announced prefix begins to compete with the real announcement (the announcement of the victim), somewhere he wins and gets into the routing table, somewhere he loses and won’t (the victim’s announcement will remain there). It depends on how many uplinks and how many IXs an attacker uses. When an attacker connects to some AS as a client, then inside it (most often) he will win the victim due to a larger local-pref (if the victim is not a client of the same uplink, then the victim will win by AS-PATH if he doesn’t prepend), i.e. an attacker needs to connect to as many uplinks as possible with his AS-SET in order to maximize the effectiveness of his attack.
   Also, the attacker must connect to the maximum number of IXs, as usually, deadlock ASs set the highest local-pref to IXs and if the victim prefix is ​​not involved in IX, then it will lose the attacker's announcement in the routing tables of the deadlock ASs.

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

1. You need to draw up a legal entity, at least one, but in fact, most likely will be required in different countries.
2. It is necessary to conclude agreements with operators, IXs, almost always make a connection fee, with LIR / RIR.
3. Some operators still do not build AS-SET prefix lists automatically, they need to write letters for this. An experienced administrator will suspect something if the AS-ka of a well-known company suddenly appears in the AS-SET of an unknown company.
4. After the attack, the equipment used (if it is located in some kind of data center) will most likely be seized in the event that a criminal case is opened.
5. The prefix lists for 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 protection measures:

1. Theoretically, in order to defend against such an attack, you need to have as many interfaces as possible with the operators (better, the client ones, because they have local-pref higher) and IXs. Those. do the same thing an attacker will do. Of course, in practice this is extremely difficult to implement and will require significant resources. This method is relevant only for services that provide 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) (see RFC6844 ). In this case, the attacker will not be able to issue a certificate (unless he can change the CAA record)
3. Theoretically, the widespread implementation of BGPsec should eliminate such an attack, but its fate is not yet clear (in practice it is not yet applied or very rarely).
4. Implementation of alternative verification AS_PATH (without BGPsec) (so far this is a draft that solves the described problem in case of its widespread implementation).
5. The prohibition of the uncontrolled addition of a foreign AS to your AS-SET (without the permission of the AS owner) could reduce the possibility of carrying out 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 advice that applies to them is No. 2 (regarding the use of account in a CAA record) and partially No. 1 in the context of choosing a host with good connectivity. In this case, you need to 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 (target audience - 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 binding to the account in the CAA record, which means the problem is theoretically solved by the attacker. The IP addresses of torproject.org are owned by the well-known Hezner hosting.

Suppose 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 IX-s). The easiest way for an attacker to redirect CA traffic to himself is to become a client of this operator and simply win at the expense of a higher local-pref. Everything here is especially relatively simple and clear.

To get a certificate in letsencrypt, you need the provider on which letsencrypt is hosting to direct traffic to the attacker, and not to Hezner (AS24940). letsencrypt resolves to different addresses for American and European IP, but let's see how difficult it will be to influence that traffic from acme-v02.api.letsencrypt.org/2.19.125.202 go to the attacker's host. Here we are faced with the fact that letsencrypt is hosted on Akamai CDN, which has very good connectivity around the world (it is present on most major IXs, 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 even without a public LG you can take a look at peering dbto assess the scale of their presence. Similarly, you can look at hezner . It is easy to see that both ASs have the presence of the same IXs, hence we can conclude that with a probability close to unity, the AS Hezner prefixes (AS24940) in the Akamai table (AS20940) are visible with AS_PATH 24940. This means that if an attacker If it tries to announce Hezner’s prefixes through some IX, then they will lose according to AS_PATH the real announcements from Hezner (since AS_PATH will contain the attacker’s AS). A possible solution would be to organize a “direct” peering between the attacker and Akamai (if Akamai agrees to this and if it will be local-pref higher than at the junctions with IXs).

To summarize, by adding someone else’s AS to your AS-SET, you can cause significant degradation of the torproject.org website (for a large number of clients, but not for everyone in the general case), but get the torproject.org SSL certificate in letsencrypt, most likely it won’t work out due to the good connectivity between the real originator (Hezner) and the CDN 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.