Relés de salida de Tor: 333 nodos roban contraseñas SSH

Más de 300 relés de salida de Tor pasaron cinco días desviando conexiones para robar contraseñas SSH. Entre el 1 y el 5 de octubre, quien entró a un servidor por medio de Tor, aceptó una clave de servidor desconocida y escribió su contraseña pudo entregarla a un interceptor sin notar nada raro: la sesión funcionaba igual que siempre.

La exposición fue estrecha. Hacía falta salir por un relé tomado, caer en uno de los 12 servidores de interceptación, aceptar la clave falsa y usar contraseña en vez de llave criptográfica. Quien las reúna debe dar esa contraseña por robada y cambiarla hoy.

Primero abrieron el puerto 22, después presentaron una clave falsa

Un relé de salida solo transporta tráfico hacia los puertos que su política permite. Los atacantes reescribieron esa política en el archivo torrc: activaron el puerto 22, el de SSH, en 342 relés que lo tenían bloqueado y volvieron salidas a 24 equipos que no lo eran.

Con el puerto abierto, la conexión ya no llegaba a su destino: salía hacia uno de 12 servidores de interceptación que presentaba su propia clave. Si el usuario conocía la clave real, OpenSSH avisaba que la identificación del equipo remoto había cambiado; si entraba por primera vez, veía la pregunta habitual para aceptar una clave nueva.

Aceptar era el error completo. El interceptor leía la contraseña, se conectaba al servidor verdadero y dejaba trabajar a la víctima mientras observaba sus comandos. En el servidor señuelo de kaba, el paso siguiente fue un instalador en Perl codificado en base64, el mismo tipo de comando usado para plantar Ebury, una puerta trasera dentro de OpenSSH. La llave criptográfica no cayó en el truco: su firma lleva un identificador único de sesión y no sirve en otra conexión.

Kaba lo detectó por un aviso que casi todo el mundo pasa de largo

Todo empezó con ese aviso. La mañana del 2 de octubre, una conexión SSH de kaba por medio de Tor devolvió la advertencia de clave cambiada. El investigador barrió los cerca de 3.000 relés de salida de Tor con la herramienta exitmap, contó 333 desviando SSH hacia los mismos 12 servidores y reportó el hallazgo al equipo de salud de red del Proyecto Tor.

El análisis del directorio amplió la foto: 377 relés de 59 operadores cambiaron a la política del atacante entre el 1 y el 4 de octubre, con un pico del 7,46 % de la capacidad de salida de la red. El análisis aclara que esa coincidencia no prueba que cada equipo estuviera comprometido.

La respuesta tomó tres días. El 4 de octubre las autoridades del directorio votaron las marcas BadExit y MiddleOnly; el 5, un reinicio programado recorrió 55 equipos de la familia más afectada sin efecto, y a las 17:00 UTC ya no quedaba en el consenso ningún relé de salida de Tor con la política del atacante.

Ebury dormía dentro de los servidores de la familia más grande

Zimmer, operador de Quetzalcoatl, la familia más afectada, publicó su examen forense el 7 de octubre: dos de sus servidores corrían Ebury 1.8.3. El atacante entró el 28 de agosto a su servidor de gestión con una contraseña reutilizada —la misma para SSH, para administrar y para la copia de seguridad, en texto claro— y en cinco minutos controlaba el equipo.

Ebury lleva años en circulación. Datos de ESET lo sitúan activo desde 2009, con unos 400.000 servidores infectados a lo largo de los años. En los equipos de Zimmer se disfrazó de biblioteca del sistema, sobrevivió a un reinicio y su versión 1.8.3 superaba los indicadores públicos de ESET, que llegan hasta la 1.8.2.

Cómo entraron en los equipos de los demás operadores sigue sin respuesta. El análisis encontró una concentración en FranTech, proveedor detrás de BuyVM: 71 de 101 relés alojados allí cambiaron de política, frente a 13 de 9.054 en otras redes. Se habla de una brecha en el proveedor, sin confirmación; tampoco hay atribución ni código CVE asociado.

Si usaste Tor para administrar un servidor, esto toca hacerlo ahora

La tarea del usuario es corta: revisar si entre el 1 y el 5 de octubre aceptó una clave nueva o cambiada al entrar por SSH vía Tor. Si fue así, esa contraseña se trata como robada: se cambia en el servidor, se rota donde se repita y la entrada pasa a llaves criptográficas, con la contraseña desactivada.

Los operadores de relés tienen la lista larga del aviso del Proyecto Tor: revisar torrc en busca de cambios en la política de salida, buscar redirecciones del puerto 22, procesos desconocidos, usuarios nuevos y tareas programadas. La revisión se hace desde un sistema de rescate o una imagen del disco sin conexión, sin escribir contraseñas en un servidor sospechoso: Ebury las capturaría.

Con una señal de compromiso, la instrucción es tajante: sacar el relé de la red, guardar disco y registros como evidencia, reinstalar desde cero en lugar de limpiar, crear una identidad nueva y rotar cada credencial suya. El implante de Zimmer volvió tras un reinicio; borrar archivos sueltos no alcanza.

Quién montó la operación y cuántas contraseñas SSH cambiaron de manos en cinco días son preguntas sin respuesta, sin conteo de víctimas. El dato frío está en Tor Metrics: la red sigue con unos 370 relés de salida menos que a principios de octubre.

Fuente: The Hacker News

Foto: The Hacker News

La entrada Relés de salida de Tor: 333 nodos roban contraseñas SSH se publicó primero en Tecnología Geek.