Tailworm: Una caja comprometida, root en la siguiente 11 hallazgos sin parchear de Tailscale, y qué cerrar esta noche Tu red privada es privada solo hasta que un dispositivo dentro de ella sea comprometido. Un nuevo informe afirma que Tailscale SSH puede convertir ese único dispositivo en root en los demás. Sin parche. Sin CVE. Aún así. ---------------------- El 25 de octubre, la investigadora Erica Windisch (Cyberdione Labs) publicó "Tailworm": 11 hallazgos en 5 grupos, probados en Tailscale 1.104.2 y headscale 0.29.5 entre el 22 y el 24 de octubre. El problema central: Tailscale SSH se ejecuta dentro de tailscaled, y tailscaled se ejecuta como root. Cuando una sesión reenvía sockets Unix (ssh -L / -R), las verificaciones de ruta y las operaciones de archivo ocurren con privilegios de root. En su laboratorio, una sesión ordinaria pasó por el socket de Docker y leyó /etc/shadow. Otra cadena capturó una clave de inscripción y se unió a un nodo malicioso que parecía un servidor confiable. La propagación tomó menos de un segundo por salto. Sin contraseñas, sin claves robadas. 🔹Qué se ha confirmado, qué no🔹 ▫️ Todos los resultados son reproducciones de laboratorio, no brechas en el mundo real ▫️ El último boletín de Tailscale sigue siendo TS-2026-013. Nada sobre Tailworm, ninguna versión corregida ▫️ Mike Shaver, VP de Ingeniería, dice que están revisándolo y no recomiendan que todos desactiven Tailscale SSH. Su consejo: revisa las políticas SSH y el reenvío, activa las actualizaciones automáticas ▫️ La investigadora dice que fue "informado pero no coordinado". Críticos en HN califican el informe como ilegible ▫️ El atacante aún necesita un punto de entrada inicial: una aplicación web vulnerable, un paquete envenenado, un implant de phishing o credenciales robadas 🔹Por qué importa más allá de TI🔹 No es la primera vez este año. Los boletines TS-2026-006 y TS-2026-009 describieron rutas SSH hacia root, una a través de un nombre de usuario "-i". Ambas fueron corregidas en la versión 1.98.9. En julio, un agente de IA utilizó una única clave reutilizable de Tailscale para inscribir 181 nodos en la red de Hugging Face. No se necesitó ninguna vulnerabilidad. Muchos desarrolladores ejecutan bots, nodos RPC, validadores e agentes de IA en un VPS accesible únicamente a través de Tailscale. La malla es el perímetro. Una caja comprometida se convierte en el problema de todas las demás. 🔹Acciones prácticas para desarrolladores🔹 📝 Verifica si realmente lo usas. Abre tu archivo de política y lee la sección ssh. ¿No es necesario en un nodo? Ejecuta tailscale set --ssh=false. Mantén otro método de acceso primero, o te bloquearás tú mismo. 📝 OpenSSH normal sobre la tailnet aún funciona, y reduce los privilegios al usuario antes de iniciar la sesión. 📝 Reescribe las reglas SSH por par: una fuente, un destino. Ninguna regla por etiqueta o para todos los miembros. Los permisos por par fueron el único control que detuvo la propagación en el laboratorio. 📝 Deniega el reenvío en cada regla SSH a menos que lo necesites. En headscale 0.29.5 no puedes hacerlo, así que trata cada permiso SSH como root. 📝 Elimina los reenvíos serve que apunten a sockets Unix y los permisos de conectores de aplicaciones no utilizados. 📝 Activa la expiración de la clave del nodo y Tailnet Lock. Reemplaza las claves de autenticación reutilizables por claves únicas o efímeras. 📝 Si una caja se ve comprometida, bórrala desde el plano de control. Volver a instalar el sistema operativo no revoca claves que ya fueron copiadas. 📝 Activa las actualizaciones automáticas y vigila tailscale.com/security-bulletins. Mi tesis se fortalece si el boletín oficial confirma los hallazgos sobre reenvío e implementa una corrección para reducir privilegios. Se debilita si lo limita a headscale o configuraciones inusuales. La confianza cero es un archivo de política. No una propiedad del software. ¿Ejecutas Tailscale SSH en algo que contiene claves?
