Exploiting time-sensitive vulnerabilities

Certificaciones

• eWPT
• eWPTXv2
• OSWE
• BSCP

Descripción

Este laboratorio contiene un mecanismo de restablecimiento de contraseña. Aunque no tiene una race condition, podemos explotar la criptografía del mecanismo enviando solicitudes sincronizadas con precisión

Para resolver el laboratorio debemos

• Identificar la vulnerabilidad en la forma en que el sitio web genera los tokens de restablecimiento de contraseña

• Obtener un token de restablecimiento de contraseña válido para el usuario carlos

• Iniciar sesión como carlos

• Acceder al panel de administración y eliminar al usuario carlos

Podemos iniciar sesión en nuestra cuenta con las credenciales wiener:peter

---

Guía de race conditions

Antes de completar este laboratorio es recomendable leerse esta guía de race conditions https://justice-reaper.github.io/posts/Race-Conditions-Guide/

Resolución

Al acceder a la web vemos esto

Si hacemos click sobre My account nos podemos loguear con las credenciales wiener:peter

Después de iniciar sesión vemos que podemos cambiarnos el correo electrónico

Si pulsamos sobre Forgot password? vemos que podemos resetear nuestra contraseña proporcionando el nombre de usuario o nuestro email

Se nos mandará un email a nuestro correo

Si pulsamos sobre el enlace nos redirigirá a /forgot-password?user=wiener&token=0838f9d972a6ebf021d46e6e74d1af997c888d91 y podremos setear una nueva contraseña

A continuación, nos dirigirnos a la extensión Logger ++ de Burpsuite y le echamos un vistazo a la petición de Forgot password?

Vamos a enviar esta petición al Repeater y vamos a testear si es probable una race condition. Para ello vamos se recomienda usar entre 20 y 30

Pinchamos sobre los tres puntos y creamos un grupo pulsando en Create tab group

Vamos a enviar todas las peticiones en grupo usando la opción Send group in sequence (separate connections). Usamos esta opción para testear las race conditions, en este caso tiene sentido porque los correos electrónicos usan hilos y al mandar varias solicitudes hay más probabilidad de que colisionen. Vemos que las peticiones tienen todas un delay similar, por lo este podría ser un entorno ideal para que se produzca una race condition

A continuación usamos la opción Send group in parallel (single-packet attack)

Al fijarnos en el delay de las peticiones vemos que la diferencia es muy grande

Esto puede deberse a que algunos frameworks intentan evitar la corrupción accidental de datos mediante algún tipo de bloqueo de solicitudes. Por ejemplo, el módulo nativo de PHP para el manejo de sesiones solo procesa una solicitud por sesión a la vez

Es fundamental detectar este tipo de comportamiento, ya que puede ocultar vulnerabilidades. Si observamos que todas las solicitudes se procesan secuencialmente, podemos intentar enviar cada una con un token de sesión diferente

Como en este laboratorio se está usando PHP, podría ser este el caso y por eso se produce ese retraso a la hora de enviar peticiones. Para comprobar si estamos en lo cierto, vamos a reducir el número de peticiones a 2 solamente y cada petición tendrá una cookie diferente. Para obtener diferentes cookies debemos abrirnos las herramientas de desarrollador de Chrome, borrar la cookie para que se nos asigne una nueva y refrescar la web con F5

Posteriormente nos abrimos el código fuente y veremos un token CSRF que también necesitaremos, debido a que este token está vinculado a nuestra cookie de sesión

Otra forma más cómoda es capturar una la petición a /login con Burpsuite y eliminar la cabecera Cookie: phpsessionid=muXYmF0pTOMtm067D2Vuhd9xmw2amPSU

De esta forma al enviar la petición nos seteará una nueva cookie

Si filtramos por csrf también podemos obtener el token CSRF

El resultado final tendría que ser este. Para comprobar que ambas sesiones son válidas podemos mandar una petición de prueba pulsando en Send

Cambiamos la opción a Send group in parallel (single-packet attack) y ejecutamos el ataque. Si nos fijamos ahora los tiempos de respuesta son prácticamente idénticos

Debemos ejecutar este ataque hasta obtener dos tokens idénticos en el Email client. Este ataque ha funcionado debido a que el token de restablecimiento de contraseña solo se aleatoriza usando un timestamp y por lo tanto si enviamos dos peticiones de forma simultánea obtendremos dos token de restablecimiento de contraseña iguales

Para obtener el token de restablecimiento de contraseña del usuario carlos debemos cambiar en una de las peticiones el nombre de usuario a carlos

La otra petición no la modificamos

El ejecutamos un single-pack attack con la opción Send group in parallel (single-packet attack). Si nos dirigimos al Email client, solo nos llega una petición en este caso y eso es porque la otra petición le está llegando al Email client de carlos

Debemos copiarnos el enlace y sustituir el nombre de wiener por carlos

/forgot-password?user=wiener&token=78e5d2447713cd97fc82095dd3b482fb5691ac8a

/forgot-password?user=carlos&token=78e5d2447713cd97fc82095dd3b482fb5691ac8a

Accedemos a /forgot-password?user=carlos&token=78e5d2447713cd97fc82095dd3b482fb5691ac8a y le cambiamos la contraseña al usuario carlos

Pulsamos sobre My account e iniciamos sesión como el usuario carlos

Ganamos acceso a la cuenta del usuario carlos

Pulsamos sobre Admin panel y borramos la cuenta de carlos