Le compromis de BGP.Exchange épargne les route servers mais expose les données de ses 510 réseaux membres
Le 12 septembre 2026, l’IXP virtuel BGP.Exchange a vu son site défiguré et son système d’e-mails détourné pour harceler ses membres ; l’opérateur assure qu’aucun route server n’a été touché. Vérifiez vos sessions de peering, changez vos identifiants et mesurez ce que l’incident dit de la séparation entre plan de gestion et plan de données.
12 septembre 2026. Le site de BGP.Exchange est défiguré. 17 septembre 2026. L’opérateur publie un premier bilan et annonce une reconstruction complète de son infrastructure. Environ 510 réseaux y échangent du trafic par tunnels. Pourquoi c’est important : un IXP virtuel a perdu son plan de gestion — site, e-mail, DNS, bureau d’enregistrement — pendant que ses route servers sont restés intacts. C’est l’inverse du scénario redouté, mais la confiance, elle, est déjà entamée.
Un IXP sans salle machine
BGP.Exchange se présente comme un Internet Exchange Point virtuel (VIXP) : une plateforme gratuite et mondiale qui permet à des réseaux de faire du peering sans jamais poser un câble dans une salle machine commune. Le raccordement se fait par des protocoles de tunnel — GRETAP, VxLAN ou ZeroTier — entre le routeur du membre et l’infrastructure de l’opérateur.
C’est une proposition qui a du sens pour les petits opérateurs, les hébergeurs de niche ou les passionnés qui veulent échanger du trafic avec leurs voisins sans financer une présence physique dans un datacenter. Le coût d’entrée est nul, la mise en route se compte en minutes. En contrepartie, la confiance devient la matière première du service : on confie à un tiers l’acheminement de ses annonces BGP, et on accepte qu’il porte nos préfixes sur sa table de routage.
Ce qui a été compromis
Le 12 septembre 2026, des membres signalent que le site affiche un message de défacement intitulé « Bitch Daniel », accusant la plateforme d’exploitation financière et de gaspillage de ressources. Dans le même temps, des e-mails partent du système d’envoi authentifié de l’opérateur : messages harcelants, paroles de chants nazis, injures en cantonais — le tout accompagné de données réelles de membres, comme des noms complets.
Un point retient l’attention des observateurs : un transfert de bureau d’enregistrement (registrar) aurait eu lieu, ce qui soulève la question d’une possible prise de contrôle du nom de domaine lui-même. Pendant l’incident, le peering a été perturbé, les tunnels VPN de certains membres ne fonctionnaient plus, et le portail de connexion était inaccessible.
Le tableau est celui d’une compromission complète du plan de gestion : le site, la messagerie, le DNS, potentiellement le domaine. Tout ce qui ne route pas du paquet, mais qui contrôle la plateforme, semble être passé sous contrôle de l’attaquant.
Ce qui n’a pas été compromis
Le 17 septembre 2026, l’opérateur publie un communiqué de sécurité au ton mesuré : « Notre enquête n’a trouvé aucune preuve qu’un route server de BGP.Exchange ait été accédé ou compromis durant cet incident. Cela vaut pour les route servers de toutes nos localisations dans le monde. »
C’est une distinction essentielle pour comprendre l’incident. Un IXP fonctionne sur deux plans séparés. Le plan de gestion — site, portail, facturation, messagerie, DNS — sert à administrer le service. Le plan de données, incarné par les route servers, est la machine qui reçoit les annonces BGP, les traite et les redistribue aux membres. Ce sont deux systèmes, deux jeux de privilèges, et ici deux destins différents.
Que les route servers aient été épargnés est une bonne nouvelle — la plus importante. Une compromission des route servers aurait permis à un attaquant d’injecter de fausses routes vers des centaines de réseaux, de détourner du trafic ou de créer des trous noirs. Rien de tel n’a été observé. Mais l’honnêteté oblige à ajouter un bémol : l’opérateur enquête encore, et l’absence de preuve n’est pas une preuve d’absence, surtout quand le plan de gestion a été aussi largement percé.
La confiance, la vraie victime
Le paradoxe de cet incident, c’est que le dommage le plus durable ne porte pas sur les paquets, mais sur la réputation. Un IXP vend de la neutralité et de la fiabilité : les membres lui confient leurs préfixes en échange d’un accès au reste du réseau. Quand la plateforme est défigurée et que des données de membres fuient dans des e-mails de harcèlement, c’est ce contrat implicite qui se fissure.
La fuite de données de membres est le point le plus sensible. Le chercheur Knut Michael Haugland a documenté l’incident en posant la question qui fâche : si un attaquant avait eu accès à la table des membres, qu’aurait-il pu faire d’autre ? La réponse dépend de ce que contenaient les comptes — et c’est précisément ce que l’opérateur n’a pas encore clarifié publiquement.
À l’échelle du secteur, cet incident rejoint une série de rappels récents sur la fragilité du plan de contrôle de l’Internet. Nous avons déjà couvert la protection RPKI/ROV et les quatre classes d’attaques BGP non validées. Le compromis de BGP.Exchange n’est pas une attaque sur le routage lui-même : c’est une attaque sur la couche de confiance qui entoure le routage.
Ce que doit faire un opérateur membre
La première action est de vérifier l’intégrité de vos sessions. Un membre de BGP.Exchange ne peut pas se contenter du communiqué rassurant : il doit examiner ses propres journaux pour détecter une annonce anormale ou une session ouverte à une heure inhabituelle.
# Vérifier les sessions BGP établies et leur durée sur un routeur Linux/BIRD
birdc show protocols | grep -E 'BGP|Established'
# Rechercher des annonces de préfixes inattendues dans les logs BGP
grep -iE 'unexpected|invalid|withdraw' /var/log/bird.log | tail -50Ensuite, tournez vos identifiants. Tout mot de passe ou jeton utilisé sur le portail de BGP.Exchange doit être considéré comme compromis et régénéré. Si le même mot de passe sert ailleurs, changez-le partout : les attaquants réutilisent les identifiants volés sur d’autres services.
Enfin, surveillez vos annonces pendant les prochaines semaines. Les hijacks de préfixes se détectent en croisant ce que vous annoncez et ce que voient les moniteurs de routage publics. Un outil comme BGP Toolkit ou un abonnement à un moniteur de RPKI suffit pour lever un doute en quelques minutes.
Verdict
Le compromis de BGP.Exchange est un cas d’école de séparation des plans : le plan de gestion a été percé de part en part, le plan de données est resté propre. Si vous êtes membre, ne paniquez pas, mais ne vous fiez pas au seul communiqué — vérifiez vos sessions, tournez vos identifiants et surveillez vos préfixes. Si vous exploitez un IXP, même virtuel, traitez votre portail, votre messagerie et votre registre de domaine comme des actifs aussi critiques que vos route servers : un attaquant qui tient votre e-mail tient la clé de la confiance de vos membres. La leçon vaut pour tout le secteur : on peut perdre un IXP sans jamais toucher à un seul paquet de routage.