Fallas graves en Tailscale dejan que un equipo infectado controle otros servidores

Un informe publicado este fin de semana describe once fallas en Tailscale, una herramienta muy usada para conectar de forma privada los equipos de una empresa. La más grave permite que un atacante que ya controla un dispositivo de la red consiga permisos de administrador en otros servidores. Afecta sobre todo a quien usa Tailscale SSH, la función para entrar a distancia en las máquinas. Todavía no hay una versión corregida, y la empresa recomienda revisar los permisos de acceso y apagar el reenvío de conexiones donde no haga falta.

Tailscale crea una red privada entre computadoras, servidores y nubes, y muchas organizaciones la usan en lugar de una VPN tradicional. El riesgo es que una intrusión pequeña se convierta en un problema de toda la empresa. En el laboratorio, desde un solo equipo comprometido se saltó a cada servidor permitido por las reglas, sin contraseñas y en menos de un segundo por salto. Con ese control, el atacante pudo robar las claves que sirven para sumar equipos nuevos. En redes sin la protección Tailnet Lock, también logró unir una máquina propia con apariencia legítima.

El informe se titula Tailworm y lo firma Erica Windisch, de Cyberdione Labs. Analiza la versión 1.104.2 de Tailscale y la 0.29.5 de headscale, un servidor de control alternativo que algunas organizaciones instalan por su cuenta. Las fallas no tienen identificador CVE ni puntuación oficial, y las gravedades son las del propio documento. No hay reportes de ataques reales: todo se reprodujo en laboratorio.

Las tres fallas más serias están en el reenvío de conexiones de Tailscale SSH, que el programa ejecuta con permisos de administrador. Una sesión normal puede usarlo para manipular canales internos reservados a los servicios más privilegiados, como el que ejecuta aplicaciones en contenedores aislados. Otras fallas afectan a una función experimental de conectores, a la estabilidad de headscale y a serve, que publica servicios locales dentro de la red. El ataque no entra desde internet: necesita un equipo ya comprometido, por ejemplo mediante una web vulnerable o un paquete malicioso.

Mike Shaver, vicepresidente de ingeniería de Tailscale, respondió en el foro oficial de la empresa en Reddit. Dijo que recibieron el informe y que sus equipos ya investigaban esos problemas con especialistas externos. Reconoció que, en algunos casos, una sesión puede hacer más de lo que debería permitir el usuario local configurado. Pero subrayó que eso no equivale a que un atacante sin autorización pueda conectarse a cualquier máquina, y anunció un aviso de seguridad con los parches.

La forma de publicar también está en discusión. Windisch escribió en Hacker News, un foro de tecnología, que las fallas fueron reportadas pero no coordinadas, es decir, que salieron sin esperar a los parches. El informe defiende esa decisión porque la infraestructura ya es vulnerable y conocerlo rápido acelera las correcciones. Tailscale, en cambio, no recomienda que todos desactiven Tailscale SSH. Un ingeniero de la empresa matizó además que, en el servicio alojado, dos equipos sin reglas entre sí no se ven, algo que quizás no ocurra en headscale.

Los arreglos avanzan en el código público, aunque todavía no llegan a una versión descargable. El 26 de octubre Tailscale incorporó un cambio que traslada el reenvío a un proceso aparte, que actúa con los permisos del usuario conectado y nunca como administrador. Es la separación que pedía el informe y que ya aplican otros servidores SSH, como OpenSSH. Un día antes la empresa había corregido otra de las fallas, en serve, que podía mezclar los permisos de dos servicios publicados.

Mientras llega el parche, la medida más eficaz es que cada regla de SSH conecte un origen concreto con un destino concreto, sin permisos amplios para grupos enteros. Según el informe, fue la única medida que frenó la propagación en sus pruebas. La segunda es apagar el reenvío de conexiones donde no se use, algo que según Tailscale mitiga varias de las fallas más serias. La empresa también sugiere activar las actualizaciones automáticas para recibir los arreglos en cuanto salgan.

Para los administradores, el reenvío se apaga con la variable TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y un reinicio, sin desactivar el resto de Tailscale SSH. El modo check, que pide volver a autenticarse, añade una barrera, aunque no corrige la escalada de permisos. En headscale, las reglas de SSH no permiten excluir el reenvío, así que conviene tratar cada permiso como acceso de administrador. Tailnet Lock, que exige firmar cada equipo nuevo, impide unir una máquina ajena aunque se roben claves.

Como análisis, el caso muestra un riesgo propio de las herramientas que concentran el acceso de toda una organización. En ellas, una falla posterior a la autenticación pesa mucho más que en un programa aislado. Lo siguiente es el aviso prometido por Tailscale, que debe precisar qué hallazgos confirma, qué configuraciones quedan expuestas y qué versión trae las correcciones.