Détournement BGP en ajoutant AS victime à AS-SET de l'attaquant

L'article est divisé en trois parties. Le premier contient des informations générales sur le piratage BGP et sa version traditionnelle. Pour ceux qui connaissent ce phénomène, il est recommandé de passer directement à la deuxième partie. La deuxième partie décrira la méthode d'annonce des préfixes étrangers en ajoutant un AS étranger à votre AS-SET. Dans la troisième partie, une évaluation sera faite de la complexité de l'utilisation de la méthode décrite dans la deuxième partie pour capturer l'adresse IP de la ressource torproject.org et émettre un certificat pour celle-ci. Il est supposé que le lecteur connaît les principes du BGPv4.

Détournement BGP simple

En bref, le détournement BGP capture les adresses IP de quelqu'un d'autre (aléatoire ou intentionnel).

Habituellement, le détournement BGP ressemble à ceci: un AS qui ne possède pas de préfixe commence à l'annoncer (préfixe de quelqu'un d'autre), les liaisons montantes / pairs l'acceptent et il commence à se répandre 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 conçu de la sorte (car il est très difficile de construire un filtre de préfixe à la jonction avec de très gros opérateurs pour diverses raisons, ce n'est pas important pour cet article) ) L'un des exemples les plus en vue des derniers temps où Rostelecom ( AS12389 ) a commencé à annoncer les préfixes Mastercard ( AS26380 ), Visa et certaines autres organisations financières (selon la version officielle , à la suite d'une panne de logiciel). Vous pouvez voir à quoi ressemblaient ces annonces dans l'historique bgplay ( affichage via le web , json ( archive )), en voici une sur l'un des collecteurs RIPE (le 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 l'annonce réelle:

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

C'est-à-dire dans ce cas, Rostelecom a annoncé un préfixe directement depuis son AS (le dernier AS dans AS-PATH est 12389). Des problèmes pourraient être évités si les liaisons montantes et les fêtes des préfixes filtrés par Rostelecom de Rostelecom en construisant des listes de préfixes selon AS-SET et / ou en validant les préfixes selon ROA RPKI . La construction de listes de préfixes entre les grands opérateurs n'est souvent pas effectuée, et tous n'ont pas implémenté RPKI (mais il y a des progrès ). Un tel détournement, en théorie, peut être fait par n'importe qui, mais seulement si le préfixe annoncé "fuit" à travers au moins une liaison montante / fête. Habituellement, les grands opérateurs russes configurent des filtres de préfixe vers leurs clients et, par conséquent, les petits AS (petits / moyens opérateurs, certains hébergeurs et certaines entreprises), presque toujours, ne peuvent pas effectuer 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 (liaisons montantes) où le filtrage n'est pas configuré (en 2017, le Brésil était le leader du détournement ) et mènent une attaque en saisissant les adresses IP (souvent, de tels événements tombent dans les fils de nouvelles), pour une attaque plus efficace, annoncer des préfixes plus spécifiques (avec un masque plus long) qu'un véritable créateur. Passons maintenant à la version d'attaque, où ni la validation ROA RPKI ni les listes de préfixes AS-SET ne sont enregistrées.

Détournement BGP avec l'ajout d'une victime AS dans son AS-SET

Considérez le scénario suivant:

1. Un attaquant obtient des adresses AS et IP (en fait, techniquement, il n'a pas besoin d'adresses IP, elles sont plus susceptibles de ne pas poser de questions).
2. Un attaquant se connecte à divers grands opérateurs et IXs (au moins un opérateur ou IX), indiquant non seulement son AS, mais son AS-SET comme source de données sur les préfixes annoncés (c'est une pratique normale pour l'interaction inter-opérateurs (y compris y compris dans une relation client-liaison montante) ou à inclure sur IX-ah)). Dans le cas normal, AS-SET est spécifié, et pas seulement AS, quand on suppose que le client n'est pas une impasse, mais qu'il a lui-même (ou aura) des clients avec bgp et leurs propres réseaux.
3. Après un certain temps, l'attaquant ajoute l'AS de la victime à son AS-SET et commence à annoncer son préfixe par lui-même, c'est-à-dire L'AS-PATH annoncé ressemble à ceci: "AS_ attaquant AS_ victimes". Du point de vue des listes de préfixes construites automatiquement et du point de vue de RPKI, c'est une annonce tout à fait valable, donc les deux mécanismes de protection ne fonctionneront pas ici.
4. Le préfixe annoncé commence à rivaliser avec l'annonce réelle (l'annonce de la victime), quelque part où il gagne et entre dans la table de routage, quelque part où il perd et ne gagne pas (l'annonce de la victime restera là). Cela dépend du nombre de liaisons montantes et du nombre d'IX utilisés par un attaquant. Lorsqu'un attaquant se connecte à un AS en tant que client, à l'intérieur (le plus souvent), il gagnera la victime en raison d'une préférence locale plus grande (si la victime n'est pas un client de la même liaison montante, alors la victime gagnera par AS-PATH s'il ne le fait pas). pré-ajouter), c'est-à-dire un attaquant doit se connecter à autant de liaisons montantes que possible avec son AS-SET afin de maximiser l'efficacité de son attaque.
   De plus, l'attaquant doit se connecter au nombre maximum de IXs, comme Habituellement, les AS de blocage définissent le préfixe local le plus élevé sur IX et si le préfixe victime n'est pas impliqué dans IX, il perdra l'annonce de l'attaquant dans les tables de routage des AS de blocage.

En théorie, il s'agit d'une attaque assez forte, mais heureusement, dans la pratique, les limitations suivantes se présenteront:

1. Vous devez créer une entité juridique, au moins une, mais en fait, elle sera probablement requise dans différents pays.
2. Il est nécessaire de conclure des accords avec les opérateurs, les IX, font presque toujours des frais de connexion, avec le LIR / RIR.
3. Certains opérateurs ne construisent toujours pas de listes de préfixes AS-SET automatiquement, ils doivent écrire des lettres pour cela. Un administrateur expérimenté soupçonnera quelque chose si l'AS-ka d'une entreprise bien connue apparaît soudainement dans l'AS-SET d'une entreprise inconnue.
4. Après l'attaque, l'équipement utilisé (s'il se trouve dans une sorte de centre de données) sera très probablement saisi en cas d'ouverture d'une affaire pénale.
5. Les listes de préfixes pour différents opérateurs / IX sont mises à jour à différents moments, vous devrez donc analyser qui met à jour lorsque ce n'est pas non plus la tâche la plus simple.

Mesures de protection possibles:

1. Théoriquement, pour se défendre contre une telle attaque, vous devez avoir autant d'interfaces que possible avec les opérateurs (mieux, les clients, car ils ont une préférence locale plus élevée) et des IX. C'est-à-dire faire la même chose qu'un attaquant fera. Bien sûr, dans la pratique, cela est extrêmement difficile à mettre en œuvre et nécessitera des ressources importantes. Cette méthode n'est pertinente que pour les services qui fournissent des services de sécurité de l'information à titre professionnel.
2. Si vous avez un site Web, utilisez un enregistrement CAA avec la tâche de compte (si votre fournisseur de certificat SSL le prend en charge. Letsencrypt le prend en charge) (voir RFC6844 ). Dans ce cas, l'attaquant ne pourra pas émettre de certificat (sauf s'il peut modifier l'enregistrement CAA)
3. Théoriquement, la mise en œuvre généralisée de BGPsec devrait éliminer une telle attaque, mais son sort n'est pas encore clair (en pratique, il n'est pas encore appliqué ou très rarement).
4. Implémentation de la vérification alternative AS_PATH (sans BGPsec) (jusqu'à présent, c'est un brouillon qui résout le problème décrit en cas d'implémentation généralisée).
5. L'interdiction de 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 mener de telles attaques dans les régions où des AS-SET sont utilisés pour filtrer les joints. Maintenant, il n'y a pas une telle interdiction.

En fait, pour la plupart des lecteurs, le seul conseil qui s'applique à eux est le n ° 2 (concernant l'utilisation du compte dans un enregistrement CAA) et partiellement n ° 1 dans le contexte du choix d'un hôte avec une bonne connectivité. Dans le même temps, vous devez vous rappeler des attaques possibles contre le service DNS dans lequel vous hébergez vos enregistrements (mais il s'agit d'un problème distinct et il y a beaucoup de documents)

Est-il difficile de capturer torproject.org

Un attaquant doit résoudre deux problèmes:

• Rediriger le trafic vers le public cible (public cible - qui recevra le faux site)
• Générer un certificat

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, il existe un enregistrement CAA, vous pouvez obtenir un certificat de letsencrypt, il n'y a pas de liaison au compte dans l'enregistrement CAA, ce qui signifie que le problème est théoriquement résolu par l'attaquant. Les adresses IP de torproject.org sont la propriété du célèbre hébergeur Hezner.

Supposons que le public cible d'un attaquant soit les clients d'un opérateur russe. Hezner n'est pas un client des opérateurs russes (mais a le peering avec les grands - directement ou via des IXs). Le moyen le plus simple pour un attaquant de rediriger le trafic CA vers lui-même est de devenir client de cet opérateur et de simplement gagner aux dépens d'un préfet local plus élevé. Tout ici est particulièrement simple et clair.

Pour obtenir un certificat dans letsencrypt, vous avez besoin du fournisseur sur lequel letsencrypt héberge pour diriger le trafic vers l'attaquant, et non vers Hezner (AS24940). letsencrypt se résout à différentes adresses pour l'IP américaine et européenne, mais voyons à quel point il sera difficile d'influencer le trafic de acme-v02.api.letsencrypt.org/2.19.125.202 vers l'hôte de l'attaquant. Ici, nous sommes confrontés au fait que letsencrypt est hébergé sur Akamai CDN, qui a une très bonne connectivité dans le monde (il est présent sur la plupart des IXs majeurs, a des liens directs avec un grand nombre de grands joueurs). Akamai n'a pas de LG public, en principe, il existe une API pour les clients avec laquelle vous pouvez faire du traceroute / ping, mais même sans LG public, vous pouvez jeter un œil au peering db pour évaluer l'ampleur de leur présence. De même, vous pouvez regarder hezner . Il est facile de voir que les deux AS ont la présence des mêmes IX, d'où nous pouvons 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 un attaquant S'il essaie d'annoncer les préfixes de Hezner via un IX, ils perdront selon AS_PATH les vraies annonces de Hezner (puisque AS_PATH contiendra l'AS de l'attaquant). Une solution possible serait d'organiser un peering «direct» entre l'attaquant et Akamai (si Akamai est d'accord avec cela et si sa préférence locale est supérieure à celle des jonctions avec les IX).

Pour résumer, en ajoutant l'AS de quelqu'un d'autre à votre AS-SET, vous pouvez provoquer une dégradation importante du site torproject.org (pour un grand nombre de clients, mais pas pour tout le monde dans le cas général), mais obtenez le certificat SSL torproject.org dans letsencrypt, très probablement, cela ne fonctionnera pas en raison de la bonne connectivité entre le véritable créateur (Hezner) et le CDN utilisé par letsencrypt (Akamai). Cependant, dans d'autres cas, lorsqu'il existe des AS de transit 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 en utilisant la méthode décrite est considérablement accru.