Tout va très mal ou un nouveau type d'interception de trafic

Le 13 mars, un projet de groupe de travail RIPE sur la lutte contre les abus a reçu une proposition d’envisager l'attaque par BGP hijacking (hjjack) comme une violation de la politique RIPE. Si la proposition est adoptée, le fournisseur d'accès Internet victime d'un détournement de trafic aurait la possibilité d'envoyer une demande spéciale pour exposer l'attaquant. Si le groupe d'experts rassemble suffisamment de preuves, un LIR à l'origine du BGP hijack serait considéré comme un contrevenant et pourrait perdre son statut de LIR. Il y a également eu des arguments contre cela. modifications.

Dans cette publication, nous souhaitons montrer un exemple d'attaque, où non seulement le véritable agresseur était en question, mais aussi toute la liste des préfixes touchés. De plus, cette attaque soulève de nouveau des questions sur les motifs de futurs détournements de trafic de ce type.

Au cours des deux dernières années, la presse a couvert les BGP hijacks principalement sous forme de conflits MOAS (Multiple Origin Autonomous System). Le MOAS est un cas particulier où deux systèmes autonomes distincts annoncent des préfixes conflictuels avec les numéros ASN appropriés dans l'AS_PATH (le premier ASN dans l'AS_PATH, ci-après — origin ASN). Cependant, nous pouvons citer au moins 3 types supplémentaires de détournement de trafic, permettant à l'attaquant de manipuler l'attribut AS_PATH à différentes fins, y compris pour contourner les méthodes modernes de filtrage et de surveillance. Un type d'attaque connu Pilosova-Kapela est le dernier type de ce détournement, mais pas le moins significatif. Il est tout à fait possible que nous ayons observé ce type d'attaque au cours des dernières semaines. Cet événement a une portée explicative et des conséquences assez graves.

Ceux qui recherchent une version TL;DR peuvent faire défiler jusqu'à la sous-titre « L'attaque parfaite ».

Contexte réseau

(pour que vous compreniez mieux les processus impliqués dans cet incident)

Si vous souhaitez envoyer un paquet et que vous avez plusieurs préfixes dans le tableau de routage contenant l'adresse IP de destination, vous utiliserez le trajet pour le préfixe de la longueur maximale. S'il existe plusieurs itinéraires différents pour un même préfixe dans le tableau de routage, vous choisirez le meilleur (selon le mécanisme de sélection du meilleur chemin).

Les approches existantes en matière de filtrage et de surveillance tentent d'analyser les routes et de prendre des décisions en examinant l'attribut AS_PATH. Le routeur peut modifier cet attribut à n'importe quelle valeur lors de l'annonce. Il peut suffire d'ajouter l'ASN du propriétaire au début de l'AS_PATH (comme ASN d'origine) pour contourner les mécanismes de vérification de source actuels. De plus, s'il existe une route depuis l'ASN ciblé jusqu'à vous, il est possible d'extraire et d'utiliser l'AS_PATH de cette route dans d'autres annonces. Toute vérification de validité de l'AS_PATH uniquement pour vos annonces fabriquées sera finalement réussie.

Il existe également plusieurs autres limitations dignes de mention. Tout d'abord, en cas de filtrage de préfixes par un fournisseur supérieur, votre route peut toujours être filtrée (même avec un AS_PATH correct) si le préfixe n'appartient pas à votre cône client, réglé chez l'upstream. Deuxièmement, un AS_PATH valide peut devenir invalide si la route créée est annoncée dans des directions incorrectes et enfreint ainsi la politique de routage. Enfin, toute route avec un préfixe enfreignant la longueur ROA peut être considérée comme invalide.

Incident

Il y a quelques semaines, nous avons reçu une plainte d'un utilisateur. Nous avons vu des routes avec son ASN d'origine et des préfixes /25, alors que l'utilisateur affirmait qu'il ne les avait pas annoncés.

TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.7.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.18.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.0/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.163.226.128/25|265466 262761 263444 22356 3491 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.0/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
TABLE_DUMP2|1554076803|B|xxx|265466|78.164.7.128/25|265466 262761 263444 6762 2914 9121|INCOMPLETE|xxx|0|0||NAG||
Exemples d'annonces au début d'avril 2019

NTT sur la route pour le préfixe /25 la rend particulièrement suspecte. Pendant l'incident, NTT ne savait rien de cette route. Donc oui, un certain opérateur crée un AS_PATH entier pour ces préfixes ! La vérification sur d'autres routeurs permet de mettre en évidence un ASN particulier : AS263444. En examinant d'autres routes avec ce système autonome, nous avons rencontré la situation suivante :

TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.0/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.23.143.128/25|265466 262761 263444 22356 6762 9498 9730 45528|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.24.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.0.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.26.128.0/17|265466 262761 263444 6762 4837|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.96.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.64.112.0/20|265466 262761 263444 6762 3491 4760|IGP|xxx|0|0||NAG||
Essayez de deviner ce qui ne va pas ici

Il semble que quelqu'un ait pris le préfixe d'une route, l'ait divisé en deux parties et annoncé une route avec le même AS_PATH pour ces deux préfixes.

TABLE_DUMP2|1554076800|B|xxx|263444|1.6.36.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|263444|1.6.38.0/23|263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.36.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|61775|1.6.38.0/23|61775 262761 263444 52320 9583|IGP|xxx|0|0|32:12595 52320:21311 65444:20000|NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.36.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|265466|1.6.38.0/23|265466 262761 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.36.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
TABLE_DUMP2|1554076800|B|xxx|28172|1.6.38.0/23|28172 52531 263444 52320 9583|IGP|xxx|0|0||NAG||
Exemples de routes pour l'une des paires de préfixes divisés

Plusieurs questions se posent. Quelqu'un a-t-il déjà essayé un tel type d'interception en pratique ? Quelqu'un a-t-il accepté ces routes ? Quels préfixes ont été touchés ?

C'est ici que commence notre série d'échecs et un autre tour de déceptions concernant l'état actuel de la santé d'Internet.

Le chemin des échecs

Tout d'abord, comment pouvons-nous déterminer quels routeurs ont accepté de telles routes interceptées et quel trafic peut déjà être redirigé aujourd'hui ? Nous avons pensé commencer par les préfixes /25, car ils « ne peuvent tout simplement pas avoir de distribution mondiale ». Comme vous pouvez le deviner, nous avions clairement tort. Cette métrique s'est révélée trop bruitée et les routes avec de tels préfixes peuvent apparaître même chez des opérateurs de niveau 1. Par exemple, NTT a environ 50 de ces préfixes qu'il distribue à ses propres clients. D'autre part, cette métrique est mauvaise car ces préfixes peuvent être filtrés si l'opérateur applique le filtrage des petits préfixes, dans toutes les directions. Par conséquent, cette méthode ne convient pas pour trouver tous les opérateurs dont le trafic a été redirigé à la suite d'un tel incident.

Une autre bonne idée nous a semblé d'examiner POV. En particulier, les routes enfreignant la règle maxLength du ROA correspondant. Ainsi, nous pourrions trouver le nombre de différents ASN d'origine avec un statut Invalid, qui étaient visibles par ce AS. Cependant, il y a un « petit » problème. La valeur moyenne (médiane et mode) de ce nombre (nombre de différents ASN d'origine) est d'environ 150 et, même si nous filtrons les petits préfixes, cela restera au-dessus de 70. Cette situation s'explique assez simplement : il n'y a que quelques opérateurs qui appliquent déjà des filtres ROA avec la politique « rejeter les routes Invalid » aux points d'entrée, donc, où que dans le monde réel une route enfreignante le ROA apparaisse, elle peut se propager dans toutes les directions.

Les deux dernières approches permettent de trouver les opérateurs ayant vu notre incident (car il était suffisamment important), mais dans l'ensemble, elles ne sont pas applicables. Très bien, mais pouvons-nous trouver l'attaquant ? Quelles sont les caractéristiques générales de cette manipulation AS_PATH ? Il y a quelques hypothèses de base :

• Le préfixe n'a jamais été vu auparavant ;
• L'ASN d'origine (rappel : le premier ASN dans AS_PATH) est valide ;
• Le dernier ASN dans AS_PATH est l'ASN de l'attaquant (au cas où son voisin vérifierait l'ASN du voisin sur toutes les routes entrantes);
• L'attaque provient d'un seul fournisseur.

Si toutes les hypothèses sont correctes, tous les itinéraires incorrects présenteront l'ASN de l'attaquant (à l'exception de l'ASN d'origine), et ceci est donc un point « critique ». Parmi les véritables pirates, il y avait aussi AS263444, bien qu'il y en ait d'autres. Même lorsque nous avons écarté les itinéraires de l'incident de l'analyse. Pourquoi ? Un point critique peut rester critique même pour des itinéraires corrects. Il peut résulter d'une mauvaise connectivité dans une région ou des limitations de notre propre visibilité.

En conséquence : il existe un moyen de détecter l'attaquant, mais seulement si toutes les conditions précitées sont remplies et seulement lorsque l'interception est suffisamment grande pour passer les seuils de surveillance. Si certains de ces facteurs ne sont pas respectés, pouvons-nous identifier les préfixes touchés par une telle interception ? Pour certains opérateurs — oui.

Lorsque l'attaquant crée un itinéraire plus spécifique, ce préfixe n'est pas annoncé par le véritable propriétaire. Si vous disposez d'une liste dynamique de tous ses préfixes, il devient possible de comparer et de trouver les itinéraires plus spécifiques déformés. Nous recueillons cette liste de préfixes grâce à nos sessions BGP, car nous recevons non seulement la liste complète des itinéraires que l'opérateur voit actuellement, mais aussi la liste de tous les préfixes qu'il souhaite annoncer au monde. Malheureusement, il existe actuellement plusieurs dizaines d'utilisateurs de Radar qui ne réalisent pas cette dernière partie correctement. Nous les informerons sous peu et tenterons de résoudre ce problème. Tous les autres peuvent rejoindre notre système de surveillance immédiatement.

Pour revenir à l'incident initial, à la fois l'attaquant et la portée de la diffusion ont été identifiés par notre recherche de points critiques. Étonnamment, AS263444 n'envoyait pas de routes falsifiées à tous ses clients. Bien qu'il y ait un autre point plus étrange.

BGP4MP|1554905421|A|xxx|263444|178.248.236.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
BGP4MP|1554905421|A|xxx|263444|178.248.237.0/24|263444 6762 197068|IGP|xxx|0|0|13106:12832 22356:6453 65444:20000|NAG||
Un exemple récent de tentative d'interception de notre espace d'adresses

Lorsque des more specific ont été créés pour nos préfixes, un AS_PATH spécialement conçu a été utilisé. Cependant, cet AS_PATH ne pouvait pas être tiré d'aucun de nos itinéraires précédents. Nous n'avons même pas de lien avec AS6762. Examinons d'autres itinéraires dans l'incident : certains d'entre eux avaient un AS_PATH réel, utilisé auparavant, tandis que d'autres n'en avaient pas, même s'il semblait authentique. Un changement supplémentaire d'AS_PATH n'a pas de sens pratique, car de toute façon, le trafic sera redirigé vers le malfaiteur, mais les itinéraires avec un « mauvais » AS_PATH peuvent être filtrés par ASPA ou tout autre mécanisme de vérification. Ici, nous nous sommes interrogés sur la motivation du pirate. Nous manquons actuellement de données pour affirmer que cet incident était une attaque planifiée. Néanmoins, c'est possible. Essayons d'imaginer une situation qui, bien que hypothétique, pourrait être tout à fait réelle.

Attaque idéale

Qu'avons-nous ? Supposons que vous soyez un fournisseur de transit, diffusant des itinéraires pour vos clients. Si vos clients ont une présence multiple (multihome), vous n'obtiendrez qu'une partie de leur trafic. Mais plus le trafic est important, plus vos revenus augmentent. Ainsi, si vous commencez à annoncer des préfixes de sous-réseaux de ces mêmes itinéraires avec le même AS_PATH, vous obtiendrez le reste de leur trafic. En conséquence, le reste de l'argent.

Le ROA aidera-t-il ici ? Peut-être, si vous décidez de renoncer complètement à l'utilisation maxLength. De plus, il est fortement déconseillé d'avoir des enregistrements ROA avec des préfixes qui se chevauchent. Pour certains opérateurs, de telles restrictions sont inacceptables.

En considérant d'autres mécanismes de sécurité de routage, dans ce cas, l'ASPA ne sera pas non plus utile (car il utilise un AS_PATH provenant d'un itinéraire autorisé). BGPSec reste toujours une option sous-optimale en raison du faible taux d'adoption et de la possibilité persistante d'attaques de downgrade.

Ainsi, nous avons un bénéfice clair pour l'attaquant et un manque de sécurité. Un excellent mélange !

Que faut-il faire ?

Une étape évidente et radicale consiste à revoir votre politique de routage actuelle. Divisez votre espace d'adresses en morceaux les plus petits possibles (sans chevauchements) que vous souhaitez annoncer. Signez une ROA uniquement pour eux, sans utiliser le paramètre maxLength. Dans ce cas, le POV actuel peut vous protéger contre une telle attaque. Cependant, encore une fois, cette approche peut ne pas être raisonnable pour certains opérateurs en raison de l'utilisation exceptionnelle de routes plus spécifiques. Tous les problèmes de l'état actuel des ROA et des objets de route seront décrits dans l'un de nos futurs documents.

En outre, il est possible d'essayer de surveiller de telles interférences. Pour cela, nous avons besoin d'informations fiables sur vos préfixes. Ainsi, si vous établissez une session BGP avec notre collecteur et nous transmettez des informations sur votre visibilité Internet, nous pouvons identifier l'étendue de la propagation et détecter d'autres incidents. Pour ceux qui ne sont pas encore connectés à notre système de surveillance, une liste de routes avec vos préfixes sera suffisante au départ. Si vous avez déjà une session en place avec nous, veuillez vérifier que tous vos routes ont été envoyées. Malheureusement, cela mérite d'être rappelé, car certains opérateurs oublient un ou deux préfixes, ce qui perturbe nos méthodes de recherche. Si tout est bien fait, nous disposerons de données fiables sur vos préfixes, ce qui permettra à l'avenir de détecter automatiquement ce type (et d'autres) d'interférences de trafic pour votre espace d'adresses.

Si vous apprenez en temps réel qu'une telle interférence de votre trafic a eu lieu, vous pouvez essayer de réagir par vous-même. La première approche consiste à annoncer les routes avec ces préfixes plus spécifiques vous-même. En cas de nouvelle attaque contre ces préfixes, répétez le processus.

La deuxième approche consiste à punir l'agresseur et ceux pour qui il est un point critique (pour les bonnes routes) en coupant l'accès à vos routes vers l'agresseur. Cela peut être réalisé en ajoutant l'ASN de l'agresseur dans le AS_PATH de vos anciennes routes et, ainsi, les forcer à éviter cet AS, en utilisant le mécanisme de détection de boucles intégré dans BGP. pour votre propre bien.

Source : habr.com