Entre le 2 et le 5 octobre 2026, des relais de sortie de Tor ont redirigé des connexions SSH vers des serveurs d’interception. Dans un compte rendu publié le 20 octobre, le bénévole Kaba a indiqué que son scan avait détecté 333 relais concernés sur environ 3 000 testés, et identifié 12 serveurs d’interception.
Ce que mesurait le scan
Kaba a utilisé exitmap et deux serveurs de test : l’un vérifiait l’empreinte de la clé d’hôte SSH, l’autre l’origine apparente de la connexion. Environ une douzaine de relais présentaient une fausse empreinte ; plus de 300 redirigeaient les connexions sans modifier eux-mêmes cette empreinte.
Un décompte distinct de 377 relais a été rapporté par The Hacker News à partir de l’analyse de politiques de sortie correspondant à un même modèle. Cette mesure ne compte pas les redirections SSH effectivement repérées par le scan de Kaba.
| Mesure | Nombre de relais | Méthode |
| Redirections SSH détectées par Kaba | 333 | Test d’environ 3 000 sorties avec exitmap, vérification de l’empreinte SSH et de l’origine de la connexion |
| Correspondances à un modèle de politique de sortie | 377 | Analyse distincte des données d’annuaire rapportée par The Hacker News |
Quand une connexion SSH pouvait exposer un mot de passe
SSH est un protocole de connexion à distance. Lorsqu’une connexion passe par un relais de sortie compromis, celui-ci peut rediriger le trafic vers un serveur d’interception. Dans la méthode décrite, le vol de mot de passe nécessitait que l’utilisateur accepte la clé d’hôte présentée par ce serveur, puis saisisse son mot de passe.
Une clé d’hôte permet au client de vérifier l’identité du serveur SSH. Si une clé déjà connue change, le client affiche un avertissement ; lors d’une première connexion, il peut présenter une demande normale d’acceptation. Kaba a relevé une empreinte ED25519 associée à un serveur d’interception : SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.
L’authentification du client par clé publique est une étape différente. Dans cette méthode d’attaque, la signature est liée à la session SSH et ne pouvait pas simplement être rejouée auprès du véritable serveur. Elle évitait donc la capture par saisie du mot de passe décrite ici, sans protéger contre d’autres voies de compromission, comme le vol d’une clé privée.
Une connexion SSH à un service onion reste dans Tor et ne passe pas par un relais de sortie. Le risque décrit concernait les connexions SSH qui quittaient Tor vers une destination ordinaire.
Les changements de ports de messagerie
La politique de sortie signalée bloquait les ports 25, 465, 587, 993 et 995. Sur deux relais Switzerland2 examinés par l’opérateur Zimmer, les ports POP3 110 et IMAP 143 restaient autorisés ; ils peuvent transporter des connexions sans chiffrement. Cette configuration créait un risque de rétrogradation, mais aucun vol de courriels ni aucune rétrogradation réussie n’a été établi.
Ce que Zimmer a trouvé sur deux serveurs
Dans son compte rendu, Zimmer a situé au 28 août 2026 l’accès à son serveur d’administration, obtenu à l’aide d’un mot de passe réutilisé. Il a indiqué que l’attaquant avait obtenu les droits administrateur en cinq minutes, puis installé Ebury 1.8.3 sur ce serveur et sur Switzerland2. Le mot de passe servait aussi à l’accès SSH, à sudo et au chiffrement d’une sauvegarde ; l’authentification SSH par mot de passe était activée sur le serveur d’administration exposé à Internet.
Ces constatations concernent les deux serveurs étudiés par Zimmer. Sur ces hôtes infectés, il a indiqué n’avoir trouvé ni redirection NAT ni binaire Tor modifié, et que les contrôles de paquets n’avaient pas détecté l’implant.
Les mesures conseillées aux opérateurs
Le 4 octobre, le Tor Project a indiqué que les relais concernés étaient signalés et rejetés par les autorités d’annuaire. Dans son avis aux opérateurs Linux publié le 5 octobre, le projet recommande d’examiner la configuration Tor et les fichiers inclus, les règles réseau, les processus, les connexions sortantes, l’intégrité des paquets, les comptes et les clés, ainsi que les tâches cron et les unités systemd.
Pour un relais soupçonné d’être compromis, le Tor Project recommande de le mettre hors ligne, de préserver les disques et les journaux, de réinstaller le système, de remplacer l’identité du relais et de renouveler les identifiants présents sur l’hôte. L’avis complet figure dans la note du Tor Project destinée aux opérateurs.
