Vulnerabilidad en Ransomlook (CVE-2026-78551)

RansomLook contiene múltiples debilidades en su punto final de autenticación que permiten a un atacante remoto no autenticado enumerar nombres de usuario válidos, realizar ataques de adivinación de contraseñas sin restricciones y potencialmente agotar los recursos de los trabajadores de la aplicación.<br /> <br /> Para la autenticación local, la implementación de inicio de sesión verificaba previamente si un nombre de usuario enviado existía antes de invocar la función de verificación del hash de la contraseña. Las solicitudes que contenían un nombre de usuario inexistente, por lo tanto, regresaban significativamente más rápido que las solicitudes para cuentas válidas, para las cuales se ejecutaba la rutina de verificación de contraseña computacionalmente costosa. Un atacante remoto podría medir estas diferencias en el tiempo de respuesta para determinar qué nombres de usuario corresponden a cuentas válidas de RansomLook.<br /> <br /> Además, el punto final /login no restringía el número o la frecuencia de los intentos de autenticación fallidos. Un atacante podría, en consecuencia, realizar ataques de fuerza bruta de contraseñas, de diccionario, de pulverización de contraseñas o de relleno de credenciales contra cuentas conocidas sin limitación por parte del servidor. Para nombres de usuario válidos, cada intento de autenticación también invoca la función de derivación de clave de contraseña, que consume una cantidad significativa de tiempo de CPU. Una tasa suficientemente alta de intentos de inicio de sesión podría, por lo tanto, ocupar los trabajadores síncronos de Gunicorn de la aplicación y causar una denegación de servicio que afecte a toda la aplicación.<br /> <br /> El problema se ha abordado realizando siempre la verificación de la contraseña utilizando un hash de contraseña ficticio generado aleatoriamente cuando el nombre de usuario proporcionado no existe, eliminando la discrepancia de tiempo dependiente del nombre de usuario. Los intentos de autenticación fallidos están adicionalmente limitados por tasa por dirección IP del cliente utilizando Valkey/Redis, con cinco intentos fallidos en cinco minutos resultando en un bloqueo de una hora. La configuración del proxy inverso también se actualizó para que la aplicación derive la dirección del cliente de un valor X-Forwarded-For de confianza que no puede ser anulado por un encabezado proporcionado por el cliente.