Attacks on BGP.

These violations can be obtained as a result of the following attacks on the BGP protocol.
BGP works based on the TCP protocol, listening on port 179. Therefore, the BGP protocol is vulnerable to attacks on TCP, which we discussed earlier.
Attack of confidentiality violations. As mentioned earlier, BGP route data is transmitted in clear text, which makes it easy to intercept information (this is because the confidentiality of route data is not a general requirement).
Replay attack. BGP does not include measures to prevent the reuse of intercepted messages.
The message insertion attack. BGP does not include message insertion protection. However, since BGP uses the TCP transport protocol, when the connection is completed, message insertion by an external node will require accurate prediction of sequence numbers (such prediction is possible, but very difficult for good TCP implementations) or session interception.
Message deletion attack. BGP does not include message deletion protection. Again, such attacks are very difficult for high-quality TCP implementations, but they cannot be completely excluded.
The message modification attack. BGP does not include protection against message modification. Syntactically correct modification without changing the size of TCP data will generally be unnoticeable.
Man-in-the-middle attack. BGP does not include protection against MITM attacks. BGP does not use partner authentication, and such attacks become a "child's toy."
Denial of service attack. Although false routing data itself can serve as a DoS attack on the end system trying to transmit data through the network, and the network as a whole, some types of false information can create DoS attacks on the BGP protocol itself. For example, the announcement of a large number of more specific routes (longer prefixes) may lead to an increase in BGP traffic and the size of routing tables, which will be unacceptable for the system.
To summarize what is described in this section, it should be noted that the presence of risks is due to three main vulnerabilities:
the lack of a built-in mechanism to protect the integrity and relevance of data, authentication of partners for sending messages;
the lack of an AS authorization verification mechanism for the announced NLRI (Network Layer Accessibility Information) information;
the lack of a mechanism to ensure the reliability of route attributes announced by AS.
Simple BGP hijacking.
BGP hijacking usually looks like this: AS, which does not own a prefix, begins 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 it is intended that way (because it is very difficult to build a prefix filter at the junction with very large operators due to various reasons, it is not important for this article)). One of the most high-profile examples of recent times is when Rostelecom (AS12389) began announcing the prefixes of Mastercard (AS26380), Visa and some other financial organizations (according to the official version, as a result of a software failure). You can see what these announcements looked like in the history of bgplay (viewing via web, json (archive)), here is 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's 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
That is, in this case, Rostelecom announced the prefix directly from its AS (the latest AS in AS-PATH is 12389). The problem could have been avoided if Rostelecom's uplinks and peers had filtered 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 has also not been implemented by far (but there is progress). Theoretically, anyone can commit such hijacking, but only if the announced prefix "leaks" through at least one uplink/peer. Usually, large Russian operators set up prefix filters towards their customers, and therefore small AS (small/medium-sized operators, some hosting companies and some enterprises) almost always cannot carry out 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/ capture of IP addresses (such events often get into the news
tapes), for greater effectiveness, attacks can announce more specific prefixes (with a longer mask) than the real originator. Now let's move on to the attack option, where neither ROA RPKI validation nor AS-SET prefix lists can save.
BGP hijacking with the addition of the victim's AS-SET.
Consider the following scenario.
The attacker gets AS and IP addresses (in fact, technically, he does not need IP addresses, rather, they are only in order not to raise questions).
The attacker connects to various large operators and IX's (minimally to at least one operator or IX), specifying not just his AS, but his AS-SET as the source of data about the announced prefixes (this is a normal practice for inter-operator interaction (including in client-uplink relationships) or to enable on IX)). 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 he himself has (or will have) clients with bgp and his own networks.
After a while, 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_THE victim's AS_ is dead." 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.
The announced prefix begins to compete with the real announcement (the victim's announcement), somewhere it will win and get into the routing table, somewhere it will lose and not get there (the victim's announcement will remain there). It depends on how many uplinks and how many IX's the attacker uses. When an attacker connects to an AS as a client, then inside it he (most often) will benefit from the victim due to a larger local-pref (unless the victim is a client of the same uplink, then the victim will benefit from the AS-PATH if he does not prepend), i.e. The attacker needs to connect to as many uplinks as possible with his AS-SET in order to maximize the effectiveness of his attack.
The attacker must also connect to the maximum number of IX's, because usually deadlocked ASS set the largest local-pref for IX's, and if the victim's prefix does not participate in IX, then he will lose the attacker's announcement in the routing tables of deadlocked AS.
In theory, this is a pretty strong attack, but fortunately, in practice, the following limitations will arise.
You need to register a legal entity, at least one, but in fact, most likely, they will be required in different countries.
It is necessary to conclude contracts with operators, IX's, and almost always make a connection payment with LIR/RIR.
Some operators still do not build prefix lists using AS-SET automatically, they need to write letters for this. An experienced administrator will suspect something if a well-known AS suddenly appears in the AS-SET of an unknown company.
After the attack, the equipment used (if it is located in any data center) is likely to be seized in the event of a criminal case.
Prefix lists for different operators/IX are updated at different times, so you will need to analyze who updates when, which is also not the easiest job.
Possible protection measures.
Theoretically, to protect yourself from such an attack, you need to have as many connections as possible with operators (better than client ones, because they have a higher local-pref) and IX. That is, to do the same thing that an attacker would do. Of course, this is extremely difficult to implement in practice and will require significant resources. This method is relevant only for services that provide information security services on a professional basis.
If you have a website, use a CAA record with the account assignment (if your SSL certificate provider supports it; letsencrypt supports it) (see RFC6844). In this case, the attacker will not be able to issue the certificate (unless he can change the CAA record).
Theoretically, the widespread implementation of BGPsec should eliminate such an attack, but its fate is not yet clear (in practice, it has not yet been applied or is very rarely used).
Implementation of an alternative AS_PATH verification (without BGPsec) (so far, this is a draft that solves the described problem in case of its widespread implementation).
Prohibiting the uncontrolled addition of someone else's AS to your AS-SET (without the permission of the AS owner) could reduce the possibility of such attacks in those regions where AS-SETS are used for filtering at the junctions. There is no such ban now.
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 partly No. 1 in the context of choosing a hoster with good connectivity. At the same time, you need to keep in mind possible attacks on the DNS service where you host your records (but this is a separate issue, and there are many materials on it).
Is it difficult to capture torproject.org .
The attacker needs to solve two tasks:
redirect traffic towards the target audience (target audience - who will receive the fake site);
generate a certificate.
Introductory notes:
$ 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 link to the account in the CAA record, which means that the problem can theoretically be solved by an attacker. Domain IP addresses torproject.org they belong to the fairly well-known Hezner hosting.
Let's say the attacker's target audience is the clients of some Russian operator. Hezner is not a client of Russian operators (but it has peer–to-peer relations with large ones, either directly or through IX's). In order for an attacker to redirect the CA traffic to himself, the easiest way is to become a client of this operator and simply win due to a higher local-pref. Everything is relatively simple and clear here.
To get a certificate in letsencrypt, you need the provider hosting letsencrypt to direct traffic to the attacker, and not to Hezner (AS24940). letsencrypt resolves to different addresses for American and European IP addresses, but let's see how difficult it will be to influence traffic from acme-v02.api.letsencrypt.org/2.19.125.202 went to the attacker's host. Here we come across the fact that letsencrypt is hosted in the Akamai CDN, which has very good connectivity around the world (it is present on most major platforms, has direct connections with a large number of major players). Akamai does not have a public LG, in principle, there is an API for clients that can be used to do traceroute/ping, but even without a public LG, you can look at the peering db to assess the scale of their presence. You can look at hezner in a similar way. It is easy to see that both AS have a presence on the same IX, hence it can be concluded that with a probability close to unity, the prefixes AS Hezner (AS24940) in the Akamai table (AS20940) are visible with AS_PATH 24940. This means that if an attacker tries to announce Hezner's prefixes through any IX, they will lose out on the real announcements from Hezner according to AS_PATH (since the attacker's AS will be in AS_PATH). A possible solution may be to organize "direct" peering between the attacker and Akamai (if Akamai agrees to this and if the local-pref is higher than at the junctions with IX).
To summarize, by adding someone else's AS to your AS-SET, you can cause significant degradation of the website. torproject.org (for a large number of clients, but not for all in the general case), but purchase an SSL certificate torproject.org in letsencrypt, it will most likely fail 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 AS between the hosting of the victim site and the certification authority and they are present in the AS_PATH, the risk of obtaining a certificate using the described method increases significantly.
Oleg Petukhov, lawyer in the field of international law and personal data protection, information security specialist security, protection of information and personal data.
Telegram channel: https://t.me/protectioninformation Telegram Group: https://t.me/informationprotection1 Website: https://legascom.ru Email: online@legascom.ru #informationprotection #informationsecurity