La investigadora de seguridad Erica Windisch, de Cyberdione Labs, ha reportado debilidades en Tailscale SSH que, en pruebas de laboratorio, permitieron a un atacante que controlaba un dispositivo obtener acceso root en otros servidores alcanzables. El ataque requería que el reenvío de puertos SSH estuviera permitido y que las reglas de acceso a la red permitieran al dispositivo comprometido conectarse a sus objetivos.
Windisch publicó los hallazgos el 25 de octubre en un informe titulado Tailworm, tras tres días de pruebas con Tailscale 1.104.2 y headscale 0.29.5, una alternativa autoalojada al servicio de control alojado de Tailscale. Los hallazgos describen ataques de laboratorio, sin que se haya reportado su explotación en redes reales.
Según The Hacker News, Tailscale no había publicado en el momento de la publicación ningún boletín de seguridad, identificador CVE ni versión corregida para estos hallazgos. Ningún otro investigador los había reproducido públicamente, y Tailscale no había confirmado las afirmaciones técnicas concretas.
Mike Shaver, vicepresidente de ingeniería de Tailscale, dijo en Reddit que la empresa había recibido el informe, que ya investigaba esas mismas áreas con especialistas externos en seguridad y que había identificado problemas que estaba trabajando para corregir. Añadió que todavía determinaba qué configuraciones estaban afectadas y que «no recomendamos que todo el mundo desactive Tailscale SSH».
Cómo funcionaron los ataques SSH reportados
Tailscale SSH utiliza la identidad del dispositivo y reglas de acceso para autorizar las conexiones, en lugar de exigir una contraseña o clave SSH convencional. Por tanto, los ataques reportados no requerían credenciales SSH robadas, pero sí un punto de apoyo previo en un dispositivo autorizado. Los hallazgos no establecen ninguna forma de obtener ese acceso inicial.
En una prueba, Windisch informó de que el reenvío de puertos SSH habitual hacía que el proceso de Tailscale, que se ejecuta con privilegios de root, se conectara a un socket del sistema restringido a root. Eso proporcionaba acceso root y permitía leer el archivo de contraseñas del sistema sin que el usuario que se conectaba tuviera privilegios de administrador.
Un segundo método, según se informa, sustituía un socket propiedad de root por otro controlado por el atacante, lo que permitía ejecutar comandos como root a través de determinados servicios. Un tercero explotaba una condición de carrera entre una comprobación de seguridad de la ruta de un archivo y el uso posterior de esa ruta, lo que eludía las restricciones sobre los archivos a los que podía acceder el reenvío.
La tercera cadena también capturó una clave utilizada para registrar dispositivos y la empleó para añadir a la red, como servidor de confianza, una máquina controlada por el atacante. Esa secuencia solo se completaba cuando Tailnet Lock estaba desactivado. Con Tailnet Lock activado, el informe indica que los secretos necesarios se capturaban en tránsito, pero que el último paso del registro no llegaba a completarse.
Windisch describió el resultado general como «wormable» (con capacidad de propagarse como un gusano), y señaló que el compromiso podía extenderse a través de los dispositivos permitidos por las reglas de acceso en menos de un segundo por paso, sin contraseñas, claves robadas ni interacción del usuario. Esa velocidad y esa propagación se demostraron en el laboratorio. Algunos investigadores cuestionaron públicamente la calificación de «wormable», mientras que otros describieron el hallazgo de acceso root como grave.
La configuración determina la exposición
El informe identificó como control que detenía la propagación en las pruebas las reglas de acceso que especifican pares individuales de dispositivo de origen y de destino. Las claves de dispositivo vinculadas al hardware, como las ligadas a un TPM o a un Secure Enclave, también limitaban los ataques.
Los controles de reenvío varían según el despliegue. En el servicio alojado de Tailscale, el reenvío de puertos SSH puede desactivarse por regla. Según el informe, headscale 0.29.5 no permite desactivarlo, por lo que Windisch sostuvo que las concesiones SSH en esa versión deben considerarse como concesiones de acceso root a sus destinos.
Los ataques SSH forman parte de 11 hallazgos que afectan a funciones de Tailscale y a headscale. Windisch también reportó que la función experimental de conector de aplicaciones conn25 podría permitir a un usuario autorizado alcanzar destinos que los administradores no habían aprobado, incluido un servicio de metadatos en la nube capaz de proporcionar credenciales de servidor. Se trata de una afirmación de la investigadora, no de una prueba de credenciales robadas en un entorno de producción.
Las medidas de configuración que se recomiendan incluyen restringir los permisos SSH, desactivar el reenvío donde sea compatible, eliminar los permisos innecesarios del conector de aplicaciones y quitar los reenvíos de tailscale serve a sockets de Unix. Activar la caducidad de la clave de nodo limita la validez de una clave robada; eliminar un dispositivo comprometido desde el plano de control revoca un acceso que reinstalar el sistema por sí solo podría dejar intacto.
Tailscale también recomienda el modo de comprobación de SSH, que añade un paso de inicio de sesión antes de cada sesión, así como las actualizaciones automáticas. El modo de comprobación añade una barrera de acceso, pero no corrige la escalada de privilegios reportada.
Windisch afirmó que el código de la prueba de concepto se compartió solo con el contacto de seguridad de Tailscale. Aunque calificó la divulgación como «reportada pero no coordinada», le dijo a The Hacker News que había enviado a la empresa tanto el informe como el código antes de la publicación.
