Tailscale corrige vulnerabilidades de SSH que permitían acceso root mediante reenvío de sockets

Tailscale ha lanzado la versión 1.104.4 para abordar graves fallos de seguridad en su servidor SSH integrado, los cuales podrían permitir a atacantes escalar sus privilegios hasta root en las máquinas objetivo. Las vulnerabilidades, reveladas en un informe de Erica Windisch de Cyberdione Labs, afectan al modo en que el servicio gestiona el reenvío de conexiones de red y fueron parcheadas apenas unos días después de su publicación.

Qué ocurrió

El problema principal radica en cómo el servidor SSH de Tailscale maneja el reenvío de sockets Unix. Cuando un usuario establece una sesión SSH, el proceso en segundo plano de Tailscale realiza la operación de reenvío con privilegios de root. Aunque el sistema verifica la ruta del socket al que se accede, una vulnerabilidad de sincronización temporal (race condition) permitía a los atacantes cambiar la ruta después de la verificación pero antes de que se estableciera la conexión. Esta condición de carrera evadía efectivamente las medidas de seguridad destinadas a restringir el acceso a sockets sensibles del sistema.

En pruebas de laboratorio, Windisch demostró que un atacante que ya controlaba un dispositivo permitido por la política de red podía reenviar conexiones al socket de control de Docker o a la API local de tailscaled. Este acceso otorgaba una shell de root y la capacidad de leer archivos sensibles como /etc/shadow sin necesidad de credenciales de administrador. El ataque no requiere contraseñas ni claves robadas, solo un punto de apoyo en un dispositivo confiable dentro de la red Tailscale.

Tailscale aclaró que estos fallos no permiten a atacantes no autenticados conectarse a servidores arbitrarios. El acceso sigue regido por el archivo de políticas de la red, lo que significa que un atacante solo puede alcanzar máquinas a las que ya tiene autorización. Sin embargo, una vez dentro de una sesión permitida, la escalada de privilegios facilita el movimiento lateral hacia servicios exclusivos de root. La empresa describió los problemas como serios fallos de seguridad, pero rechazó calificar el exploit como un gusano autorreplicante, señalando que depende de permisos de políticas existentes en lugar de propagarse de forma autónoma.

Cómo funciona

La vulnerabilidad explota la diferencia entre la comprobación de permisos y el contexto de ejecución. Anteriormente, el proceso de Tailscale verificaba la ruta del socket y luego realizaba la operación de reenvío como root. Al intercambiar la ruta del socket durante esta ventana de tiempo, un atacante podía engañar al sistema para que se conectara a un socket privilegiado en lugar del previsto. La corrección en la versión 1.104.4 cambia este comportamiento para que el reenvío se lleve a cabo como el usuario conectado y no como root. También desplaza la dependencia de las verificaciones internas de rutas hacia los permisos nativos de archivos del sistema operativo, que son más robustos frente a estas condiciones de carrera.

Este cambio aborda específicamente el boletín TS-2026-014, que cubre los fallos de reenvío de sockets. La actualización también resuelve otros tres problemas: un bug de agotamiento de memoria que podría bloquear el proceso de Tailscale (TS-2026-015), una falla en la función tailscale serve que permitía el control remoto de nodos mediante sockets Unix (TS-2026-016) y un problema de filtración de cabeceras en configuraciones de TLS serve (TS-2026-017). El servidor SSH de Tailscale se ejecuta en Linux y en la compilación de código abierto para macOS, aunque el dispositivo atacante puede ser de cualquier plataforma.

Detalles clave

• Versiones afectadas: No se especifica la versión más antigua afectada, pero la versión 1.104.4 contiene las correcciones.
• Requisitos previos: Los atacantes deben controlar ya un dispositivo confiable según la política de red, con el reenvío SSH habilitado.
• Impacto: Una explotación exitosa otorga acceso a sockets exclusivos de root, como el socket de Docker o la API local de tailscaled.
• Usuarios de Headscale: El servidor de control headscale autoalojado (versión 0.29.5) aún no corrige estos problemas, y el reenvío SSH no puede deshabilitarse en su política.
• Divulgación: El informe se publicó sin coordinación previa; Tailscale lo recibió dos horas antes del lanzamiento público.
• Sin CVEs: Hasta el momento de la publicación, los cuatro boletines de seguridad no tienen identificadores CVE asignados ni puntuaciones de severidad.

Por qué importa

Para los equipos de ingeniería que utilizan Tailscale para el acceso a infraestructuras, este incidente destaca los riesgos de la confianza implícita en los modelos de identidad de dispositivos. Dado que Tailscale SSH utiliza la identidad del dispositivo en lugar de contraseñas, comprometer un único dispositivo confiable puede proporcionar una vía hacia sistemas críticos si el reenvío está habilitado. La velocidad con la que el exploit puede moverse lateralmente —menos de un segundo por paso en las pruebas— implica que los tiempos de detección y respuesta deben ser extremadamente rápidos para evitar una comprometida generalizada.

La situación es particularmente difícil para los usuarios de headscale, la alternativa de código abierto al plano de control de Tailscale. Como headscale actualmente carece de la capacidad para deshabilitar el reenvío SSH en la política y aún no ha lanzado una corrección, los administradores que usan esta configuración deben tratar cada concesión de SSH como una posible concesión de acceso root. Esto subraya la importancia de comprender las diferencias entre servicios gestionados y alternativas autoalojadas al evaluar las posturas de seguridad.

Qué puedes hacer

• Actualiza todos los clientes y servidores de Tailscale a la versión 1.104.4 o posterior inmediatamente.
• Si la actualización no es posible, establece TS_SSH_DISABLE_FORWARDING=1 en el entorno del servicio tailscaled para bloquear el reenvío.
• Revisa las reglas de acceso SSH para asegurar que solo los dispositivos y usuarios necesarios tengan permiso de conexión.
• Habilita el modo de comprobación SSH para sistemas sensibles, exigiendo reautenticación antes de iniciar sesiones.
• Para usuarios de headscale, restringe agresivamente las concesiones de SSH y monitoriza actividad no autorizada a nivel de root.
• Reimagen y elimina dispositivos comprometidos del plano de control si sospechas de una brecha, ya que reimagenar por sí solo no revoca las claves del dispositivo.