Un atacante tomó el control de 333 nodos de salida de Tor y los convirtió en una plataforma de recolección de datos. Las sesiones SSH que pasaban por los nodos comprometidos se redirigían a uno de 12 servidores de interceptación, mientras que se bloqueaban los puertos usados para el envío y la recepción de correo cifrado. Así, los mensajes podían leerse en texto plano si un servicio recurría a una conexión sin cifrar. La información procede de un informe de Ars Technica firmado por Dan Goodin, que se basa en una publicación y una investigación de un voluntario de Tor identificado como Kaba, así como en declaraciones de otros voluntarios.
La escala importa porque la red es pequeña. El artículo sitúa a Tor en unos 3.000 nodos de salida, así que los nodos secuestrados representan aproximadamente una décima parte de las salidas por las que puede salir el tráfico.
Una contraseña reutilizada, Ebury y el salto a Switzerland2
Según los voluntarios de Tor citados en el informe, la intrusión comenzó a finales de agosto, mientras que el secuestro en sí se produjo entre el 2 y el 5 de octubre. El punto de entrada fue una contraseña válida que se había reutilizado en un servidor de administración de Tor. Desde allí, el atacante instaló Ebury, una puerta trasera para Linux que, según el artículo, se descubrió 12 años antes. Después abrió una conexión SSH desde ese servidor de administración hacia una segunda máquina de Tor, llamada Switzerland2.
Ese segundo salto usó una clave RSA que los investigadores no encontraron entre las claves autorizadas de Switzerland2. Ebury también se instaló en Switzerland2, y se reconfiguraron dos nodos de salida alojados en esa máquina. Los voluntarios no han establecido cómo obtuvo el atacante el control del resto de servidores subyacentes. Una de las teorías que han planteado, según la cual una empresa de hosting habría sido comprometida, se describe como no concluyente.
Cómo se capturó el tráfico SSH y cómo se convirtió en más infecciones
La investigación de Kaba halló que el tráfico SSH por el puerto 22 que atravesaba los nodos comprometidos se redirigía a los 12 servidores controlados por el atacante. Cuando los usuarios ignoraban la advertencia de cambio de clave de host, el atacante les robaba la contraseña SSH, abría una conexión con el servidor de la víctima y observaba todos los comandos escritos. Después abría una segunda conexión e infectaba el servidor con Ebury.
La huella digital que mostraba la advertencia falsificada es SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E. El texto de la advertencia es el mensaje estándar del cliente que empieza con "REMOTE HOST IDENTIFICATION HAS CHANGED". Quien aceptara una clave nueva de un nodo de salida durante el periodo afectado debería considerar sospechosas tanto las credenciales usadas en esa sesión como el servidor del otro extremo.
Correo: bloqueo de los puertos cifrados
En el caso del correo, los nodos comprometidos bloquearon los puertos 25, 465, 587, 993 y 995, que son los usados para el envío y la recepción cifrados, y dejaron abiertos los puertos para recibir correo sin cifrar. El efecto era empujar el tráfico hacia conexiones que el atacante podía leer si un servicio de correo degradaba la conexión. El informe no establece si algún intento de degradación llegó a tener éxito.
El script de sondeo y el honeypot que lo delató
La compromisión salió a la luz gracias a un método de comprobación, no a un chivatazo. Un script consultaba cada nodo de salida para comprobar si presentaba la huella SSH correcta de un servidor de pruebas. Ese servidor también registraba si una conexión entrante procedía de un nodo de salida fijado o de uno de los 12 servidores de interceptación. Se desplegó un honeypot para observar cómo el software de interceptación intentaba iniciar sesión e instalar Ebury. El secuestro comenzó a finales de agosto y se produjo entre el 2 y el 5 de octubre. La conexión de prueba de Kaba fue redirigida un viernes por la mañana, y el informe del investigador se publicó un martes.
La atribución sigue siendo una especulación
Kaba afirmó que el uso de Ebury, junto con la recolección masiva de datos sin cifrar, apunta a un grupo criminal motivado por el dinero. Además, lo describió explícitamente como una especulación. El artículo no identifica quién está detrás de la campaña.
Medidas prácticas para quien usó estos nodos
Las medidas que recoge el artículo apuntan directamente a lo que aprovechó el atacante. En el lado del cliente, acepta solo tráfico de correo cifrado y rechaza los puertos sin cifrar. Desactiva la autenticación por contraseña en SSH y usa inicios de sesión basados en claves, frente a los cuales las credenciales capturadas no habrían servido. Por último, trata un cambio inesperado de clave de host como un posible ataque de intermediario (man-in-the-middle) y no como una molestia que se pueda aceptar sin más. La propia advertencia pide contactar con el administrador del sistema, y verificar la nueva clave por un canal distinto es la única forma de distinguir una rotación legítima de un servidor de interceptación.
