Entre el 2 y el 5 de octubre de 2026, una campaña redirigió conexiones SSH a través de relays de salida de Tor manipulados. En el escaneo que publicó el 20 de octubre, el voluntario de Tor Kaba detectó 333 relays que enviaban el tráfico SSH a 12 servidores de interceptación, tras probar unos 3.000 relays de salida. El incidente afectó a una parte de esos relays, no al protocolo central de Tor.
Qué cuentan las cifras de 333 y 377 relays
Kaba usó exitmap y dos servidores de prueba para comprobar tanto la huella de la clave SSH del servidor como el origen de la conexión. Su escaneo identificó 333 relays que redirigían SSH a 12 servidores. En torno a una docena presentaba una huella falsa; más de 300 redirigían las conexiones sin cambiar por sí mismos la huella.
| Medición | Relays | Método y alcance |
| Redirecciones SSH detectadas por Kaba | 333 | Probó cerca de 3.000 relays con exitmap y comprobó la huella SSH y el origen de la conexión; encontró redirecciones a 12 servidores. |
| Coincidencias con un patrón de política de salida | 377 | Un análisis de datos de directorio publicado por The Hacker News contó relays cuya política coincidía con el patrón observado. Una coincidencia de política no demuestra por sí sola que un relay redirigiera SSH. |
Los recuentos miden cosas distintas: el de Kaba se basa en pruebas de redirección SSH; el de 377, en coincidencias de política de salida.
Cuándo podía quedar expuesta una contraseña SSH
La interceptación afectaba a conexiones SSH que salían de Tor hacia destinos ajenos a la red. Un relay de salida es el último repetidor del circuito Tor y conecta con ese destino. Las conexiones a un servicio onion permanecen dentro de Tor y no pasan por un relay de salida, así que no seguían la ruta descrita en este incidente.
El riesgo para una contraseña aparecía si el usuario aceptaba la clave del servidor interceptor y después introducía su contraseña. SSH puede advertir de que ha cambiado una clave de servidor que el usuario ya conocía. En una primera conexión, en cambio, puede mostrar la solicitud habitual para aceptar una clave nueva; por eso ambas situaciones no son equivalentes.
La autenticación del usuario con clave pública es otra comprobación distinta. En el método descrito, la firma de autenticación está ligada a esa sesión SSH y no podía reproducirse sin más ante el servidor real. Por tanto, ese método no permitía capturar una contraseña que el usuario no introdujera en el servidor interceptor.
Qué pasó con los puertos de correo
En dos relays Switzerland2 investigados por el operador Zimmer, la política bloqueaba los puertos 25, 465, 587, 993 y 995, y permitía los puertos 110 y 143, usados por POP3 e IMAP y capaces de transportar correo sin cifrar. El cambio podía dejar conexiones de correo expuestas a una degradación hacia texto plano. No se ha establecido que esa degradación llegara a producirse ni que se interceptaran mensajes.
Qué encontró Zimmer en dos servidores
Zimmer informó de que el 28 de agosto de 2026 un atacante accedió a su servidor de administración con una contraseña reutilizada y obtuvo permisos de administrador en cinco minutos. Según su reconstrucción, desde allí llegó a Switzerland2. El operador indicó que había reutilizado la misma contraseña para el acceso SSH, sudo y la frase de paso de una copia de seguridad, y que el servidor de administración aceptaba contraseñas SSH desde Internet.
Zimmer encontró la puerta trasera Ebury 1.8.3 en el servidor de administración y en Switzerland2. Ese hallazgo se refiere a los dos servidores que investigó; no demuestra que los 333 relays detectados por Kaba tuvieran Ebury.
Qué recomendó el Tor Project a los operadores
En un aviso del 5 de octubre de 2026, el Tor Project pidió a los operadores de relays Linux que revisaran la configuración de Tor, incluidos los archivos torrc, las políticas de salida y las reglas de red. También recomendó comprobar procesos, conexiones salientes, integridad de paquetes, usuarios, claves, tareas de cron y unidades de systemd.
Ante una sospecha de intrusión, el Tor Project recomendó retirar el relay de servicio, conservar los discos y registros, reinstalar el sistema en lugar de intentar limpiarlo, sustituir la identidad del relay y cambiar las credenciales presentes en el equipo. En los dos servidores que examinó Zimmer no había redirecciones NAT ni binarios de Tor modificados, y las comprobaciones de paquetes no detectaron Ebury. El operador documentó esos resultados en esos dos equipos.
