Un attaquant a pris le contrôle de 333 relais de sortie Tor et les a transformés en plateforme de collecte. Les sessions SSH passant par les sorties compromises étaient redirigées vers l'un des 12 serveurs d'interception. Les ports utilisés pour l'envoi et la récupération chiffrés des e-mails étaient bloqués, de sorte que les messages pouvaient être lus en clair si un service revenait à une connexion non chiffrée. Le récit provient d'un rapport d'Ars Technica signé Dan Goodin, qui s'appuie sur un message et une enquête d'un bénévole de Tor identifié sous le nom de Kaba, ainsi que sur les déclarations d'autres bénévoles.
L'ampleur du problème tient à la taille réduite du réseau : l'article évalue Tor à environ 3 000 nœuds de sortie. Les relais détournés représentent donc environ un dixième des sorties par lesquelles le trafic peut quitter le réseau.
Un mot de passe réutilisé, Ebury et le pivot vers Switzerland2
Selon les bénévoles de Tor cités dans le rapport, l'intrusion a débuté fin août, et le détournement lui-même s'est produit entre le 2 et le 5 octobre. Le point d'entrée était un mot de passe valide, réutilisé sur un serveur d'administration de Tor. À partir de là, l'attaquant a installé Ebury, une porte dérobée Linux que l'article dit avoir été découverte 12 ans plus tôt, puis a ouvert une connexion SSH depuis ce serveur d'administration vers une seconde machine de Tor, appelée Switzerland2.
Ce second saut reposait sur une clé RSA que les enquêteurs n'ont pas pu retrouver parmi les clés autorisées de Switzerland2. Ebury a également été installé sur Switzerland2, et deux relais de sortie hébergés par cette machine ont été reconfigurés. Les bénévoles n'ont pas établi comment l'attaquant a pris le contrôle des autres serveurs sous-jacents. Une piste évoquée par eux, selon laquelle une société d'hébergement aurait été compromise, est jugée non concluante.
Comment le trafic SSH a été capturé et a servi à de nouvelles infections
L'enquête de Kaba a établi que le trafic SSH sur le port 22 traversant les sorties compromises était redirigé vers les 12 serveurs contrôlés par l'attaquant. Lorsque les utilisateurs ignoraient l'avertissement de changement de clé d'hôte, l'attaquant volait leur mot de passe SSH, ouvrait une connexion vers le serveur visé et observait toutes les commandes saisies. Il ouvrait ensuite une seconde connexion et infectait le serveur avec Ebury.
L'empreinte présentée dans l'avertissement falsifié est SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. Le texte de l'avertissement est le message standard du client, qui commence par « REMOTE HOST IDENTIFICATION HAS CHANGED ». Quiconque a accepté une nouvelle clé provenant d'un relais de sortie pendant la période concernée doit considérer comme suspects à la fois les identifiants utilisés lors de cette session et le serveur situé à l'autre bout.
E-mails : blocage des ports chiffrés
Côté messagerie, les sorties compromises bloquaient les ports 25, 465, 587, 993 et 995, c'est-à-dire les ports utilisés pour l'envoi et la récupération chiffrés, tout en laissant ouverts les ports de réception des messages non chiffrés. L'effet était de rediriger le trafic vers des connexions que l'attaquant pouvait lire si un service de messagerie rétrogradait la connexion. Le rapport n'établit pas si une tentative de repli a réellement réussi.
Le script de sondage et le honeypot qui l'ont exposé
La compromission a été mise au jour par une méthode de vérification, et non par un signalement. Un script interrogeait chaque relais de sortie pour vérifier s'il présentait la bonne empreinte SSH d'un serveur de test. Ce serveur de test enregistrait également si une connexion entrante provenait d'un relais épinglé ou de l'un des 12 serveurs d'interception. Un honeypot a été déployé pour observer le logiciel d'interception tentant une connexion et installant Ebury. Le détournement a commencé fin août et s'est déroulé du 2 au 5 octobre. La connexion de test de Kaba a été redirigée un vendredi matin, et le chercheur a publié son rapport le mardi.
L'attribution reste une hypothèse
Kaba a déclaré que l'usage d'Ebury, associé à une collecte massive de données non chiffrées, laisse penser à un groupe criminel motivé par l'argent, et a explicitement qualifié cette hypothèse de spéculation. L'article n'identifie pas la personne ou le groupe derrière la campagne.
Mesures pratiques pour ceux qui ont utilisé ces sorties
Les mesures listées dans l'article visent directement ce que l'attaquant a exploité. Côté client, n'acceptez que le trafic e-mail chiffré et refusez les ports non chiffrés. Désactivez l'authentification par mot de passe pour SSH et utilisez des connexions par clé, contre lesquelles les identifiants capturés ne serviraient à rien. Enfin, considérez un changement inattendu de clé d'hôte comme une possible attaque de type homme du milieu, et non comme un désagrément qu'on valide sans réfléchir. L'avertissement lui-même invite à contacter l'administrateur système, et la seule façon de distinguer une rotation légitime d'un serveur d'interception est de vérifier la nouvelle clé par un canal distinct.
