Un ataque involucra a miles de usuarios web en una botnet para descifrar contraseñas

Los atacantes han transformado cientos de sitios pirateados que ejecutan software WordPress en servidores de comando y control que obligan a los navegadores de los visitantes a realizar ataques para descifrar contraseñas.

A búsqueda Web El JavaScript que realiza el ataque mostró que estaba alojado en 708 sitios en el momento en que esta publicación se publicó en Ars, en comparación con 500 hace dos días. Denis Sinegubko, el investigador que descubrió la campaña, dijo en ese momento que había visto miles de computadoras de visitantes ejecutando el script, lo que los llevó a acceder a miles de dominios en un intento de adivinar las contraseñas de los nombres de usuario con cuentas.

Visitantes reclutados sin saberlo

“Así es como miles de visitantes en cientos de sitios web infectados, sin saberlo y simultáneamente, intentan forzar a miles de otros sitios de WordPress de terceros”, Sinegubko escribió. “Y dado que las solicitudes provienen de los navegadores de visitantes reales, se puede imaginar que es un desafío filtrar y bloquear dichas solicitudes”.

Al igual que los sitios web pirateados que alojan JavaScript malicioso, todos los dominios objetivo ejecutan el sistema de gestión de contenidos WordPress. El script, de sólo 3 kilobits de tamaño, llega a un getTaskURL controlado por el atacante, que a su vez proporciona el nombre de un usuario específico en un sitio específico de WordPress, junto con 100 contraseñas comunes. Cuando estos datos se introducen en el navegador que visita el sitio pirateado, intenta iniciar sesión en la cuenta de usuario objetivo utilizando las contraseñas candidatas. JavaScript opera en un bucle, solicita tareas de getTaskURL, informa los resultados a completeTaskURL y luego realiza los pasos una y otra vez.

A continuación aparece un fragmento del JavaScript alojado y, debajo, la tarea resultante:

const getTaskUrl = 'hxxps://dynamic-linx[.]com/getTask.php';
const completeTaskUrl = 'hxxps://dynamic-linx[.]com/completeTask.php';
…

[871,"https://REDACTED","redacted","60","junkyard","johncena","jewish","jakejake","invincible","intern","indira","hawthorn","hawaiian","hannah1","halifax","greyhound","greene","glenda","futbol","fresh","frenchie","flyaway","fleming","fishing1","finally","ferris","fastball","elisha","doggies","desktop","dental","delight","deathrow","ddddddd","cocker","chilly","chat","casey1","carpenter","calimero","calgary","broker","breakout","bootsie","bonito","black123","bismarck","bigtime","belmont","barnes","ball","baggins","arrow","alone","alkaline","adrenalin","abbott","987987","3333333","123qwerty","000111","zxcv1234","walton","vaughn","tryagain","trent","thatcher","templar","stratus","status","stampede","small","sinned","silver1","signal","shakespeare","selene","scheisse","sayonara","santacruz","sanity","rover","roswell","reverse","redbird","poppop","pompom","pollux","pokerface","passions","papers","option","olympus","oliver1","notorious","nothing1","norris","nicole1","necromancer","nameless","mysterio","mylife","muslim","monkey12","mitsubishi"]

Con 418 lotes de contraseñas hasta el martes, Sinegubko concluyó que los atacantes están probando 41.800 contraseñas en cada sitio objetivo.

Sinegubko escribió:

Etapas de ataque y ciclo de vida.

El ataque consta de cinco etapas clave que permiten a un mal actor aprovechar sitios web ya comprometidos para lanzar ataques distribuidos de fuerza bruta contra miles de otros sitios potenciales víctimas.

• Etapa 1: obtener las URL de los sitios de WordPress. Los atacantes rastrean Internet ellos mismos o utilizan varios motores de búsqueda y bases de datos para obtener listas de sitios de WordPress objetivo.
• Etapa 2: extraer los nombres de usuario de los autores. Luego, los atacantes escanean los sitios de destino y extraen nombres de usuarios reales de los autores que publican en esos dominios.
• Etapa 3: inyectar scripts maliciosos. Los atacantes luego inyectan sus linx dinámico[.]es/chx.js script a sitios web que ya han comprometido.
• Etapa 4: Credenciales de fuerza bruta. Cuando los visitantes normales del sitio abren páginas web infectadas, se carga el script malicioso. Detrás de escena, los navegadores de los visitantes llevan a cabo un ataque distribuido de fuerza bruta en miles de sitios objetivo sin ninguna participación activa de los atacantes.
• Etapa 5: verificar las credenciales comprometidas. Los malos actores verifican las credenciales por fuerza bruta y obtienen acceso no autorizado a los sitios objetivo de la etapa 1.

Entonces, ¿cómo logran los atacantes realmente un ataque distribuido de fuerza bruta desde los navegadores de visitantes de un sitio web completamente inocentes y desprevenidos? Echemos un vistazo más de cerca a la etapa 4.

Pasos del ataque de fuerza bruta distribuida:

1. Cuando un visitante del sitio abre una página web infectada, el navegador del usuario solicita una tarea al hxxps://dinámico-linx[.]es/getTask.php URL.
2. Si la tarea existe, analiza los datos y obtiene la URL del sitio a atacar junto con un nombre de usuario válido y una lista de 100 contraseñas para probar.
3. Para cada contraseña de la lista, el navegador del visitante envía la wp.uploadArchivo XML-RPC Solicitud de API para cargar un archivo con las credenciales cifradas que se utilizaron para autenticar esta solicitud específica. ¡Son 100 solicitudes de API para cada tarea! Si la autenticación tiene éxito, se crea un pequeño archivo de texto con credenciales válidas en el directorio de cargas de WordPress.
4. Cuando se verifican todas las contraseñas, el script envía una notificación a hxxps://dinámico-linx[.]es/completeTask.php que la tarea con un específico ID de tarea (probablemente un sitio único) y comprobarId (lote de contraseñas) se ha completado.
5. Finalmente, el script solicita la siguiente tarea y procesa un nuevo lote de contraseñas. Y así indefinidamente mientras la página infectada esté abierta.

Hasta el martes, el investigador había observado “docenas de miles de solicitudes” a miles de dominios únicos que buscaban archivos cargados por los navegadores de los visitantes. La mayoría de los archivos informaron errores web 404, una indicación de que falló el inicio de sesión con la contraseña adivinada. Aproximadamente el 0,5 por ciento de los casos arrojaron un código de respuesta 200, lo que deja abierta la posibilidad de que las adivinanzas de contraseña hayan tenido éxito. Tras una inspección más exhaustiva, sólo uno de los sitios resultó comprometido. Los demás usaban configuraciones no estándar que devolvían la respuesta 200, incluso para páginas que no estaban disponibles.

Durante un lapso de cuatro días que finalizó el martes, Sinegubko registró más de 1200 direcciones IP únicas que intentaron descargar el archivo de credenciales. De ellas, cinco direcciones representaron más del 85 por ciento de las solicitudes:

IP	%	ASN
146.70.199.169	34,37%	M247, RO
138.199.60.23	28,13%	CDNEXT, ES
138.199.60.32	10,96%	CDNEXT, ES
138.199.60.19	6,54%	CDNEXT, ES
87.121.87.178	5,94%	SOUZA-AS, BR

El mes pasado, el investigador observó que una de las direcciones (87.121.87.178) albergaba una URL utilizada en un ataque de criptojacking. Una posibilidad para el cambio es que la campaña anterior falló porque la URL maliciosa en la que se basaba no estaba alojada en suficientes sitios pirateados y, en respuesta, el mismo atacante está utilizando el script para descifrar contraseñas en un intento de reclutar más sitios.

Como señala Sinegubko, la campaña más reciente es importante porque aprovecha las computadoras y las conexiones a Internet de visitantes involuntarios que no han hecho nada malo. Una forma en que los usuarios finales pueden detener esto es usar NoScript u otra herramienta que bloquee la ejecución de JavaScript en sitios desconocidos. NoScript daña tantos sitios que no es adecuado para usuarios menos experimentados, e incluso aquellos con más experiencia a menudo consideran que la molestia no vale la pena. Otro posible remedio es utilizar ciertos bloqueadores de publicidad.