Un único dispositivo comprometido en una Tailnet de Tailscale puede convertirse en punto de partida para obtener privilegios de root en otros servidores que ese dispositivo puede alcanzar, según un informe publicado el 25 de octubre por la investigadora Erica Windisch de Cyberdione Labs.
Qué ocurre y qué condiciones se necesitan
El ataque descrito no explota contraseñas ni claves robadas: aprovecha cómo funciona Tailscale SSH, que identifica dispositivos en lugar de usuarios y concede acceso según reglas de dispositivo. Para que la cadena de ataque tenga éxito se requieren dos condiciones concretas:
- Tailscale SSH configurado para permitir el reenvío de puertos (port forwarding).
- Un atacante que ya controla al menos un dispositivo que las reglas de acceso de la red autoricen a conectar con el objetivo.
En laboratorio, Windisch demostró varias técnicas que permiten, a partir de una sesión SSH con reenvío, forzar al proceso de Tailscale que corre con privilegios de root a conectar con sockets del sistema que solo root debería leer o usar. Eso posibilitó la escalada a root y la lectura inmediata de archivos sensibles, como el fichero de contraseñas del sistema.
Alcance de la prueba y limitaciones
Las pruebas se realizaron en laboratorio sobre Tailscale (la investigadora probó la versión indicada en su informe) y sobre headscale (el servidor self-hosted compatible con Tailscale). El informe no documenta ataques en redes reales; además, a la fecha de la publicación no existía todavía un boletín de seguridad ni parche oficial ni identificador CVE público asociado.
Cómo se propaga y por qué Windisch lo llamó “wormable”
En la demostración, un dispositivo comprometido podía, en segundos por salto, extender el control a cualquier otro equipo al que las reglas de acceso permitieran conectar, sin requerir contraseñas, claves robadas ni interacción de usuarios. La investigadora añadió que el vector fue capaz de capturar una clave de inscripción de nuevos dispositivos y, en redes sin la configuración de bloqueo, usarla para incorporar máquinas del atacante como servidores de confianza.
Sin embargo, el informe también señala barreras que limitarían la propagación en condiciones reales: reglas de acceso específicas (origen-destino) que actúan como contención y claves de dispositivo ligadas a hardware seguro (TPM, Secure Enclave).
Respuesta de Tailscale y recomendaciones provisionales
Tailscale ha reconocido públicamente la recepción del informe y ha indicado que trabaja con especialistas externos en algunas de las áreas señaladas, aunque no había publicado aún un parche o detalles técnicos confirmados de forma pública al momento de la nota. La compañía ha dicho que aún evalúa qué configuraciones concretas resultan afectadas y que no recomienda desactivar Tailscale SSH de forma generalizada.
Mientras no exista un parche oficial, las medidas prácticas sugeridas por la propia documentación de Tailscale y por el informe son gestionar el reenvío de puertos con cautela y tratar cada concesión de SSH como potencialmente peligrosa. En la plataforma alojada de Tailscale es posible desactivar el reenvío por regla; en headscale (versión probada por la investigadora) esa opción no estaba disponible, por lo que el informe recomienda considerar cada permiso SSH como equivalente a dar acceso root al objetivo.
Otras mitigaciones comentadas incluyen activar el modo de comprobación de SSH (SSH check mode) que obliga a un paso de inicio de sesión adicional antes de comenzar la sesión —aunque este modo no corrige la escalada de privilegios, añade una barrera extra— y mantener las actualizaciones automáticas habilitadas para aplicar parches cuando estén disponibles.
Qué deben hacer administradores y dueños de sitios
- Revisar las reglas de acceso en su Tailnet y minimizar permisos de reenvío de puertos; tratar cualquier concesión SSH como de alto riesgo si no puede limitarse.
- Si usan headscale, verificar si su versión permite desactivar el reenvío; si no, evaluar restricciones adicionales en la red o en el diseño de permisos.
- Habilitar características de defensa adicionales como SSH check mode y forzar políticas de hardware seguro (TPM, Secure Enclave) para las claves de dispositivo cuando sea posible.
- Prepararse para aplicar parches oficiales de Tailscale en cuanto se publiquen y seguir los avisos del proveedor de software.
El informe explica que las pruebas y la PoC se entregaron a Tailscale; no todas las afirmaciones han sido reproducidas por terceros ni confirmadas por la compañía a la fecha.
Lee también:
- Arista parchea un tercer zero-day en VeloCloud Orchestrator (VCO) en cuatro meses
- Google aclara que datos de Gmail y Photos usados por funciones de IA pueden influir en la publicidad personalizada
Fuente: The Hacker News
