333 relais de sortie Tor ont dérouté le SSH et favorisé le courrier en clair

Début octobre, environ un relais de sortie Tor sur dix a été discrètement transformé en piège à mots de passe SSH. Un chercheur publiant sous le pseudonyme kaba a scanné le 2 octobre l'ensemble des quelque 3 000 sorties de Tor et en a trouvé 333 qui redirigeaient le SSH vers les mêmes 12 serveurs d'interception. Rien n'a failli dans la cryptographie de Tor. Les attaquants ont pris le contrôle des hôtes Linux sous-jacents aux relais et réécrit un fichier texte.

01Comment les relais ont été détournés

Un relais de sortie n'achemine le trafic que vers les ports autorisés par sa politique de sortie, et cette politique se trouve dans le fichier de configuration torrc du relais. À partir du 1er octobre, les attaquants ont réécrit ces politiques pour ouvrir le port 22. Cela a activé le SSH sur 342 relais qui le bloquaient et transformé 24 relais hors sortie en sorties.

La seule voie d'entrée entièrement documentée passe par l'infrastructure d'un opérateur de relais, et non par les systèmes du Tor Project. Le résumé d'Ars Technica parle d'un « serveur de gestion Tor », mais le post-mortem décrit les choses autrement. Il s'agissait du VPS Contabo de l'opérateur, qui servait de passerelle WireGuard, d'hôte de rebond SSH et de pont obfs4. Une seconde machine, Switzerland2, était un VPS FranTech qui hébergeait deux des relais de sortie de l'opérateur. L'attaquant a utilisé le mot de passe de l'opérateur, qui a fonctionné du premier coup, et il disposait des droits root cinq minutes plus tard. Cela concorde avec le récit d'Ars sur la réutilisation d'un mot de passe.

Ebury 1.8.3 a été installé sur ce serveur. Environ une heure plus tard, Switzerland2 a accepté une connexion avec une clé RSA absente de tous ses fichiers authorized_keys, et Ebury y a été installé une seconde après. L'opérateur indique que la façon dont cette clé a été acceptée reste une question ouverte. Marc-Etienne Léveillé, qui suit Ebury depuis 13 ans, a suggéré sur la liste de diffusion qu'Ebury était peut-être présent plus tôt et qu'il aurait été mis à jour le 30 septembre. Il a aussi évoqué l'hypothèse d'un hébergeur compromis.

Le post-mortem de l'opérateur montre comment l'attaquant a réécrit la politique sur Switzerland2. La liste d'acceptation de 60 plages de ports, générée par ansible, a été supprimée. Cinq lignes de rejet pour les ports 25, 465, 587, 993 et 995 ont été ajoutées après « # end of torrc ». Les deux relais de Switzerland2 ont publié le résultat à 09:34:04 le 2 octobre.

La manière dont les autres relais sont tombés n'est pas élucidée. Ars note que les enquêteurs n'ont pas établi comment les 333 serveurs sous-jacents ont été pris. Un indice pointe toutefois vers l'hébergement : 71 des 101 relais tiers chez FranTech Solutions ont basculé, contre 13 des 9 054 relais hébergés ailleurs. C'est une corrélation, pas la preuve d'une compromission de l'hébergeur.

02Les deux charges utiles : SSH et courrier

SSH. Le trafic vers le port 22 quittait les sorties compromises pour l'un des 12 serveurs d'interception. L'intercepteur présentait sa propre clé d'hôte, enregistrait tout mot de passe saisi, puis se connectait au vrai serveur pour que la session paraisse normale. Un utilisateur qui ignorait l'avertissement d'OpenSSH sur le changement de clé d'hôte exposait donc ses identifiants et donnait à l'attaquant une vue en direct de la session. Ars rapporte aussi une troisième étape : l'attaquant ouvrait une connexion supplémentaire pour tenter d'implanter Ebury sur la destination. Dans le pot de miel de kaba, le client de l'attaquant s'identifiait comme paramiko, vérifiait l'identifiant utilisateur et la présence de sudo sans mot de passe, puis exécutait une commande Perl encodée en base64 pour installer Ebury.

La détection était plus difficile que l'avertissement ne le laisse penser. Seule une douzaine de sorties présentaient une fausse clé d'hôte. Les quelque 300 autres redirigeaient le trafic par les mêmes serveurs sans modifier la clé. Un utilisateur qui atteignait un serveur par l'une de ces sorties ne voyait rien d'anormal, mais le serveur, lui, voyait une connexion provenant de l'adresse d'un intercepteur plutôt que de celle de la sortie.

Courrier. La modification touchant le courrier est plus subtile que le raccourci d'Ars ne le laisse entendre, car tous les ports bloqués ne sont pas réservés au chiffrement. L'analyse de l'opérateur classe 25, 587 et la paire 110/143 comme « TLS optionnel ». Seuls 465, 993 et 995 sont des ports à TLS implicite. La politique finale bloquait l'envoi de courrier et la lecture chiffrée, mais laissait ouverts POP3 (110) et IMAP (143) en clair. L'opérateur note aussi que la première politique essayée par l'attaquant était l'inverse : elle bloquait POP3 et IMAP en clair, et elle a été remplacée par celle qui est entrée en production.

On en déduit que les clients configurés pour tenter TLS puis se rabattre sur le clair seraient poussés vers le texte en clair. Un relais de sortie lit tout ce qui sort en clair, et il peut aussi supprimer la négociation STARTTLS. Sur la plupart des relais, le changement a également ouvert POP3 et IMAP en clair. On ignore si un client de messagerie a effectivement rétrogradé sa connexion, comme le note Ars.

03Ampleur, durée et nettoyage

Ars situe le détournement du 2 au 5 octobre. D'autres sources comptent différemment la fenêtre d'application de la politique. La politique de Switzerland2 est restée en vigueur environ 52 heures sur deux relais Guard+Exit qui écoulaient environ 3,4 TiB par jour. Ebury lui-même est bien antérieur à la campagne : ESET estimait en 2024 qu'il avait infecté environ 400 000 serveurs Linux depuis 2009.

• Part du réseau : au pic, le 4 octobre à 01:00 UTC, les relais détournés portaient 7,46 % du poids de sortie utilisable de Tor.
• Correspondance de politique plus large : une analyse des données de l'annuaire a recensé 377 relais, exploités par 59 opérateurs, qui ont adopté la politique de sortie de l'attaquant entre le 1er et le 4 octobre. L'analyse elle-même parle de correspondance de politique, et non de preuve de compromission.
• Réaction : kaba a fait son signalement dans la soirée du 2 octobre. Les autorités de l'annuaire ont commencé à appliquer BadExit dans la soirée du 4 octobre, et à 17:00 UTC le 5 octobre, aucun relais doté de la politique de l'attaquant ne figurait plus dans le consensus. Lorsque les attaquants ont redémarré de nombreux relais le 5 octobre, les indicateurs les ont cantonnés à un rôle de relais intermédiaire.

Kaba affirme que l'équipe Tor chargée de la santé du réseau lui a dit n'avoir encore jamais vu d'attaque de ce type.

04Ce que cela dit du modèle de confiance de Tor

Tor sépare qui vous êtes de ce que vous envoyez, mais ne protège pas le contenu une fois sorti du relais de sortie. Le conseil de longue date du Tor Project est d'utiliser un chiffrement de bout en bout comme HTTPS, parce que la sortie voit le trafic en clair. Les abus de relais de sortie ne sont pas nouveaux. Une étude de 2014 de l'université de Karlstad avait relevé 19 relais de sortie utilisant des certificats auto-signés pour mener des attaques de l'homme du milieu sur HTTPS et SSH. En 2020, le chercheur nusenu a signalé que des attaquants exploitaient jusqu'à 380 relais de sortie, ce qui donnait aux utilisateurs environ une chance sur quatre de tomber sur une sortie malveillante.

Ce qui distingue le cas présent, c'est le mécanisme. Il s'agissait de relais d'opérateurs honnêtes, retournés par une banale compromission d'hôte, avec la politique de sortie comme levier. L'équipe Network Health a décrit l'attaquant comme modifiant des fichiers torrc pour transformer des relais hors sortie en sorties. La défense qui a fonctionné est venue de l'observation externe : le scan exitmap, les données de l'annuaire et un chercheur qui a refusé de passer outre un avertissement. La vue au niveau des familles aide aussi. La requête Onionoo de l'opérateur a montré 168 relais sur 57 adresses IP annonçant la même politique quasi ouverte. Le réseau Tor compte sur les hôtes des bénévoles pour rester intègres, et la fuite d'un seul identifiant peut prendre l'ampleur d'un événement à l'échelle du réseau.

05Détection et parades

Pour les utilisateurs et les administrateurs SSH :

1. Traitez un avertissement de changement de clé d'hôte comme un incident. Quiconque a saisi un mot de passe après avoir accepté une nouvelle clé doit le considérer comme volé, le changer et vérifier la présence d'Ebury sur la cible.
2. Désactivez l'authentification par mot de passe au profit des clés, comme le recommande Ars. Une attaque de l'homme du milieu ne capture alors rien de réutilisable. Épinglez les clés d'hôte avec une vérification stricte, ou utilisez des certificats SSH.
3. Lorsque c'est possible, accédez aux services d'administration via un service onion, afin qu'aucune sortie ne soit impliquée. Il s'agit d'une pratique générale, non d'un point abordé par les sources.
4. Utilisez le TLS implicite (465, 993, 995) et configurez les clients pour qu'ils refusent le texte en clair au lieu de s'y rabattre.

Pour les opérateurs de relais et les équipes réseau :

• Déclenchez une alerte sur toute modification de la politique de sortie que votre outil de gestion de configuration n'a pas effectuée. Comparez le descripteur publié avec celui prévu.
• Faites passer des sondes témoins par les sorties, comme l'a fait kaba, en vérifiant à la fois la clé présentée et l'adresse source vue par la destination.
• Ne réutilisez pas les mots de passe d'opérateur, et exigez un accès par clé uniquement pour les hôtes de rebond.
• Partez du principe qu'un hôte d'apparence saine peut ne pas l'être. Ebury 1.8.3 est plus récent que les indicateurs publics d'ESET, et l'opérateur n'a trouvé ni redirection NAT, ni nouveaux utilisateurs, ni binaire tor modifié. Les connexions par porte dérobée ne laissent ni journaux de connexion ni historique du shell. Les experts conseillent de mettre les relais hors ligne, de réaliser un instantané du disque et de tout reconstruire à partir de zéro plutôt que de nettoyer sur place.

06Ce qui reste à démontrer

Plusieurs questions restent ouvertes : comment les autres relais ont été atteints, pourquoi Switzerland2 a accepté la clé non répertoriée, et qui se cache derrière l'attaque. Kaba affirme que l'usage d'Ebury et le ratissage de données non chiffrées désignent un groupe motivé par l'argent, mais il précise qu'il s'agit d'une spéculation. Pour Léveillé, vu la portée d'Ebury, il existe très probablement d'autres relais Tor compromis. Personne n'a démontré combien de mots de passe ont été capturés ni si du courrier a été rétrogradé.