333 relés de salida de Tor desviaron SSH e inclinaron el correo hacia texto plano

Aproximadamente uno de cada diez relés de salida de Tor se convirtió discretamente en una trampa de contraseñas SSH a principios de octubre. Un investigador que publica bajo el seudónimo kaba analizó el 2 de octubre las unas 3.000 salidas de Tor y encontró 333 que redirigían SSH hacia los mismos 12 servidores de interceptación. Ningún elemento de la criptografía de Tor falló. Los atacantes tomaron el control de los hosts Linux que sustentan los relés y reescribieron un archivo de texto.

01Cómo se manipularon los relés

Un relé de salida solo transporta tráfico hacia los puertos que permite su política de salida, y esa política reside en el archivo de configuración torrc del relé. Desde el 1 de octubre, los atacantes reescribieron esas políticas para abrir el puerto 22. Con ello habilitaron SSH en 342 relés que lo habían bloqueado y convirtieron 24 relés que no eran de salida en relés de salida.

La única vía de entrada documentada por completo es la propia infraestructura de un operador de relés, no los sistemas del Tor Project. El resumen de Ars Technica lo llama «servidor de administración de Tor», pero el análisis posterior al incidente lo describe de otro modo. Se trataba del VPS de Contabo del operador, que hacía de pasarela WireGuard, host de salto SSH y puente obfs4. Una segunda máquina, Switzerland2, era un VPS de FranTech que ejecutaba dos de los relés de salida del operador. El atacante usó la contraseña del operador, que funcionó al primer intento, y obtuvo acceso root cinco minutos después. Esto coincide con el relato de Ars sobre una contraseña reutilizada.

En ese servidor se instaló Ebury 1.8.3. Aproximadamente una hora después, Switzerland2 aceptó un inicio de sesión con una clave RSA que no figuraba en ninguno de sus archivos authorized_keys, y Ebury se instaló allí un segundo más tarde. El operador afirma que sigue sin saberse cómo se aceptó esa clave. Marc-Etienne Léveillé, que lleva 13 años siguiendo la pista a Ebury, sugirió en la lista de correo que Ebury pudo haber estado presente antes y haberse actualizado el 30 de septiembre. También planteó como posibilidad que el proveedor de alojamiento estuviera comprometido.

El propio análisis posterior del operador muestra cómo reescribió el atacante la política en Switzerland2. Se eliminó la lista de aceptación de 60 rangos de puertos generada con ansible por el operador. Se añadieron cinco líneas de rechazo para los puertos 25, 465, 587, 993 y 995 tras «# end of torrc». Los dos relés de Switzerland2 publicaron el resultado a las 09:34:04 del 2 de octubre.

Cómo cayeron los demás relés sigue sin resolverse. Ars señala que los investigadores no han establecido cómo se tomaron los 333 servidores subyacentes. Con todo, un patrón apunta al alojamiento: 71 de los 101 relés de terceros en FranTech Solutions cambiaron, frente a 13 de los 9.054 relés alojados en otros lugares. Es una correlación, no una prueba de que el proveedor haya sido vulnerado.

02Las dos cargas: SSH y correo

SSH. El tráfico al puerto 22 salía de las salidas comprometidas hacia uno de los 12 interceptores. El interceptor presentaba su propia clave de host, registraba cualquier contraseña escrita y luego iniciaba sesión en el servidor real para que la sesión pareciera normal. Un usuario que ignorara la advertencia de OpenSSH sobre el cambio de clave de host exponía, por tanto, sus credenciales y daba al atacante una vista en vivo de la sesión. Ars informa además de un tercer paso: el atacante abría otra conexión para intentar instalar Ebury en el destino. En el honeypot de kaba, el cliente del atacante se identificó como paramiko, comprobó el ID de usuario y el sudo sin contraseña, y después ejecutó un comando Perl codificado en base64 para instalar Ebury.

La detección fue más difícil de lo que sugiere la advertencia. Solo una docena de salidas servía una clave de host falsa. Las otras 300 aproximadamente redirigían el tráfico por los mismos servidores sin cambiar la clave. Un usuario que llegara a un servidor a través de una de esas salidas no vería nada extraño, pero el servidor vería una conexión desde la dirección de un interceptor y no desde la de la salida.

Correo. El cambio en el correo es más sutil de lo que sugiere el resumen de Ars, porque no todos los puertos bloqueados son exclusivamente cifrados. El análisis del operador clasifica 25, 587 y el par 110/143 como «TLS opcional». Solo 465, 993 y 995 son puertos de TLS implícito. La política final bloqueaba el envío de correo y la lectura cifrada, pero dejaba abiertos POP3 (110) e IMAP (143) en texto plano. El operador señala además que la primera política que probó el atacante era la inversa: bloqueaba POP3 e IMAP en texto plano y fue sustituida por la que entró en producción.

La inferencia es que los clientes configurados para intentar TLS y recurrir a texto plano si falla acabarían empujados al texto sin cifrar. Un relé de salida lee todo lo que sale en claro, y además puede eliminar la negociación STARTTLS. En la mayoría de los relés, el cambio también abrió POP3 e IMAP en texto plano. Se desconoce si algún cliente de correo llegó realmente a degradar la conexión, como señala Ars.

03Alcance, duración y limpieza

Ars sitúa el secuestro entre el 2 y el 5 de octubre. Otros relatos cuentan de forma distinta la ventana de la política. La política de Switzerland2 estuvo activa unas 52 horas en dos relés Guard+Exit que movían aproximadamente 3,4 TiB al día. El propio Ebury es muy anterior a la campaña. ESET estimó en 2024 que había infectado a unos 400.000 servidores Linux desde 2009.

• Cuota de la red: En el pico, el 4 de octubre a las 01:00 UTC, los relés secuestrados transportaban el 7,46 % del peso de salida utilizable de Tor.
• Coincidencia de política más amplia: Un análisis de los datos del directorio contabilizó 377 relés operados por 59 operadores que adoptaron la política de salida del atacante entre el 1 y el 4 de octubre. El propio análisis lo califica de coincidencia de política, no de prueba de compromiso.
• Respuesta: Kaba lo comunicó en la tarde del 2 de octubre. Las autoridades de directorio empezaron a aplicar BadExit en la tarde del 4 de octubre y, a las 17:00 UTC del 5 de octubre, ya no quedaba en el consenso ningún relé con la política del atacante. Cuando los atacantes reiniciaron muchos relés el 5 de octubre, las banderas los limitaron a funciones de relé intermedio.

Kaba afirma que el equipo de salud de la red Tor le dijo que no había visto antes un ataque como este.

04Qué dice esto del modelo de confianza de Tor

Tor separa quién eres de lo que envías, pero no protege el contenido una vez que sale por la salida. El consejo de siempre del Tor Project es usar cifrado de extremo a extremo, como HTTPS, porque la salida ve el tráfico en claro. El abuso de relés de salida no es nuevo. Un estudio de la Universidad de Karlstad de 2014 encontró 19 relés de salida que usaban certificados autofirmados para ataques de intermediario contra HTTPS y SSH. En 2020, el investigador nusenu informó de que los atacantes llegaron a operar 380 relés de salida en su punto álgido, lo que daba a los usuarios aproximadamente una probabilidad entre cuatro de usar una salida maliciosa.

Lo distintivo aquí es el mecanismo. Eran relés de operadores honestos, alterados mediante un compromiso ordinario del host, y la política de salida fue la palanca. El equipo de Network Health describió al atacante como alguien que editaba archivos torrc para convertir relés que no eran de salida en relés de salida. La defensa que funcionó fue la observación externa: el escaneo con exitmap, los datos del directorio y un investigador que se negó a pasar por alto una advertencia. La visión a nivel de familia también ayuda. La consulta de Onionoo del operador mostró 168 relés en 57 IP que anunciaban la misma política casi abierta. La red Tor confía en que los hosts de los voluntarios no estén comprometidos, y una sola credencial filtrada puede escalar hasta un evento a escala de red.

05Detección y mitigación

Para usuarios y administradores de SSH:

1. Trate una advertencia de cambio de clave de host como un incidente. Quien haya escrito una contraseña tras aceptar una clave nueva debe considerarla robada, rotarla y comprobar si el destino tiene Ebury.
2. Desactive la autenticación por contraseña en favor de claves, como recomienda Ars. Así, un ataque de intermediario no captura nada reutilizable. Fije las claves de host con comprobación estricta o use certificados SSH.
3. Siempre que sea posible, acceda a los servicios administrativos mediante un servicio onion para que no intervenga ninguna salida. Es una práctica general y no algo que traten las fuentes.
4. Use TLS implícito (465, 993, 995) y configure los clientes para que rechacen el texto plano en lugar de recurrir a él.

Para operadores de relés y equipos de red:

• Configure alertas ante cualquier cambio de política de salida que no haya hecho su gestión de configuración. Compare el descriptor publicado con el previsto.
• Ejecute sondas canario a través de las salidas, como hizo kaba, comprobando tanto la clave presentada como la dirección de origen que ve el destino.
• No reutilice contraseñas de operador y exija acceso solo con clave en los hosts de salto.
• Asuma que un host de apariencia limpia puede no estarlo. Ebury 1.8.3 es más reciente que los indicadores públicos de ESET, y el operador no encontró redirección NAT, usuarios nuevos ni un binario de tor modificado. Los inicios de sesión por la puerta trasera no dejan registros de acceso ni historial de shell. Los expertos aconsejan retirar los relés, hacer una instantánea del disco y reconstruir desde cero en lugar de limpiar in situ.

06Lo que sigue sin demostrarse

Varias preguntas siguen abiertas: cómo se accedió a los demás relés, por qué Switzerland2 aceptó la clave no listada y quién está detrás. Kaba dice que el uso de Ebury y el barrido de datos sin cifrar apuntan a un grupo con motivación económica, pero advierte de que es una especulación. Para Léveillé, dado el alcance de Ebury, lo más probable es que haya otros relés de Tor comprometidos. Nadie ha demostrado cuántas contraseñas se capturaron ni si algún correo fue degradado.