Unos atacantes tomaron el control de cientos de servidores de la red Tor y convirtieron 333 de sus nodos de salida en una trampa para interceptar conexiones SSH y robar contraseñas entre el 2 y el 5 de octubre. Lo detectó un investigador que firma como KABA, que avisó al Proyecto Tor el mismo 2 de octubre. Los nodos quedaron fuera de la red el día 5, y el equipo de salud de la red de Tor ha pedido a los operadores que revisen sus máquinas porque todavía no se sabe cómo entraron los atacantes en la mayoría de ellas.
Las claves del ataque a los nodos de salida de Tor en 20 segundos
- 333 nodos de salida de Tor redirigieron conexiones SSH a 12 servidores de intercepción.
- Solo se robaron contraseñas de quien ignoró el aviso de clave cambiada; las claves SSH no eran vulnerables.
- Los servidores llevaban infectados con el malware Ebury desde agosto y se desconoce cómo entraron los atacantes.
Tor protege el anonimato haciendo pasar el tráfico por tres servidores voluntarios. El último, el nodo de salida, es el que se conecta al destino final y puede ver el tráfico que no va cifrado de extremo a extremo. Por eso un nodo de salida malicioso es una amenaza conocida, pero el propio equipo de salud de la red de Tor reconoció, según el investigador, que no había visto antes un ataque de este tipo. Según su recuento, los nodos comprometidos eran alrededor del 10 % de los cerca de 3.000 nodos de salida de la red.
Cómo funcionaba el robo de contraseñas
Los atacantes entraron en los servidores Linux en agosto y desplegaron Ebury 1.8.3, una puerta trasera para OpenSSH que roba credenciales. A principios de octubre modificaron el fichero de configuración de Tor (torrc) para convertir en nodos de salida relés que no lo eran y cambiar su política de salida. Todo el tráfico SSH al puerto 22 se desviaba a uno de 12 servidores de intercepción que se hacían pasar por el destino real, mientras el resto del tráfico cifrado, como la navegación web, seguía su curso normal.
El usuario veía la advertencia de OpenSSH de que la identidad del servidor había cambiado. Si la ignoraba y escribía su contraseña, el atacante se la quedaba, abría una conexión paralela con el servidor real para que la sesión pareciera normal y observaba cada comando. Según KABA, con una segunda conexión infectaba además ese servidor con Ebury, lo que permitía extender el ataque. Quien se autenticaba con claves SSH estaba a salvo, porque la firma no se puede reenviar a través de un intermediario. Un análisis independiente de los datos del directorio de Tor encontró además que las políticas de salida modificadas bloqueaban los puertos de correo cifrado, como IMAPS y POP3S, y dejaban abiertos los no cifrados, lo que el investigador interpreta como un intento de capturar correo en claro.
KABA lo descubrió el 2 de octubre al recibir el aviso de identidad cambiada en una conexión propia. Después probó los cerca de 3.000 nodos de salida con la herramienta exitmap, lanzando conexiones SSH entre dos servidores suyos a través de cada uno. Una docena mostraba una huella falsa del servidor y más de 300 desviaban el tráfico a los servidores de intercepción. Un señuelo SSH le permitió ver que los atacantes usaban la librería paramiko de Python y ejecutaban un comando en Perl codificado en base64 para instalar Ebury.
Las cifras no coinciden del todo
Los 333 nodos son los que KABA vio redirigir el tráfico SSH. Un análisis publicado el 9 de octubre en la lista de correo de operadores de Tor, a partir de los datos públicos del directorio, contó 377 relés de 59 operadores, repartidos en 147 servidores y 15 redes de proveedores distintos, que adoptaron la misma política de salida entre el 1 y el 4 de octubre. Su autor advierte de que coincidir en la política no prueba que el relé estuviera comprometido. En su punto máximo, el 4 de octubre, esos nodos sumaban el 7,46 % de la capacidad de salida de la red, y el 9 de octubre solo quedaba uno visible, marcado como malicioso. Un 34 % de esos relés estaba alojado en el proveedor FranTech.
El equipo de salud de la red de Tor confirmó el incidente el 5 de octubre en un aviso a los operadores, sin dar cifras. Los nodos afectados se marcaron para que los clientes dejaran de usarlos como salida y las autoridades del directorio los rechazaron. Para los usuarios de Tor, el riesgo real se limita a quien se conectó por SSH con contraseña a través de la red en esos días y aceptó el aviso de cambio de clave. Aun así, conviene revisar cualquier servidor al que se haya accedido así.
Una contraseña reutilizada en el origen
El operador de la familia de relés Quetzalcoatl, la más afectada con 277 de los 377 relés según el análisis, publicó el 7 de octubre un informe sobre dos de sus servidores infectados. Atribuye la causa a errores propios: una misma contraseña para el acceso SSH, sudo y la clave de una copia de seguridad, guardada además en texto plano en un script, y el acceso por contraseña activado en un servidor de gestión expuesto a Internet. El atacante entró en ese servidor al primer intento el 28 de agosto, lo que hace pensar que ya conocía la contraseña, y desde allí llegó al resto. Sigue sin saberse de dónde la sacó, ni cómo se comprometieron los servidores de otros operadores.
Las recomendaciones coinciden en todas las fuentes. Para administradores de servidores: desactivar el acceso SSH por contraseña y usar solo claves, no reutilizar contraseñas, no ignorar nunca el aviso de identidad cambiada y no escribir una contraseña en un servidor sospechoso, porque Ebury la captura. Ebury es difícil de detectar: es un único fichero que se hace pasar por la librería libkeyutils y escapa a las comprobaciones de paquetes como dpkg -V. ESET, que estimó en 2024 unos 400.000 servidores infectados por Ebury desde 2009, publica un script de detección. A los operadores de Tor, el proyecto les pide revisar el torrc y la política de salida, buscar reglas que desvíen el puerto 22 y usuarios o tareas desconocidos, y, si hay sospecha, reinstalar desde cero, generar una nueva identidad para el relé, cambiar todas las credenciales y escribir a [email protected]. Son lecciones parecidas a las de otros fallos recientes de SSH, como el de MikroTik RouterOS o ssh-keysign-pwn en Linux.
Preguntas frecuentes
¿Qué pasó con los nodos de salida de Tor?
Entre el 2 y el 5 de octubre de 2026, 333 nodos de salida comprometidos desviaron las conexiones SSH a servidores de los atacantes para robar contraseñas. Ya están fuera de la red.
¿Estoy afectado si uso Tor Browser?
El ataque se centró en conexiones SSH. Solo corrió riesgo quien se conectó por SSH a través de Tor en esas fechas, usando contraseña y aceptando el aviso de que la clave del servidor había cambiado.
¿Qué es Ebury?
Una puerta trasera para OpenSSH en Linux que roba credenciales. ESET estimó en 2024 que había infectado unos 400.000 servidores desde 2009.
¿Cómo me protejo de un ataque así?
Usando autenticación SSH con claves en lugar de contraseñas, sin reutilizar contraseñas y sin ignorar nunca el aviso de que la identidad del servidor ha cambiado.
Fuentes:
- KABA: How I got over 300 Tor exit nodes removed
- Tor Project, lista tor-relays: aviso del equipo de salud de la red a los operadores (5 de octubre)
- Tor Project, lista tor-relays: informe del operador de Quetzalcoatl sobre Ebury 1.8.3 (7 de octubre)
- Tor Project, lista tor-relays: análisis de las políticas de salida modificadas (9 de octubre)
- ESET: script de detección de Ebury
