Le rapport détaille l'escalade possible des racines en utilisant Tallscale SSH en laboratoire

Un chercheur en sécurité a publié cette semaine un rapport décrivant comment, dans un laboratoire, un appareil déjà contrôlé au sein d'un réseau Tailscale peut être utilisé pour obtenir un accès avec des privilèges root sur d'autres équipements que le réseau peut atteindre. Le travail - publié le 25 octobre sous le nom de "Tailworm" par Erica Windisch de Cyberdione Labs - documente des preuves contre Tailscale 1.104.2 et tête 0,29.5 dans un environnement de laboratoire pendant plusieurs jours. Selon le rapport, la chaîne d'attaque a besoin de deux conditions spécifiques: que le réseau utilise Tailscale SSH avec le réexpédition des ports activés et que l'attaquant a déjà le contrôle d'un hôte que les règles d'accès Tailnet autorisent à se connecter à la cible.

Faits confirmés: Windish a publié un rapport technique et testé les versions de laboratoire susmentionnées; Tailscale a publiquement reconnu la réception du rapport et a déclaré qu'il travaillait avec des spécialistes externes; et, dès la publication du rapport, il n'y avait pas de bulletin de sécurité, de CVE public et une version parcheed disponible. En outre, le comportement de Tallscale SSH diffère de celui d'un serveur SSH traditionnel : l'autorisation est basée sur l'identité du périphérique et les règles d'accès au niveau de Tallnet, et non sur la vérification directe des mots de passe ou des clés par le serveur distant - c'est la clé pour comprendre pourquoi la technique n'exige pas d'identifications volées pour avancer.

Comment fonctionne l'escalade et la propagation décrite techniquement: Tallscale SSH permet, entre autres, le réexpédition des prises et des ports. Dans les tests de Windish, un tunnel SSH "normal" a démarré des connexions à partir d'un processus Tallscale qui fonctionne en tant que sockets racine à système qui ne devraient être accessibles que par racine; en manipulant ces canaux, des fichiers sensibles tels que / etc / ombre ou exécution de commande avec privilège racine ont été obtenus. Le rapport documente également des variantes : remplacer une socket appartenant à la racine par une socket contrôlée par l'attaquant pour exécuter des commandes, et une condition de carrière (TOCTOU) qui a échappé à une vérification préventive de l'accès aux fichiers. En laboratoire, cette chaîne a continué à capturer une clé de roulis utilisée pour intégrer de nouveaux nœuds dans le Tallnet et, dans les environnements sans la protection Tallnet Lock activée, l'utiliser pour ajouter un hôte attaquant comme serveur fiable.

Limites et aspects encore incertains: tous les tests décrits ont été réalisés dans un laboratoire contrôlé; il n'y a pas de reproduction publique indépendante ni de cas confirmés dans les réseaux productifs à la date du rapport. Tailscale a déclaré qu'ils enquêtent sur les configurations spécifiques vulnérables; par conséquent, l'extrapolation aux déploiements réels dépend de la configuration de chaque réseau (règles, utilisation de Tailnet Lock, ou la présence de clés liées à un matériel sécurisé comme TPM). Certains lecteurs et collègues se sont demandé si l'étiquette « verbiable » était appropriée en dehors des conditions de laboratoire; d'autres considèrent la possibilité de s'enraciner comme une découverte sérieuse. Il est important de distinguer entre les démonstrations contrôlées et les événements observés dans les environnements de production.

Qui est en danger: les réseaux utilisant Tailscale SSH avec réexpédition au port activé et permettant aux dispositifs à faible ségrégation d'accès d'atteindre des systèmes sensibles sont les plus exposés. Il y a une différence opérationnelle importante: dans le service hébergé par Tallscale vous pouvez désactiver le réexpédition en règle générale; dans l'échelle de tête 0.29.5, selon le rapport, il n'y a aucun moyen de désactiver le réexpédition, de sorte que chaque concession SSH dans ce logiciel devrait être considérée comme équivalente à donner racine dans l'hôte cible jusqu'à ce qu'il y ait un patch.

Incidences pratiques: si la chaîne d'exploitation est jouée dans des environnements réels, un attaquant avec une seule machine engagée que la politique Tailnet permet de se connecter à d'autres équipements pourrait, sans voler des mots de passe ou des clés, obtenir des privilèges racine et potentiellement déplacer cette même capacité latéralement à tous les systèmes autorisés par les règles. En laboratoire, la propagation a été mesurée à la vitesse de la machine (chaque saut en moins d'une seconde), mais cette mesure peut varier dans des environnements réels par des contrôles supplémentaires, des règles plus restrictives ou des protections matérielles.

Mesures concrètes et immédiates à prendre par les gestionnaires: réévaluer et agir maintenant - les actions qui suivent sont basées sur le rapport et le guide public Tailscale sur SSH.

(1) Revoir et restreindre les règles d'accès : convertir les règles SSH en paires de destination explicites (un seul appareil → une seule destination) et supprimer les règles générales par identité ou tags. Le rapport indique que les règles formulées comme paires d'unités étaient le contrôle qui a arrêté la chaîne en preuve.

2) Désactivez le transfert de port / Prises Unix si possible: Dans le service hébergé Tallscale, le réexpédition peut être désactivé en règle générale; si vous utilisez Headscale 0.29.5, vous devez supposer que le réexpédition est disponible et traiter chaque permis SSH comme un équivalent racine jusqu'à ce qu'une version corrigée existe.

3) Supprimer les connecteurs d'application inutiles et servir vers l'avant: les connecteurs expérimentaux qui permettent d'envoyer du trafic arbitraire vers des destinations non approuvées (par exemple, les métadonnées dans les fournisseurs de cloud) augmentent le risque; supprimer ces permis aux appareils qui n'en ont pas besoin réduit les vecteurs abusifs. Évitez les réexpéditions qui pointent vers les prises Unix sur la machine.

4) Activer l'expiration des touches de nœud et utiliser Tailnet Lock: configurer l'expiration de la clé de nœud pour limiter la fenêtre d'utilisation des clés de verrouillage Tailnet compromises et actives si votre organisation le supporte; dans les tests, l'absence de verrouillage Tailnet a permis l'étape finale de l'incorporation d'un noeud attaquant.

5) Réponse à l'engagement : Si vous détectez un équipement compromis, supprimez-le du plan de contrôle de Tailnet; réimaginer l'hôte n'invalide pas les clés déjà copiées. Envisagez la rotation des clés de bobine et l'examen médico-légal des jetons qui ont pu être exfiltrés.

6) Atténuation et surveillance supplémentaires: activer le "mode de vérification SSH" (ajouter une étape de connexion avant la session) et les mises à jour automatiques; garder à l'esprit que le mode de vérification ajoute une barrière supplémentaire mais, selon le rapport, ne corrige pas les privilèges soulevés décrits.

Pour des détails techniques sur la façon dont Tallscale implémente SSH et les options de configuration existantes, voir la documentation officielle: Documentation SSH à grande échelle. Si vous utilisez l'échelle de tête, vérifiez le dépôt et les notes de projet pour comprendre les limites des versions auto-organisées: tête d'échelle en GitHub.

À quoi s'attendre dans les prochaines semaines: Tallscale est susceptible de publier une communication formelle, un CVE ou une version parched une fois qu'il détermine exactement quelles configurations sont affectées et comment y remédier sans casser les déploiements. D'ici là, les contrôles de configuration et la minimisation des permis sont les outils les plus efficaces. Les organismes qui disposent de solides contrôles de sécurité (séparation du réseau, clés liées au matériel, règles par cible) seront mieux placés pour atténuer les risques; ceux qui utilisent l'échelle de tête sans possibilité de désactivation du réexpédition devraient prioriser l'évaluation de l'exposition.

Enfin, rappelez-vous que les résultats décrits proviennent de tests en laboratoire effectués par un chercheur et que, bien que les techniques soient techniquement plausibles et que la découverte de l'escalade des racines soit pertinente, la présence de l'exploitation dans des environnements réels n'est pas publiquement confirmée. Soyez proactif : réduisez la surface d'attaque dès maintenant et préparez-vous à appliquer des correctifs officiels lorsque disponibles.