Mientras trabajábamos para proteger la tienda en línea de uno de nuestros clientes, varias veces encontramos un curioso ataque de fuerza bruta, que no fue tan fácil de contrarrestar. Se basaba en una solución sencilla que distinguía el ataque de las filas de su clase. Lo que ella era y cómo aún nos defendíamos de ella, leía debajo del corte.
Como saben, la fuerza bruta "clásica" es un ataque de fuerza bruta de datos. Por ejemplo, se toman cuentas conocidas y se seleccionan contraseñas para ellos de acuerdo con algunos criterios, ya sea generados sobre la marcha o basados en diccionarios robados. Este es el método básico para hackear cuentas.
Y en el caso que describí, los atacantes actuaron de manera un poco diferente. Primero, utilizaron una gran red de bots distribuida entre diferentes países desde varios cientos de computadoras infectadas. En el sistema de monitoreo, todo parecía como si fueran computadoras completamente diferentes, o representantes de personas reales que estaban sentadas y accediendo al sitio. Tal ataque puede pasar desapercibido durante mucho tiempo.
La segunda característica del ataque, además de su fuerte distribución geográfica, era una enumeración de no inicios de sesión, sino inicios de sesión. Los atacantes probablemente usaron diccionarios de contraseñas populares y listas de inicio de sesión robadas. Y primero se ingresó un inicio de sesión a la contraseña conocida, luego otro, tercero, y así sucesivamente. Fue muy similar a la situación en la que los usuarios comunes conectados a través de un proveedor no pueden iniciar sesión con sus contraseñas. Es decir, a primera vista, nada criminal. Además, el acceso al recurso era muy raro: uno o dos por minuto.
La tercera característica del ataque fue que la red de bots tenía un comportamiento muy "humano": los clientes procesaron JavaScript, aceptaron cookies.
Debido a este complejo de factores, el ataque pasó desapercibido durante mucho tiempo. Sin embargo, cuando lo descubrimos, nos hicimos una pregunta no trivial: ¿cómo defendernos? Todas las computadoras botnet no tenían ninguna característica distintiva especial, con la excepción de un cierto error en el agente de usuario. Pero no bloqueamos el ataque sobre la base de este signo, porque en este caso dejaríamos de ver las acciones del atacante. Era necesario resaltar algunas otras anomalías. No pasó nada especial en términos de direcciones IP. También es imposible bloquear los inicios de sesión que realizan un gran número de intentos de inicio de sesión fallidos, porque la frecuencia es muy baja y el inicio de sesión no está codificado. Solo había una forma: introducir captcha. Pero el cliente realmente no quería hacer esto, porque creía que captcha podría alienar a muchos clientes. Mientras tanto, los atacantes ya han logrado elegir las combinaciones correctas para algunas cuentas.
Seguramente estás perplejo: ¿por qué alguien entraría en las cuentas de los clientes de una tienda en línea? El hecho es que en su cuenta se acumulan puntos de bonificación, que pueden utilizarse para recibir descuentos en productos. Probablemente alguien realmente quería comprar o vender puntos de bonificación en Internet.
Como resultado, persuadimos al cliente para que implementara el captcha usando las herramientas F5: debería haber aparecido después de un número dado de entradas sin éxito. Pero primero, era necesario configurar los criterios para un inicio de sesión exitoso en el sistema. Esto resultó ser un poco más complicado de lo que parecía, porque en algunos casos el recurso proporciona el mismo código de respuesta para cualquier intento de inicio de sesión. Como criterio para el éxito del inicio de sesión, elegimos enviar las cookies de dominio del cliente.
En la última versión de
F5 ASM , fue posible responder a los intentos de selección en términos de ID de dispositivo, un identificador único del navegador. Se agrega un código JS a la página, y cuando la máquina infectada abre esta página, informa su identificador único. En el caso de nuestros atacantes, resultó que la ID del dispositivo del navegador era la misma para cada dirección IP. Es decir, de hecho, se accede a un navegador desde una dirección IP.
Por lo tanto, puede establecer el siguiente criterio: si se realizan más de 5 intentos de inicio de sesión fallidos desde un navegador en 15 minutos, se mostrará un captcha a este cliente. Si este es un usuario realmente normal, lo resolverá e iniciará sesión con calma. En caso de que el navegador no sea compatible con JavaScript, hemos agregado excepciones. Pero, para no debilitar la protección, utilizamos un criterio diferente: si se realizan más de 20 intentos de inicio de sesión fallidos desde una dirección IP, se ofrece nuevamente un captcha. Nuevamente: para un usuario normal, esto no causará problemas.
Pero hoy ya existen métodos para eludir la protección con captcha. Por ejemplo, las botnets envían captchas a "outsourcing" - a China o India, donde los trabajadores locales por una pequeña tarifa resuelven captchas y devuelven valores de texto. Pero en este caso, puede tomar las medidas apropiadas: incluso si con el captcha resuelto, los intentos de inicio de sesión no tienen éxito, puede bloquear las solicitudes de una IP específica o ID de dispositivo si se excede el número especificado de intentos fallidos.
La última vez que la tienda en línea fue atacada de esta manera, gestionamos el captcha y funcionó. Después de su introducción, el ataque de fuerza bruta comenzó a desvanecerse gradualmente y finalmente cesó. Aproximadamente un año ha pasado desde entonces, no hubo recaídas.
Andrei Chernykh, experto en el Centro de seguridad de la información Jet Infosystems