Attaques sur BGP.
Ces violations peuvent résulter des attaques suivantes sur le protocole BGP.
BGP fonctionne sur la base du protocole TCP, en écoutant sur le port 179. Par conséquent, le protocole BGP est vulnérable aux attaques TCP dont nous avons parlé précédemment.
Attaque confidentiality violations (violation de la confidentialité). Comme mentionné précédemment, les données de routage BGP sont transmises en texte clair, ce qui permet d'intercepter facilement les informations (en effet, la confidentialité des données de routage n'est pas une exigence commune).
Attaque replay (lecture). BGP ne comprend pas de mesures pour empêcher la réutilisation des messages interceptés.
Attaque message insertion (insertion de messages). BGP n'inclut pas la protection contre l'insertion de messages. Toutefois, étant donné que BGP utilise le protocole de transport TCP, lorsque la connexion est terminée, l'insertion de messages par un hôte externe nécessitera une prédiction précise des numéros de séquence (une telle prédiction est possible, mais très difficile pour de bonnes implémentations TCP) ou une interception de session.
Attaque message deletion (suppression de messages). BGP n'inclut pas la protection contre la suppression des messages. Encore une fois, de telles attaques sont très difficiles pour les implémentations TCP de qualité, mais elles ne peuvent pas être complètement exclues.
Attaque message modification (modification des messages). BGP n'inclut pas la protection contre la modification des messages. Une modification syntaxiquement correcte sans modifier la taille des données TCP sera généralement imperceptible.
Attaque Man-in-The-middle (attaques impliquant un homme). BGP n'inclut aucune protection contre les attaques MITM. BGP n'utilise pas l'authentification des partenaires et de telles attaques deviennent un «jouet d'enfant».
Denial of service Attack. Bien que les fausses données de routage puissent elles-mêmes servir d'attaque DoS contre le système final qui tente de transmettre des données sur le réseau et le réseau dans son ensemble, certains types de fausses informations peuvent créer des attaques DoS contre le protocole BGP lui-même. Par exemple, l'annonce d'un grand nombre de routes plus spécifiques (préfixes plus longs) peut entraîner une augmentation du trafic BGP et de la taille des tables de routage, ce qui n'est pas acceptable pour le système.
Pour résumer ce qui est décrit dans cette section, il convient de noter que les risques sont dus à trois vulnérabilités principales:
l'absence d'un mécanisme intégré pour protéger l'intégrité et la pertinence des données, l'authentification des partenaires pour la transmission de messages;
il n'existe pas de mécanisme de vérification des autorisations AS pour les INFORMATIONS nlri (Network Layer Reachability Information);
il n'existe pas de mécanisme permettant d'assurer la fiabilité des attributs des itinéraires annoncés par AS.
Simple BGP hijacking.
Habituellement, BGP hijacking ressemble à ceci: AS, qui n'appartient pas à un préfixe, commence à l'annoncer (le préfixe de quelqu'un d'autre), les liens/festins l'acceptent, et il commence à se propager sur Internet. Ils l'acceptent pour la raison qu'il n'y a pas de filtrage des préfixes à la jonction (soit c'est une erreur de configuration, soit c'est prévu (car il est très difficile de construire un filtre de préfixe à la jonction avec de très grands opérateurs en raison de diverses raisons, pour cet article, ce n'est pas important)). L'un des exemples les plus célèbres de l'époque récente est lorsque Rostelecom (AS12389) a commencé à annoncer les préfixes Mastercard (AS26380), Visa et d'autres organisations financières (selon la version officielle, à la suite d'une défaillance du LOGICIEL). A quoi ressemblaient ces annonces, vous pouvez voir dans l'histoire bgplay (voir via le web, json (archive)), voici l'un d'eux sur l'un des collectionneurs RIPE (préfixe 216.119.216.0 / 24 appartient à Mastercard (AS26380)):
"source_id": "05-193.203.0.185",
"path": [
6939,
12389
],
"community": [],
"target_prefix": 216.119.216.0/24
Et voici à quoi ressemblait la présente annonce:
"source_id": "05-193.203.0.63",
"path": [
6720,
8447,
32787,
26380,
26380,
26380
],
"community": [
"1120:1"
],
"target_prefix": 216.119.216.0/24
Autrement dit, dans ce cas, Rostelecom a annoncé le préfixe directement à partir de son AS (le dernier AS dans AS-PATH – 12389). Les problèmes pourraient être évités si les aplinks et les pairs de Rostelecom filtraient les préfixes de Rostelecom en construisant des feuilles de préfixe par AS-SET et/ou en validant les préfixes par ROA RPKI. La construction de listes de préfixes entre les grands opérateurs n'est souvent pas faite, et RPKI n'a pas non plus mis en œuvre tout (mais il y a des progrès). Un tel hijacking peut théoriquement être commis par n'importe qui, mais seulement si le préfixe annoncé «fuit» via au moins un aplink/PIR. Habituellement, les grands opérateurs russes configurent des filtres de préfixe vers leurs clients, et donc les petits AS (petits/moyens opérateurs, certains hébergeurs et certaines entreprises) ne peuvent presque toujours pas commettre une telle attaque (mais encore une fois, tout dépend de la région / pays / opérateur spécifique).
Cependant, les attaquants trouvent toujours des endroits (aplinks) où le filtrage n'est pas configuré (en 2017, le leader du piratage était le Brésil) et effectuent une attaque / capture d'adresses IP (souvent de tels événements tombent dans les Actualités
pour plus d'efficacité, les attaques peuvent annoncer des préfixes plus spécifiques (avec un masque plus long) que l'original réel. Passons maintenant à l'option d'attaque, où ni la validation par ROA RPKI, ni les feuilles de préfixe construites par AS-SET ne sont sauvées.
BGP hijacking avec l'ajout de la victime AS à votre AS-SET.
Considérons le scénario suivant.
L'attaquant obtient l'AS et les adresses IP (en fait, techniquement, il n'a pas besoin d'adresses IP, plutôt, ils ne sont que pour ne pas poser de questions).
L'attaquant se connecte à divers opérateurs majeurs et IX'am (minimum - au moins un opérateur ou IX), indiquant comme source de données sur les préfixes annoncés, non seulement son AS, mais son AS-SET (c'est une pratique normale pour l'interaction inter-opérateurs (y compris dans la relation client-AppLink) ou pour l'inclusion sur IX'ah)). Dans le cas normal, as-SET est spécifié, pas seulement AS, quand il est implicite que le client n'est pas bloqué et qu'il a lui-même (ou aura) des clients avec bgp et ses propres réseaux.
Après un certain temps, l'attaquant ajoute l'AS de la victime à son AS-SET et commence à annoncer son préfixe via lui-même, c'est-à-dire que le as-PATH annoncé ressemble à ceci: «As_de la victime as_de la Victime». Du point de vue des feuilles de préfixe construites automatiquement et du point de vue de RPKI, il s'agit d'une annonce parfaitement valide, de sorte que les deux mécanismes de protection ne fonctionneront pas ici.
Le préfixe proanonsirovannogo commence à rivaliser avec l'annonce réelle (annonce de la victime), quelque part il va gagner et tomber dans la table de routage, quelque part il va perdre et ne pas tomber (il y aura une annonce de la victime). Cela dépend du nombre de liens et du nombre d'IX's utilisés par l'attaquant. Lorsqu'un attaquant se connecte à un AS en tant que client, alors à l'intérieur de celui-ci, il gagne (le plus souvent) la victime au détriment d'un plus grand local-pref (à moins que la victime ne soit un client du même apllink, alors sur AS-PATH la victime gagne si elle ne fait pas de pref), c'est-à-dire un attaquant doit se connecter au plus grand nombre de liens vers son AS-SET afin de maximiser l'efficacité de son attaque.
En outre, l'attaquant doit se connecter au nombre maximum d'IX's, car généralement les as sans issue exposent le plus grand local-pref sur IX's et si le préfixe de la victime ne participe pas à IX, il perdra l'annonce de l'attaquant dans les tables de routage des as sans issue.
En théorie, c'est une attaque assez forte, mais heureusement, dans la pratique, les limites suivantes se présenteront.
Il est nécessaire d'émettre une entité juridique, au moins un, et en fait, très probablement, il sera nécessaire dans différents pays.
Il est nécessaire de conclure des contrats avec les opérateurs, IX's, presque toujours payer pour la connexion, avec LIR/RIR.
Certains opérateurs ne construisent toujours pas automatiquement les feuilles de préfixe AS-SET, ils doivent écrire des lettres pour cela. Un administrateur expérimenté soupçonnera quelque chose si une ENTREPRISE inconnue apparaît soudainement dans AS-SET.
Après l'attaque, l'équipement utilisé (s'il est placé dans un centre de données) sera probablement saisi en cas d'ouverture d'une affaire pénale.
Les listes de préfixes de différents opérateurs / IX sont mises à jour à des moments différents, il est donc nécessaire d'analyser qui met à jour quand, ce n'est pas non plus le travail le plus simple.
Mesures de protection possibles.
Théoriquement, pour se protéger contre une telle attaque, vous devez avoir autant de connexions que possible avec les opérateurs (mieux que les clients, car ils sont plus élevés local-pref) et IX'S. C'est-à-dire faire la même chose qu'un attaquant ferait. Bien sûr, dans la pratique, cela est extrêmement difficile à mettre en œuvre et nécessitera des ressources considérables. Cette méthode est pertinente, sauf pour les services qui fournissent des services de sécurité de l'information sur une base professionnelle.
Si vous avez un site Web, utilisez un enregistrement CAA avec le travail account (si votre Fournisseur de certificat SSL le prend en charge; letsencrypt le prend en charge) (voir RFC6844). Dans ce cas, l'attaquant ne peut pas émettre de certificat (sauf s'il peut modifier l'enregistrement CAA).
En théorie, l'adoption généralisée de BGPsec devrait éliminer une telle attaque, mais son destin n'est pas encore clair (dans la pratique, il n'est pas encore utilisé ou très rarement utilisé).
Mise en œuvre de la vérification alternative AS_PATH (sans BGPsec) (jusqu'à présent, il s'agit d'un projet qui résout le problème décrit en cas de mise en œuvre généralisée).
Interdire l'ajout Incontrôlé d'un AS étranger à votre AS-SET (sans l'autorisation du propriétaire de l'AS) pourrait réduire la possibilité de telles attaques dans les régions où les AS-SET sont utilisés pour filtrer les jonctions. Maintenant, il n'y a pas une telle interdiction.
En fait, pour la plupart des lecteurs, le seul conseil qui leur est applicable est le n ° 2 (concernant l'utilisation de account dans un enregistrement CAA) et en partie le n ° 1 dans le contexte de la sélection d'un hébergeur avec une bonne connectivité. Dans ce cas, vous devez vous rappeler des attaques possibles sur le service DNS dans lequel vous hébergez vos enregistrements (mais c'est une question distincte, et il y a beaucoup de matériel).
Est-ce difficile à saisir torproject.org.
L'attaquant doit résoudre deux problèmes:
rediriger le trafic vers le public cible (CA-qui recevra le faux site);
générer un certificat.
D'introduction:
$ 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
Comme vous pouvez le voir, l'enregistrement CAA est, vous pouvez obtenir un certificat de letsencrypt, il n'y a pas de liaison au compte dans l'enregistrement CAA, ce qui signifie que la tâche est théoriquement résolue par un attaquant. Adresses IP du domaine torproject.org appartiennent à l'hébergement assez célèbre Hezner.
Disons que les CA de l'attaquant sont les clients d'un opérateur russe. Hezner n'est pas un client des opérateurs russes (mais a un peering avec les grands – directement ou via IX's). Pour qu'un attaquant redirige le trafic CA vers lui-même, il est plus facile de devenir un client de cet opérateur et de gagner simplement au détriment d'un local-pref plus élevé. Ici, tout est relativement simple et clair.
Pour obtenir un certificat dans letsencrypt, vous devez que le Fournisseur qui héberge letsencrypt dirige le trafic vers l'attaquant, et non vers Hezner (AS24940). letsencrypt résoudra différentes adresses pour les IP américaines et européennes, mais voyons à quel point il sera difficile d'affecter le trafic avec acme-v02.api.letsencrypt.org/2.19.125.202 je suis allé à l'hôte de l'attaquant. Ici, nous sommes confrontés au fait que letsencrypt est hébergé dans le CDN Akamai, qui a une très bonne connectivité dans le monde entier (présent sur la plupart des grands IX, a des connexions directes avec un grand nombre de grands joueurs). Akamai n'a pas de LG public, en principe, pour les clients il y a une API avec laquelle faire traceroute/ping, mais aussi un LG non public peut être regardé dans peering db pour évaluer l'ampleur de leur présence. De même, vous pouvez regarder hezner. Il n'est pas difficile de voir que les deux AS ont une présence sur les mêmes IX, d'où on peut conclure qu'avec une probabilité proche de l'unité, les préfixes AS Hezner (AS24940) dans la table Akamai (AS20940) sont visibles avec AS_PATH 24940. Cela signifie que si l'attaquant essaie de proanonsirovat à travers certains préfixes IX de Hezner'a, alors ils perdront par AS_PATH les annonces réelles de Hezner (parce que dans AS_PATH il y aura AS de l'attaquant). Une solution possible pourrait être d'organiser un peering «direct " entre l'attaquant et Akamai (si Akamai est d'accord et si en même temps il y aura local-pref plus élevé que sur les jonctions avec IX's).
Pour résumer, en ajoutant l'AS de quelqu'un d'autre à votre AS-SET, il est possible de provoquer une dégradation significative du site Web torproject.org (pour un grand nombre de clients, mais pas pour tout le monde en général), mais acheter un certificat SSL torproject.org letsencrypt échouera probablement en raison de la bonne connectivité entre l'original réel (Hezner) et le CDN utilisé par letsencrypt (Akamai). Toutefois, dans d'autres cas, lorsqu'il existe des AS transitoires entre l'hébergement du site victime et l'autorité de certification et qu'ils sont présents dans AS_PATH, le risque d'obtenir un certificat par LA méthode décrite est considérablement accru.
Petukhov Oleg, avocat en droit international et protection des données personnelles, spécialiste de l'information sécurité, protection de l'information et des données personnelles.
Telegram Channel: https://t.me/protecciondelainformacion
Groupe au Télégramme: https://t.me/securiteinformatique2
Site: https://legascom.ru
E-mail: online@legascom.ru
#sécuritéinformations #informationsécurité
