Tailscale corrige fallos en SSH que convierten un dispositivo comprometido en root en los demás servidores

Tailscale ha publicado la versión 1.104.4 de su cliente para cerrar un conjunto de debilidades en Tailscale SSH, el servidor SSH integrado en su agente de VPN en malla. En un nodo Linux sin parchear, un atacante que ya controle un dispositivo de confianza para la política de la red podía abusar del reenvío SSH para alcanzar recursos reservados a root en otra máquina, y en un entorno de laboratorio eso bastó para obtener una shell de root.

Qué ocurrió

Tailscale SSH no autentica con contraseñas ni claves. Decide quién puede iniciar sesión a partir de la identidad del dispositivo que se conecta y de las reglas del archivo de políticas de la tailnet. El diseño es cómodo, pero también implica que un intruso no necesita credenciales robadas. Un punto de apoyo en cualquier dispositivo al que la política ya permita abrir una sesión SSH, con reenvío habilitado en esa regla, es el único requisito.

El punto débil es el reenvío de sockets. El demonio tailscaled se ejecuta como root y, cuando una sesión SSH permitida le pedía reenviar una conexión a un socket Unix del servidor, el demonio validaba la ruta solicitada y después ejecutaba el reenvío con sus propios privilegios de root. Una condición de carrera entre la comprobación y el uso permitía a la sesión sustituir la ruta por otra una vez superada la validación, lo que anulaba la salvaguarda que debía limitar qué sockets eran alcanzables.

En las pruebas, reenviar hacia el socket de control de Docker en el nodo objetivo produjo una shell de root y acceso de lectura al archivo shadow de contraseñas del sistema, sin ningún derecho administrativo en esa máquina. El aviso de Tailscale describe el impacto de forma más acotada, como acceso a sockets exclusivos de root tales como el socket de Docker o la API local de tailscaled, pero cualquiera de los dos resultados equivale al control total del nodo.

La compañía subraya que los fallos no permiten a un desconocido sin autenticar conectarse a servidores Tailscale SSH arbitrarios. El alcance lo delimita la política: el atacante solo llega a las máquinas a las que la política ya deja acceder por SSH al dispositivo comprometido. El servidor SSH solo se incluye en la compilación de Linux y en la compilación de código abierto de macOS, aunque el dispositivo atacante puede ejecutar cualquier plataforma.

La versión 1.104.4 cambia el servidor para que el reenvío se ejecute como el usuario autenticado y no como root, y se apoya en los permisos de archivo normales del sistema operativo en lugar de la antigua comprobación de ruta. La publicación cubre cuatro boletines de seguridad de Tailscale:

• TS-2026-014: las debilidades de reenvío de sockets descritas arriba, que permiten a una sesión autorizada alcanzar sockets exclusivos de root.
• TS-2026-015: una forma de que una sesión SSH autorizada agote la memoria del servidor y haga caer tailscaled, cortando toda la conectividad Tailscale en ese nodo.
• TS-2026-016: un fallo en tailscale serve por el que un reenvío a un socket Unix podía alcanzar la API local de tailscaled y tomar el control remoto del nodo, más un problema relacionado de sustitución de socket.
• TS-2026-017: con TLS serve y dos o más montajes configurados, una petición podía recibir las cabeceras de permisos de otro montaje.

En el momento de publicar, los boletines no tienen identificadores CVE ni puntuaciones de severidad, y ninguno indica la versión afectada más antigua. Tailscale afirma haber reproducido los principales problemas de escalada de privilegios, los califica de serios y sigue determinando qué configuraciones están afectadas.

Por qué importa

La divulgación desató una disputa en torno a la palabra "wormable". La investigadora que reportó los problemas demostró una cadena en la que un único dispositivo comprometido se propagaba a todos los nodos que la política permitía, sin contraseñas, sin claves robadas y sin interacción del usuario, con cada salto en bastante menos de 1 s. Tailscale rechaza ese encuadre: aquí no hay malware que se replique solo, sostiene la empresa, sino movimiento lateral limitado a las conexiones que la política ya autoriza. Ambas partes pueden tener razón a la vez. En muchas tailnets reales, la política es tan permisiva que "todos los dispositivos que la política permite" son sencillamente todos los dispositivos.

Dos puntos merecen atención especial:

• Parchear no expulsa a un atacante que ya está dentro. Una clave de dispositivo robada sigue siendo válida hasta que el nodo se elimina del plano de control. Reinstalar la máquina no la revoca, y los avisos de Tailscale no abordan este escenario.
• Headscale autoalojado está peor. En headscale, el reenvío SSH se concede en cada sesión aceptada y no se puede desactivar en la política, así que cada permiso SSH allí debe tratarse como un permiso de root. La última versión de headscale, la 0.29.5 del 13 de octubre, no corrige los problemas reportados.

La divulgación fue reportada, pero no coordinada. Tailscale afirma que recibió el informe la mañana del sábado 24 de octubre, unas dos horas antes de su publicación, y que sus ingenieros ya estaban revisando la misma zona del código. Ninguna de las partes tiene constancia de explotación en ataques reales, y el código de prueba de concepto solo se ha compartido con el equipo de seguridad de Tailscale. Un fallo distinto en la misma ruta de reenvío de sockets Unix se corrigió en junio, en la versión 1.98.9, y el informe también abarcó los conectores de aplicaciones de Tailscale y sus funciones serve y funnel. El hallazgo de los conectores está en conn25, una función experimental sin publicar, por lo que los conectores que usan hoy los clientes no están afectados. De los cinco hallazgos sobre serve y funnel, Tailscale corrigió tres y considera que los otros dos funcionan como está previsto.

Qué hacer

1. Actualiza todos los nodos Linux y macOS de código abierto a 1.104.4 o posterior, empezando por los servidores que exponen el socket de Docker o ejecutan otros servicios propiedad de root.
2. Si un nodo todavía no se puede actualizar, define TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y reinicia el servicio. Esto desactiva el reenvío sin apagar Tailscale SSH y bloquea varios de los hallazgos más graves.
3. Endurece la sección SSH de tu archivo de políticas. Concede SSH solo a los usuarios y dispositivos que realmente lo necesitan y prefiere pares explícitos dispositivo a dispositivo frente a reglas amplias por grupos. Las reglas por pares fueron uno de los dos controles que frenaron la cadena de movimiento lateral en las pruebas.
4. Vincula las claves de dispositivo al hardware, por ejemplo a un TPM, donde la plataforma lo permita, para que una identidad robada no pueda reutilizarse desde otro lugar. Fue el otro control que resistió.
5. No confíes en el modo check de SSH como solución. La reautenticación protege el inicio de la sesión; el abuso del reenvío ocurre dentro de una sesión ya aprobada. Aun así, conviene activar el modo check en los equipos sensibles.
6. Si sospechas que un nodo fue comprometido, elimínalo del plano de control y vuelve a inscribirlo. Solo parchear o reinstalar deja su clave utilizable.
7. Los operadores de headscale deben asumir que cada permiso SSH equivale a root hasta que llegue una versión corregida, y reducir esos permisos en consecuencia.

Debilidades como estas rara vez aparecen en un escaneo de puertos: la exposición vive en la política de acceso y en lo que una máquina de confianza puede alcanzar desde otra. Una prueba de penetración interna que parta de un único nodo supuestamente comprometido y trace hasta dónde puede llegar es la forma más fiable de saber si tu tailnet contendría el radio de impacto o entregaría las llaves. Ese tipo de ejercicio de movimiento lateral forma parte del servicio de penetration testing que ofrece nuestro equipo.