Tailscale ha lanzado la versión 1.104.4 de su cliente para corregir deficiencias en su servidor SSH nativo que podrían permitir a un atacante acceder a servicios y archivos de otros servidores restringidos al usuario root. Los problemas residen en el mecanismo de reenvío de conexiones de red, una tarea que el proceso en segundo plano de Tailscale ejecuta con privilegios de superusuario.
Para aprovechar estas vulnerabilidades, el atacante debe controlar previamente un dispositivo que las reglas de acceso de la red autoricen a abrir una sesión SSH contra el objetivo, y que dicha regla permita el reenvío. Los fallos proceden de un informe denominado Tailworm, publicado días antes de la corrección por Erica Windisch, de Cyberdione Labs, quien probó en un laboratorio versiones ya distribuidas del cliente Tailscale y del servidor de control autoalojado headscale.
Tailscale SSH determina quién puede conectarse mediante la identidad del dispositivo y el fichero de políticas de la red, sin contraseñas ni claves, de modo que el atacante no necesita credenciales robadas, sino únicamente presencia en un equipo en el que la política ya confía. La empresa subraya que los fallos no permiten a un atacante no autenticado conectarse a servidores Tailscale SSH arbitrarios y que el alcance se limita a las máquinas que el fichero de políticas ya autoriza. El servidor de Tailscale SSH solo se ejecuta en Linux y en la compilación de código abierto para macOS; el dispositivo del atacante puede ser de cualquier plataforma.
El origen: reenvío de sockets y una carrera temporal
El problema se sitúa en el reenvío de sockets. Cuando una sesión SSH autorizada redirigía una conexión a un socket Unix del servidor, el proceso de Tailscale verificaba la ruta pero después operaba como root. Un truco de temporización permitía al atacante sustituir la ruta por otra después de esa comprobación, burlando la salvaguarda destinada a limitar los sockets alcanzables mediante reenvío.
En las pruebas de Windisch, el reenvío al socket de control de Docker produjo una shell de root y permitió leer el archivo de contraseñas del sistema, /etc/shadow, sin derechos de administrador. El boletín de Tailscale describe el alcance de forma más restrictiva: un atacante podría llegar a sockets reservados a root, como el de Docker o la API local de tailscaled.
En la versión 1.104.4, Tailscale modificó el servidor para que el reenvío se realice con la identidad del usuario conectado en lugar de root y para apoyarse en los permisos de archivo del propio sistema operativo en vez de en su comprobación previa de rutas. La actualización abarca cuatro boletines de seguridad:
- TS-2026-014: los fallos de reenvío de sockets SSH descritos, que permitían a una sesión autorizada alcanzar sockets reservados a root como el de Docker o la API local de tailscaled.
- TS-2026-015: una forma de que una sesión SSH autorizada agotara la memoria del servidor y provocara la caída del proceso de Tailscale, interrumpiendo toda la red Tailscale de 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, otorgando control remoto del nodo, además de un problema relacionado de intercambio de sockets.
- TS-2026-017: un fallo por el que, con TLS serve y dos o más montajes, una petición podía recibir las cabeceras de permisos de otro montaje.
Qué deben hacer los usuarios
Quienes utilicen Tailscale SSH deben actualizar a la versión 1.104.4 o posterior. Si no es posible actualizar un servidor de inmediato, se puede desactivar el reenvío SSH definiendo TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled y reiniciándolo; según Tailscale, esto anula el reenvío sin deshabilitar Tailscale SSH y bloquea varios de los hallazgos más graves. La empresa también recomienda revisar las reglas de acceso SSH para que solo tengan acceso los usuarios y dispositivos que lo necesiten.
Tailscale sugiere emplear el modo de verificación SSH, que exige al usuario iniciar sesión de nuevo antes de comenzar una sesión, en sistemas sensibles. No obstante, este modo no evita los fallos de reenvío: protege el inicio de la sesión, mientras que el reenvío ocurre dentro de una sesión ya aprobada.
Si un servidor podría haber sido comprometido, el informe de Windisch advierte de que la corrección por sí sola no basta. Una clave de dispositivo robada sigue siendo válida hasta que el dispositivo se elimina en el plano de control, ya que reinstalar la máquina no la revoca. Los avisos de Tailscale no contemplan este supuesto.
El panorama es peor en headscale, el servidor de control autoalojado. En headscale, el reenvío SSH se concede en todas las sesiones aceptadas y no puede desactivarse en la política, por lo que el informe de Windisch sostiene que toda concesión SSH allí debería tratarse como equivalente a otorgar root. La última versión de headscale, la 0.29.5 del 13 de octubre, no corrige los problemas descritos.
¿Se trata de un gusano?
Windisch calificó la cadena de ataques como 'propagable como un gusano'. En sus pruebas, un dispositivo comprometido podía extenderse a todos los dispositivos permitidos por la política, sin contraseñas, sin claves robadas y sin intervención del usuario, en menos de un segundo por paso. Dos controles frenaron la propagación: redactar las reglas de acceso como pares de dispositivo a dispositivo y vincular las claves de dispositivo a hardware como un TPM, lo que impide reutilizar una identidad robada en otro equipo.
Tailscale rechazó la descripción de gusano. Según la compañía, los hallazgos no describen malware autorreplicante que se propague solo entre máquinas, sino un movimiento lateral limitado a las conexiones que el fichero de políticas ya permite.
Tailscale calificó los problemas de escalada de privilegios como 'graves problemas de seguridad', afirmó haber reproducido los principales y añadió que sigue determinando qué configuraciones se ven afectadas.
Divulgación y correcciones anteriores
En el momento de la publicación, los cuatro boletines no incluyen identificadores CVE ni puntuaciones de gravedad, y ninguno indica la versión más antigua afectada. El informe también abarcó los conectores de aplicaciones de Tailscale y sus funciones serve y funnel. Tailscale señaló que el hallazgo de los conectores de aplicaciones corresponde a conn25, una función experimental no publicada, y que los conectores que usan los clientes hoy no están afectados. De los cinco hallazgos en serve y funnel, corrigió tres y sostuvo que los otros dos funcionan según lo diseñado.
Windisch publicó el informe sin coordinar previamente la divulgación con Tailscale, lo que ha descrito como 'reportado pero no coordinado'. Tailscale afirmó haber recibido el informe en la mañana del sábado 24 de octubre, unas dos horas antes de que Windisch lo publicara, y que sus ingenieros ya estaban revisando las mismas partes del código. Ni la empresa ni el informe indican que los fallos se hayan usado en ataques reales. El código de prueba de concepto no es público y Windisch aseguró haberlo entregado únicamente al equipo de seguridad de Tailscale.
Este informe es el último de una serie de correcciones en la misma área de Tailscale durante este año. En junio, la compañía corrigió en la versión 1.98.9 un fallo independiente en el reenvío de sockets Unix de Tailscale SSH que permitía a un usuario sin privilegios alcanzar un socket privilegiado.
Deja una respuesta