Tor: 333 nodos de salida con un backdoor SSH

333 nodos de salida de Tor infectados con un backdoor SSH

El viernes 2 de octubre a las 09:35, 333 nodos de salida de Tor arrancaron una campaña coordinada para interceptar conexiones SSH y recolectar la mayor cantidad de tráfico sin cifrar posible. Para dimensionarlo: la red tiene alrededor de 3.000 exit relays, así que cerca del 10% quedó bajo control de los atacantes.

Para cualquier equipo que corre infraestructura propia, la noticia no es que Tor esté roto. La noticia es el método: alguien consiguió entrar en servidores Linux ajenos, los convirtió en nodos de salida y desde ahí se puso en el medio de conexiones SSH de terceros. Ese mismo patrón, comprometer un host, darle una nueva función y usarlo de trampolín, es el que golpea a startups que dejan SSH abierto con contraseña.

Cómo funcionó el ataque

Los atacantes habían entrado en los servidores dos meses antes, en agosto, y de forma silenciosa desplegaron su payload Ebury 1.8.3, un backdoor de OpenSSH y ladrón de credenciales para Linux.

El ataque tuvo dos objetivos:

• Recolectar la mayor cantidad posible de tráfico de correo sin cifrar.
• Interceptar conexiones SSH mediante un ataque man-in-the-middle.

Para el primero, bloquearon ciertos puertos de modo que sus nodos de salida manejaran sobre todo correo sin cifrar. Para el segundo, el mecanismo fue más quirúrgico: si tu circuito salía por uno de los 333 nodos infectados, al principio no notabas nada. El tráfico web cifrado se reenviaba con normalidad, pero si intentabas una conexión SSH por el puerto 22, te redirigían sin que lo supieras a uno de 12 servidores de intercepción.

Ahí aparecía la única señal visible: la advertencia de que la identificación del host remoto había cambiado, con un fingerprint de clave ED25519 distinto al esperado. Si la ignorabas y seguías con el login, el atacante hacía tres cosas: robaba tu contraseña, abría una conexión a tu servidor para observar cada comando que escribías y abría una segunda conexión para infectar ese servidor con Ebury.

La línea de tiempo: 48 horas para tumbarlos

La respuesta fue rápida y coordinada, y conviene leerla como un caso de gestión de incidentes:

• Viernes 2 de octubre: arranca la intercepción.
• Viernes por la noche: quien detectó el ataque contacta al equipo de salud de red de Tor Project, que confirma que es algo nuevo. Desde el equipo reconocieron que no habían visto un ataque así antes.
• Domingo 4 de octubre: el equipo anuncia el incidente a los operadores, que empiezan a apagar sus nodos de salida, y los relays quedan marcados como BadExit para que los clientes dejen de usarlos.
• Lunes 5 de octubre: los atacantes reinician muchos relays, pero al estar ya marcados solo pueden operar como nodos intermedios.
• Lunes 5 de octubre: todos los servidores infectados quedan apagados, en parte por los operadores y en parte por los propios atacantes.

En el anuncio, el equipo de salud de red describió el patrón: cuando el atacante lograba acceso a un host Linux que no era de salida, editaba el archivo torrc para convertirlo en nodo de salida y así poder ejecutar el ataque SSH. El impacto es visible en las métricas públicas de la red: hay una caída clara el 4 de octubre que no se ha recuperado desde entonces.

¿Cómo se detectaron los 333 nodos?

El hallazgo no esperó a que alguien más lo hiciera. Con exitmap se armó un script que fijaba un nodo de salida y abría una conexión SSH desde un servidor A hacia un servidor B. El servidor A verificaba si recibía el fingerprint SSH correcto del servidor B; el servidor B comprobaba si la conexión llegaba desde el nodo fijado o desde uno de los 12 servidores de intercepción.

El script corrió contra los ~3.000 relay de salida. Alrededor de una docena servían un fingerprint falso, y más de 300 no interceptaban nada pero redirigían a través de esos mismos servidores. Redirigir ya era suficiente para confirmar que el nodo estaba infectado.

Después se usó sshesame como honeypot. Al engañar al atacante para que iniciara sesión en la trampa, apareció la firma técnica: usaban paramiko, una librería SSH de Python, y ejecutaban comandos en Perl para instalar Ebury, comprobando primero permisos con sudo -n true y luego pasando un comando codificado en base64.

¿Qué significa esto para tu startup?

Hay tres lecciones que aplican aunque nunca toques la red Tor.

Primero, el eslabón débil casi nunca es el protocolo: es el host. El ataque no rompió el cifrado de SSH. Consiguió acceso a servidores Linux, los reconvirtió y desde ahí se puso en el medio. Si tus servidores de producción aceptan login SSH con contraseña, tu superficie de ataque se parece bastante a la de esos relays.

Segundo, la advertencia REMOTE HOST IDENTIFICATION HAS CHANGED es la última línea de defensa y es muy fácil de ignorar. Ese mensaje existe justamente para este escenario, y basta con que un desarrollador lo acepte por costumbre, asumiendo que es un cambio de IP, para que le roben la contraseña y le infecten el servidor.

Tercero, la operación duró meses: acceso en agosto, ataque en octubre. La detección temprana de cambios de configuración en los servidores es lo que separa un incidente contenido de una campaña de robo de credenciales a escala.

Acciones concretas para tu equipo

• Desactiva la autenticación por contraseña en SSH y usa claves. Es la recomendación explícita de quien detectó el ataque.
• Suma llaves de hardware para los accesos críticos de infraestructura y para las cuentas con permisos de administración.
• Monitorea fingerprints y known_hosts. Una alerta ante un host key inesperado vale más que cualquier regla genérica de firewall.
• Revisa qué servicios expones en puertos como el 22 y cierra todo lo que no uses o restringe su acceso por origen.
• Trata tus servidores como máquinas de producción altamente expuestas. Como resumió George, operador de relay, en la lista de correo del proyecto, los relays y bridges deben tratarse como máquinas de producción altamente atacadas. Tus servidores merecen el mismo criterio.

Preguntas abiertas

El cómo sigue sin respuesta. La teoría que circula es que la empresa de hosting pudo haber sido comprometida, pero nadie lo ha confirmado. Tampoco se sabe quién está detrás: el uso de Ebury y la recolección masiva de tráfico sin cifrar apuntan a un grupo criminal con motivación económica, aunque eso también es especulación.

Un dato del hilo sí resulta incómodo. Como señaló Marc-Etienne M. Léveillé, entre 2009 y 2023 hubo alrededor de 400.000 servidores con Ebury, lo que sugiere que es probable que sigan existiendo relays comprometidos que nadie ha detectado. Y el detalle de que el ataque arrancara un viernes, apostando a que nadie querría arruinar su fin de semana respondiendo, dice bastante sobre cómo opera este tipo de actor.

Conclusión

El caso de los 333 nodos de salida es un recordatorio poco amable pero útil: la seguridad de tu producto no termina en tu código. Termina en cada host que puedes alcanzar por SSH, en cada credencial que reutilizas y en cada advertencia que decides ignorar. La red Tor perdió cerca del 10% de su capacidad de salida en cuestión de días y todavía no se ha recuperado. Una startup con un servidor comprometido puede perder mucho más y no enterarse hasta que el atacante ya vendió las credenciales.

Fuentes

• How I got over 300 Tor exit nodes removed (fuente original)

No se encontraron datos adicionales verificables en fuentes externas al momento de publicar esta nota.