Résumé

  • L’annonce frauduleuse de 162.55.80.0/24 conservait AS24940 comme origine apparente et restait donc valide au regard de la ROA couvrante, malgré un chemin non autorisé.
  • Virtualizor a reconstitué la propagation à partir de 368 pairs RIPE RIS, mais les réponses servies par l’attaquant n’ont jamais atteint ses journaux ; le fournisseur ne peut donc pas établir la liste définitive des installations concernées.
  • La preuve manquante est un reçu local de consommation de mise à jour, liant version demandée, manifeste signé, empreinte du paquet, clé acceptée, décision de vérification et résultat d’installation ou de retour arrière.

Les rapports d’incident ont une faiblesse familière : le chiffre le plus spectaculaire finit par absorber tous les autres. Ici, ce chiffre est 368. Virtualizor affirme que chacun des 368 pairs de son échantillon RIPE RIS a transporté, à un moment ou à un autre, la route détournée. Cette donnée mesure l’étendue observable d’un chemin BGP. Elle ne dénombre ni les clients, ni les téléchargements, ni les exécutions du paquet malveillant.

Ce n’est pas une nuance de statisticien. C’est la frontière entre quatre registres qui n’observent pas le même événement. Les collecteurs BGP voient des chemins annoncés. L’autorité de certification voit une demande et un certificat. Le serveur de l’attaquant voit les requêtes qu’il intercepte. Enfin, chaque installation Virtualizor prend une décision locale : demander une version, accepter un fichier, l’exécuter, le refuser ou revenir en arrière. L’incident devient précisément dangereux parce que ces registres se séparent.

LACNIC a publié le 10 septembre 2026 une version espagnole de l’analyse de Kentik. Cette publication fournit l’actualité régionale et un exposé pédagogique utile ; elle ne fait pas de LACNIC l’opérateur de l’infrastructure compromise. La page précise d’ailleurs que les opinions exprimées appartiennent aux auteurs. Une lecture rigoureuse attribue donc chaque élément : LACNIC publie le cas, Kentik analyse le routage, Virtualizor décrit l’impact sur son produit.

Ce que démontre le routage

Vers 20 h 57 UTC le 28 août, le préfixe 162.55.80.0/24 est apparu avec une fin de chemin 6204 62390 24940. Le /24 était plus spécifique que le 162.55.0.0/16 normalement annoncé par Hetzner. Là où les deux annonces étaient reçues, la règle du préfixe le plus long dirigeait le trafic vers la nouvelle route.

L’astuce ne consistait pas à remplacer l’origine apparente. AS24940, celui de Hetzner, restait placé à droite du chemin. La ROA couvrante autorisait cette origine et permettait un préfixe allant jusqu’au /24. La validation d’origine pouvait donc produire le verdict « valide » sans authentifier les AS intermédiaires. Elle répondait correctement à une question trop étroite pour prouver l’intégrité du trajet.

La RFC 9319 décrit cette famille de détournement par sous-préfixe à origine forgée. Un adversaire peut conserver l’AS autorisé en bout de chemin et utiliser une portion plus spécifique couverte par une ROA non minimale. La recommandation en faveur de ROA minimales ferme cet espace inutilisé lorsque l’exploitation opérationnelle le permet. Elle ne transforme pas la validation d’origine en validation cryptographique de chaque voisinage BGP.

Il faut donc refuser de lire « RPKI Valid » comme un certificat de sûreté générale. Le résultat dit que le couple préfixe-origine et la longueur concordent avec une autorisation publiée. Il ne certifie pas que AS62390 était un fournisseur amont légitime, que le chemin déclaré était vrai, que le serveur atteint appartenait au bon opérateur ni que le logiciel reçu était authentique. Cette limitation n’invalide pas RPKI ; elle interdit simplement de lui attribuer une promesse qu’il ne formule pas.

Selon Virtualizor, l’épisode s’étend d’environ 20 h 57 UTC le 28 août à 6 h 10 UTC le 30 août, avec deux vagues actives séparées par une accalmie d’environ onze heures. La société signale près de 10 600 retraits de routes. Une reconstruction par intervalles de dix minutes est donc une série de coupes, pas un film continu. Les instantanés alignés sur les tables complètes produites toutes les huit heures sont plus solides ; entre ces repères, un fort battement peut conduire à sous-compter certains pairs visibles.

Le fameux 368 sur 368 porte lui aussi un qualificatif temporel : tous ont vu la route au moins une fois, non au même instant. Au sommet d’une vague active, environ 72 % de l’ensemble des 368 pairs la transportaient. Même ce pourcentage reste une approximation topologique. Il ne pondère pas les pairs selon leur trafic, leur clientèle ou le nombre de serveurs Virtualizor situés derrière eux. Sa valeur tient à cette discipline, pas à une extrapolation spectaculaire.

Le certificat a déplacé la confiance, pas rétabli la destination

Le serveur vers lequel le trafic était détourné a également pu répondre aux vérifications nécessaires à l’émission d’un certificat TLS. Virtualizor rapporte qu’un certificat techniquement valide couvrait plusieurs noms de la famille Softaculous, dont des points de distribution. Une connexion interceptée pouvait donc être chiffrée sans avertissement. TLS protégeait la session vers l’extrémité fournie par le routage ; il ne prouvait plus que cette extrémité était celle que l’éditeur avait prévue.

La corroboration d’émission à perspectives multiples, ou MPIC, vise justement à rendre cette attaque plus coûteuse. Une autorité de certification ne se contente plus d’une observation unique : elle sollicite plusieurs perspectives éloignées et exige leur accord. Les exigences actuelles du CA/Browser Forum imposent, depuis le 15 juin 2026 pour les contrôles concernés, au moins quatre perspectives distantes et une corroboration répartie sur au moins deux régions de registres Internet. Let’s Encrypt explique depuis plusieurs années que détourner le trajet de validation peut tromper une observation isolée.

L’émission du certificat ne prouve pas que MPIC serait inutile. L’analyse de Kentik est plus précise : une route plus spécifique, sans concurrente et largement propagée, peut présenter la même fausse extrémité à suffisamment de perspectives pour obtenir un quorum. La diversité révèle un mensonge local par désaccord. Lorsque le mensonge devient la vue commune, le quorum peut se tromper collectivement. Des ROA strictes, une surveillance des routes, des contrôles sensibles au chemin et des perspectives de certification réellement diverses restent complémentaires.

Le journal central disparaît là où l’attaque réussit

Virtualizor confirme qu’un paquet malveillant a été livré à un petit nombre d’installations. La société parle aussi d’une poignée de serveurs. Mais elle ne peut fournir de liste définitive, car les réponses malveillantes ont été servies depuis le système de l’attaquant et n’ont jamais atteint ses propres journaux.

Cette explication montre une propriété souvent oubliée des journaux web. Un journal d’origine enregistre les requêtes qui arrivent à cette origine. Pendant un détournement réussi, l’absence d’une requête ne signifie pas qu’elle n’a pas eu lieu. Elle peut signifier qu’elle a été répondue ailleurs. Le registre central devient incomplet au moment exact où l’adversaire prend la place du serveur légitime.

La procédure normale de mise à jour élargit cette zone aveugle. La documentation de Virtualizor indique qu’une installation vérifie par défaut les mises à jour toutes les vingt-quatre heures, sauf désactivation de l’automatisme. L’administrateur peut aussi lancer l’opération depuis le panneau ou en ligne de commande. Il faudrait donc distinguer les machines ayant vérifié pendant les heures actives, celles dont le trafic empruntait alors la route détournée, celles ayant terminé le téléchargement, celles ayant accepté le paquet et celles l’ayant exécuté. Le relevé BGP ne possède aucune de ces colonnes.

La société reconnaît en outre que ses clients de mise à jour ne vérifiaient pas encore cryptographiquement les paquets. Elle annonce la mise en place de la signature du code. C’est la première correction indispensable : un programme de mise à jour privilégié doit refuser un paquet dont le manifeste signé, l’empreinte, la version ou la clé autorisée ne concordent pas. La sécurité du transport ne doit pas être l’unique preuve d’authenticité du code.

La signature ne résout toutefois qu’une partie du problème. Elle peut empêcher un futur paquet non signé d’être exécuté. Elle ne dit pas automatiquement ce qui s’est passé sur chaque machine pendant l’incident. Même avec des signatures, il faut savoir quelle version a été demandée, quelle empreinte a été reçue, quelle clé a été acceptée, si la vérification a échoué, si l’installation a abouti, si le paquet a été mis en quarantaine ou si un retour arrière a été lancé.

Un reçu là où la décision est prise

Le contrôle manquant peut être modeste. À chaque tentative de mise à jour, la machine conserve un reçu infalsifiable ou au moins détectable en cas d’altération. Il enregistre le canal et la version demandée, l’heure, l’empreinte du manifeste signé, l’empreinte du paquet, la clé ou le seuil de clés accepté, le résultat de la vérification, puis l’issue : rejet, quarantaine, installation, échec ou retour arrière. Une révocation ou un avis ultérieur doit pouvoir pointer vers ce reçu.

Ce dispositif n’exige pas de publier la liste des clients. Le reçu peut rester chez l’opérateur, employer un identifiant pseudonyme de parc et ne révéler que la preuve minimale lors d’un incident. Le fournisseur peut proposer un accusé facultatif : il reçoit une preuve aveuglée ou pseudonyme et retourne un horodatage. Les grands opérateurs agrègent les résultats en interne ; les plus petits exportent un dossier de preuve vers le support. La protection de la vie privée devient une exigence d’architecture, non un prétexte à l’absence de trace.

Le reçu forme la jointure qui manque aujourd’hui. Le registre de publication du fournisseur dit : « ce manifeste, ce paquet et cette clé étaient autorisés ». Le registre local répond : « cette machine a demandé cette version, vérifié cette empreinte et pris cette décision ». Si l’attaquant contrôle la route et le site, mais pas la clé, le reçu conserve le rejet. Si une clé est révoquée, l’opérateur retrouve les machines qui l’ont acceptée. Si un défaut du vérificateur est découvert, l’empreinte du paquet borne la population à examiner.

Cette jointure interdit surtout de confondre cinq étapes. Un pair RIS qui transporte la route atteste une exposition possible. Une requête pendant une période détournée crée une occasion de livraison. Un téléchargement achevé atteste l’acquisition. Une installation réussie atteste l’exécution. Un indicateur de compromission atteste l’impact. Un rapport sérieux publie chaque compte avec son dénominateur et sa méthode, puis indique franchement les liaisons impossibles.

Une réponse déjà substantielle, mais sans registre local

La défense du fournisseur mérite d’être formulée avant la critique. Virtualizor a déclaré la livraison du paquet malveillant, publié un indicateur, demandé la rotation et la restriction des identifiants, recommandé la préservation des preuves, signalé le certificat pour révocation, reconstitué l’incident de routage et promis la signature des paquets. Kentik et LACNIC ont expliqué l’intérêt de ROA strictes et de la surveillance sans présenter la validation d’origine comme une vérité sur le chemin entier.

Le reproche n’est donc pas l’absence d’une certitude inaccessible. Il porte sur l’absence antérieure d’une obligation de laisser une trace portable au point de décision. Quand le serveur de l’attaquant répond, le journal du fournisseur sort de la transaction. La seule archive indépendante possible se trouve alors sur l’installation. Demander à tous les opérateurs de vérifier est raisonnable quand la population est inconnue ; c’est aussi le coût concret de l’absence de reçus.

Un prochain rapport devrait pouvoir juxtaposer trois registres. Le premier indique quelles perspectives ont vu quel chemin et à quelle heure. Le deuxième décrit les manifestes, paquets et clés que l’éditeur a autorisés. Le troisième consigne la décision de chaque client. Aucun ne remplace les autres. Ensemble, ils transforment une alerte générale en périmètre de réparation vérifiable.

Sources