Asumiendo que el servidor toma acciones basadas en una condición específica, analicemos la situación en la que el servidor realiza cálculos dependiendo del resultado de esta condición y luego transmite la respuesta al usuario. En ambos casos, es decir, tanto si se realizan los cálculos como si no, el servidor devuelve una respuesta al usuario. Cabe destacar que en la situación en la que el servidor realiza cálculos, consume una cierta cantidad de recursos, lo que lleva a un aumento en el tiempo de respuesta del servidor. Por lo general, estas diferencias en el tiempo de respuesta son tan pequeñas que no son perceptibles para el usuario final. Sin embargo, revelar estas sutiles diferencias en el tiempo de respuesta puede llevar a una fuga de datos no intencional.
Ahora consideremos un ejemplo práctico de esta situación basado en el proceso de inicio de sesión en una aplicación. Supongamos que el nombre de usuario proporcionado es correcto, pero la contraseña es incorrecta: en tal caso, el servidor puede tomar la decisión de realizar cálculos, como verificar la contraseña. Si el servidor realiza estos cálculos, puede requerir recursos adicionales y provocar un mayor tiempo de respuesta en comparación con el caso en que no se realizan cálculos. Aunque las diferencias en el tiempo de respuesta generalmente son pequeñas, están presentes y pueden ser medidas por un atacante.
El mismo proceso, pero cuando también el nombre de usuario es incorrecto:
En el caso de tales sutiles diferencias en el tiempo de respuesta, un atacante puede intentar utilizar esta información para inferir la validez del nombre de usuario. Por ejemplo, un atacante puede realizar un ataque de tiempo (timing attack), analizando el tiempo que el servidor tarda en responder a solicitudes con diferentes nombres de usuario. Comparando los tiempos de respuesta, el atacante puede inferir qué solicitud tomó más tiempo, lo que sugiere que el nombre de usuario era correcto. Descubrir el nombre de usuario permite a los atacantes realizar un ataque de fuerza bruta para adivinar la contraseña. En algunos casos, esto también puede significar la divulgación de información sensible, especialmente cuando el nombre de usuario es una dirección de correo electrónico asociada con una persona específica, y la aplicación probada es un portal con contenido controvertido.
Pruebas con Burp Suite – Request Timer
Al buscar este tipo de vulnerabilidades, será útil un complemento para Burp llamado Request Timer. Este complemento nos permitirá investigar el tiempo de respuesta del servidor para las solicitudes que especifiquemos.
El primer paso será interceptar la solicitud responsable del inicio de sesión del usuario y enviarla al módulo Intruder:
A continuación, cambiamos la contraseña por una larga cadena de caracteres para aumentar la carga en el servidor al generar el hash de la contraseña. Indicamos el lugar donde se encuentra el nombre de usuario. En el caso de la aplicación probada, también es necesario agregar el encabezado «X-Forwarded-For» y asignarle una dirección IP aleatoria para evitar el bloqueo de intentos repetidos de inicio de sesión desde la misma dirección IP. Por lo tanto, debemos cambiar el tipo de ataque a «Pitchfork».
Agregamos una lista de nombres de usuario a comprobar:
En el complemento Request Timer, definimos que escuche al módulo Intruder:
Después de iniciar la prueba, en la pestaña aparecerán las solicitudes generadas junto con el tiempo de respuesta. Como se puede notar, para un nombre de usuario correcto, el tiempo de respuesta es significativamente mayor. De esta manera, demostramos que la aplicación es vulnerable a la enumeración de nombres de usuario a través del análisis del tiempo de respuesta del servidor.
¿Qué hacer, cómo vivir?
Una de las soluciones a este tipo de problema es agregar una función responsable de retrasar aleatoriamente la respuesta del servidor:
Sin embargo, el problema con este tipo de solución es que todavía no tenemos control sobre situaciones como la ralentización de la red durante el intento de conexión a la base de datos o las diferencias que surgen cuando la base de datos crece de manera significativa.
Una mejor solución parece ser realizar operaciones de validación de datos proporcionados por el usuario de manera asíncrona en segundo plano e informar al usuario inmediatamente del intento de inicio de sesión. En este caso, los cálculos y los retrasos asociados permanecerán invisibles para el atacante.
