Entradas Mensuales

Síguenos en:

Canal Oficial Telegram de elhacker.NET Grupo Facebook elhacker.NET Twitter elhacker.NET Canal Youtube elhacker.NET Comunidad Steam: Grupo elhacker.NET Mastodon

Entradas populares

PostHeaderIcon Fallos en Tailscale SSH podrían dar acceso root a servidores desde un dispositivo comprometido


Un nuevo informe de seguridad llamado Tailworm, publicado el 25 de octubre de 2026 por la investigadora Erica Windisch, advierte que Tailscale SSH presenta fallos críticos. Estas vulnerabilidades podrían permitir que un atacante, tras comprometer un solo dispositivo, logre obtener acceso de root en otros servidores conectados a través de la red privada.



Un nuevo informe de seguridad advierte que Tailscale SSH tiene fallos que podrían permitir que un hacker pase de un dispositivo comprometido al acceso de root en otros servidores. Tailscale SSH permite que los dispositivos aprobados inicien sesión entre sí a través de una red privada.

El informe, llamado Tailworm, fue publicado el 25 de octubre de 2026 por la investigadora de seguridad Erica Windisch de Cyberdione Labs. Tailscale no ha confirmado los hallazgos y, hasta la fecha del informe, no había publicado ningún boletín, número CVE ni versión corregida para los mismos.

Fallos de Tailscale SSH

El informe enumera 11 hallazgos en cinco grupos. Estos abarcan el servidor SSH de Tailscale, sus funciones de "serve" y conector de aplicaciones, el cliente de relevo DERP y headscale, un servidor de código abierto que gestiona las redes de Tailscale. La investigadora probó tailscale 1.104.2 y headscale 0.29.5 entre el 22 y el 24 de octubre de 2026.

#ID del HallazgoComponenteQué fallaSeveridadQué necesita el intruso
1F1 (T3)Tailscale SSHEl reenvío de sockets locales (ssh -L) se ejecuta como root y alcanza sockets exclusivos de root. En el laboratorio, esto dio acceso root y permitió leer /etc/shadow.AltaUna regla de SSH que permita el reenvío local
2F2 (T2)Tailscale SSHEl reenvío de sockets remotos (ssh -R) reemplaza sockets propiedad de root. Esto permitió la ejecución de código root a través de un demonio de comandos.AltaUna regla de SSH que permita el reenvío remoto
3F3 (T2-RACE, T3-RACE)Tailscale SSHUna brecha de tiempo permite derrotar la comprobación de ruta antes de que se ejecute la acción del archivo. En el laboratorio, esto llevó a que un nodo malicioso se uniera a la red.AltaSesión SSH ordinaria con reenvío permitido
4F4 (C1)Conectores de apps (conn25)Un derecho de usuario permite cualquier destino saliente a través del conector. Esto alcanzó metadatos de la nube y servicios de Kubernetes.AltaUn derecho de aplicación ordinario
5F5 (T1)Tailscale SSHLa rotación de sesiones hace que el demonio root se quede sin memoria en un bucle. Se asignaron unos 536 MB en 7 segundos.AltaUna sesión SSH autenticada
6F6 (C2, C3, C4)headscale y cliente DERPLos registros no autenticados pueden expulsar aprobaciones de dispositivos pendientes. Un relevo malicioso también puede forzar a un cliente a leer hasta 1.34 GB.Media-AltaAcceso a internet a headscale, o un relevo hostil
7F7 (SERVE-F-1)tailscale serveUn reenvío TCP al socket de la API local permite que un par remoto escriba en la API local. En el laboratorio, un cambio de configuración devolvió éxito, lo que significa la toma de control del nodo.AltaConfiguración de Serve por el operador, más un par permitido
8F8 (SERVE-F-2)tailscale serveUn enlace simbólico intercambiado después de la configuración derrota la protección del socket, lo que permite marcaciones de root a sockets exclusivos de root.Media (contenida)Acceso de escritura local al directorio de la ruta del backend
9F9 (SERVE-F-3)FunnelEl acceso a Funnel depende solo de la capacidad del par y la configuración local. El informe trata esto como un problema del modelo de amenazas.MediaUn nodo con Funnel habilitado
10F10 (SERVE-F-4)tailscale serveLa configuración TS_SERVE_ALLOW_ALL_INTERFACES expone "serve" fuera de la vinculación del túnel. El informe llama a esto una nota de configuración.Nota de configuraciónNodos que establezcan esta variable
11F11 (SERVE-F-5)tailscale serveUna carrera en el contexto compartido de "serve" permite que los permisos de un montaje se trasladen a otro.Media, o Baja-Media sin autorización de encabezadoConfiguraciones de Serve que usan autorización basada en encabezados

El grupo más serio afecta a Tailscale SSH. Su servidor SSH se ejecuta dentro de tailscaled, un programa en segundo plano con poder total de root en la máquina. Según el informe, cuando un usuario tiene permiso para reenviar sockets de Unix (que son canales locales utilizados por servicios como Docker), el programa abre o reemplaza esos canales usando derechos de root. En el laboratorio, una sesión SSH ordinaria obtuvo root y leyó el archivo de contraseñas /etc/shadow casi instantáneamente.

La investigadora también describe una cadena que se propaga a través de una red. En el laboratorio, un dispositivo hackeado alcanzó el root en otros servidores e inscribió un nodo malicioso que parecía un servidor confiable. El informe indica que esta propagación no necesitó contraseñas ni claves robadas, y se movió de dispositivo en dispositivo en menos de un segundo por salto.

Tailscale construye una red mesh privada en la que los dispositivos confían entre sí basándose en reglas de política. Según el informe, cada dispositivo recibe una lista completa de sus pares, por lo que un hacker en una máquina puede ver cada objetivo posible. La investigadora dice que el primer punto de apoyo puede provenir de una aplicación web vulnerable, un paquete de software contaminado, un implante de phishing o datos de inicio de sesión robados.

Esto es importante porque la política asume que los dispositivos confiables son seguros. El informe dice que Tailscale no crea el primer punto de apoyo, pero puede convertir una pequeña brecha en un acceso amplio a toda una flota. Las reglas de acceso por par detuvieron la propagación en el laboratorio, y la investigadora las califica como el único control que funcionó.

Grupos de amenazas ya han utilizado Tailscale para moverse a través de redes. Un perfil de actor de amenazas de Scattered Spider describe cómo el grupo utilizó la VPN de Tailscale para moverse entre entornos.

Más allá de SSH, el informe describe problemas en la función experimental de conector de aplicaciones conn25. Según la investigadora, un dispositivo con permiso de conector puede enviar tráfico a cualquier destino que elija, incluido el servicio de metadatos de la nube que contiene las credenciales del servidor. En clústeres de Kubernetes, la misma ruta podría alcanzar servicios internos.

El informe también describe un problema de memoria en headscale que no requiere cuenta. La investigadora dice que un usuario remoto puede agotar la memoria en el servidor de control, lo que puede bloquear la unión de nuevos dispositivos. Una función de "serve" también puede exponer la interfaz de administración local a pares remotos cuando reenvía tráfico a un socket de Unix.

Un patrón de correcciones recientes de SSH

Este no es el primer problema serio de Tailscale SSH este año. En julio de 2026, Tailscale corrigió TS-2026-009, donde un nombre de usuario que comenzaba con un guion podía hacer que una búsqueda de cuenta de Linux devolviera la cuenta de root. Eso permitió que un usuario con acceso SSH abriera una sesión de root violando las reglas de ACL. La corrección llegó en la versión 1.98.9.

El acceso root a través de SSH es también un problema más amplio de Linux. Un informe de escalada de privilegios de Linux muestra cómo un usuario de SSH con un punto de apoyo de bajo nivel puede alcanzar el root en distribuciones principales.

La investigadora también sostiene que el diseño de código abierto se alejó de la protección por capas. El informe dice que Tailscale SSH reemplaza a OpenSSH, el cual divide los privilegios para que las sesiones de usuario se ejecuten con los derechos del usuario. La investigadora afirma que OpenSSH descarta los privilegios antes de que comience una sesión, mientras que la ruta de Tailscale mantiene a cargo un proceso altamente privilegiado.

Aún no existe un parche oficial, por lo que deberías seguir los pasos provisionales de la investigadora y la documentación de Tailscale. Reemplaza las reglas de SSH amplias (para toda la identidad o etiquetas) por concesiones por par que nombren un origen y un destino específicos. Establece el reenvío como "denegado" en cada regla donde exista esa configuración. En headscale 0.29.5, el reenvío no se puede desactivar, por lo que cada concesión de SSH debe tratarse como equivalente a root.

Desactiva Tailscale SSH en los dispositivos que no lo necesiten ejecutando tailscale set –ssh=false. Confirma primero otra forma de acceder al dispositivo, ya que la documentación advierte que podrías perder el acceso. Elimina los permisos del conector de aplicaciones donde no se utilicen, elimina los reenvíos de "serve" que apunten a sockets de Unix y activa la expiración de claves de nodo. Si un dispositivo se ve comprometido, elimínalo en el plano de control, ya que reinstalar la imagen del host no revoca las claves que ya fueron copiadas.

Las credenciales importan tanto como el código. Tailscale informó que un agente de IA utilizó una credencial robada de Tailscale para inscribir 181 nodos durante la intrusión de Hugging Face, aunque Tailscale afirmó que no se explotó ninguna vulnerabilidad.

Deberías revisar el informe Tailworm directamente y vigilar los boletines de seguridad de Tailscale para obtener una respuesta oficial. Algunos comentaristas cuestionan la gravedad de los hallazgos, y los resultados provienen de pruebas de laboratorio en lugar de brechas confirmadas. Aun así, el informe muestra cómo un dispositivo comprometido puede convertirse en una ruta hacia muchos servidores cuando las reglas de acceso son demasiado amplias. Los equipos que usen Tailscale SSH deberían revisar sus reglas hoy mismo y leer la documentación de SSH de Tailscale antes de realizar cambios.



Fuentes:
https://cybersecuritynews.com/tailscale-ssh-flaws/

0 comments :

Publicar un comentario

Los comentarios pueden ser revisados en cualquier momento por los moderadores.

Serán publicados aquellos que cumplan las siguientes condiciones:
- Comentario acorde al contenido del post.
- Prohibido mensajes de tipo SPAM.
- Evite incluir links innecesarios en su comentario.
- Contenidos ofensivos, amenazas e insultos no serán permitidos.

Debe saber que los comentarios de los lectores no reflejan necesariamente la opinión del STAFF.