La chercheuse en sécurité Erica Windisch, de Cyberdione Labs, a signalé des faiblesses de Tailscale SSH qui, lors de tests en laboratoire, permettaient à un attaquant contrôlant un appareil d'obtenir un accès root sur d'autres serveurs joignables. L'attaque supposait que le transfert de port SSH soit autorisé et que les règles d'accès réseau permettent à l'appareil compromis de se connecter à ses cibles.
Windisch a publié ses conclusions le 25 octobre, dans un rapport intitulé Tailworm, à l'issue de trois jours de tests avec Tailscale 1.104.2 et headscale 0.29.5, une alternative auto-hébergée au service de contrôle hébergé de Tailscale. Ces conclusions décrivent des attaques réalisées en laboratoire, sans exploitation signalée contre de véritables réseaux.
Selon The Hacker News, Tailscale n'avait publié ni bulletin de sécurité, ni identifiant CVE, ni version corrigée pour ces failles à la date de publication. Aucun autre chercheur ne les avait reproduites publiquement, et Tailscale n'avait pas confirmé les affirmations techniques précises.
Le vice-président de l'ingénierie de Tailscale, Mike Shaver, a déclaré sur Reddit que l'entreprise avait reçu le rapport, qu'elle enquêtait déjà sur les mêmes domaines avec des spécialistes externes en sécurité et qu'elle avait identifié des problèmes qu'elle s'employait à corriger. Il a indiqué que l'entreprise déterminait encore quelles configurations étaient touchées et qu'elle « ne recommande pas à tout le monde de désactiver Tailscale SSH ».
Comment fonctionnaient les attaques SSH signalées
Tailscale SSH s'appuie sur l'identité des appareils et des règles d'accès pour autoriser les connexions, au lieu d'exiger un mot de passe ou une clé SSH classique. Les attaques signalées ne nécessitaient donc pas d'identifiants SSH volés, mais elles supposaient un point d'appui préalable sur un appareil autorisé. Les conclusions n'établissent pas de moyen d'obtenir cet accès initial.
Dans un test, Windisch a indiqué qu'un transfert de port SSH ordinaire amenait le processus Tailscale, qui s'exécute avec les droits root, à se connecter à un socket système réservé à root. Cela donnait un accès root et permettait de lire le fichier de mots de passe du système sans que l'utilisateur connecté dispose de privilèges d'administrateur.
Une deuxième méthode aurait consisté à remplacer un socket appartenant à root par un socket contrôlé par l'attaquant, ce qui permettait d'exécuter des commandes en root via certains services. Une troisième exploitait une situation de concurrence entre une vérification de sécurité sur le chemin d'un fichier et l'utilisation ultérieure de ce chemin, contournant ainsi les restrictions sur les fichiers auxquels le transfert pouvait accéder.
La troisième chaîne a également capturé une clé servant à enregistrer des appareils, et l'a utilisée pour ajouter au réseau une machine contrôlée par l'attaquant, en tant que serveur de confiance. Cette séquence n'a abouti que lorsque Tailnet Lock était désactivé. Avec Tailnet Lock activé, selon le rapport, les secrets nécessaires ont bien été capturés en transit, mais l'étape finale d'enregistrement n'a pas été menée à terme.
Windisch a décrit l'ensemble du résultat comme « wormable », en indiquant que la compromission pouvait se propager à travers les appareils autorisés par les règles d'accès en moins d'une seconde par étape, sans mot de passe, sans clé volée et sans intervention de l'utilisateur. Cette rapidité et cette propagation ont été démontrées en laboratoire. Certains chercheurs ont publiquement remis en question la qualification de « wormable », tandis que d'autres ont jugé grave la découverte d'un accès root.
La configuration détermine l'exposition
Le rapport a identifié les règles d'accès qui précisent des paires d'appareils source-destination individuelles comme un contrôle ayant arrêté la propagation lors des tests. Les clés d'appareil liées au matériel, comme celles rattachées à un TPM ou à une Secure Enclave, limitaient également les attaques.
Les contrôles de redirection varient selon le déploiement. Sur le service hébergé de Tailscale, le transfert de port SSH peut être désactivé règle par règle. Selon le rapport, headscale 0.29.5 ne permet pas de le désactiver ; Windisch soutient donc que les autorisations SSH sur cette version devraient être considérées comme accordant un accès root à leurs cibles.
Les attaques SSH font partie de 11 constats portant sur les fonctionnalités de Tailscale et de headscale. Windisch a également signalé que la fonctionnalité expérimentale de connecteur d'application conn25 pouvait permettre à un utilisateur autorisé d'atteindre des destinations que les administrateurs n'avaient pas approuvées, notamment un service de métadonnées cloud capable de fournir des identifiants de serveur. Il s'agit toujours d'une affirmation du chercheur, et non de la preuve d'identifiants volés dans un environnement de production.
Les mesures de configuration recommandées comprennent la restriction des autorisations SSH, la désactivation de la redirection lorsqu'elle est prise en charge, la suppression des permissions inutiles du connecteur d'application et la suppression des redirections tailscale serve vers des sockets Unix. L'activation de l'expiration des clés de nœud limite la durée de validité d'une clé volée ; la suppression d'un appareil compromis au niveau du plan de contrôle révoque un accès que la seule réinstallation pourrait laisser intact.
Tailscale recommande également le mode check de SSH, qui ajoute une étape de connexion avant chaque session, ainsi que les mises à jour automatiques. Le mode check ajoute une barrière d'accès, mais ne corrige pas l'élévation de privilèges signalée.
Windisch a indiqué que le code de preuve de concept n'avait été partagé qu'avec le contact sécurité de Tailscale. Bien qu'elle qualifie la divulgation de « signalée mais non coordonnée », elle a déclaré à The Hacker News avoir transmis à l'entreprise à la fois le rapport et le code avant la publication.
