Exploitation de vulnérabilités sensibles au temps

Exploiting time-sensitive vulnerabilities

Lab: Exploiting time-sensitive vulnerabilities | Web Security AcademyWebSecAcademy

Contexte du lab

Le site propose une fonctionnalité de réinitialisation de mot de passe via un lien envoyé par e-mail. Il n’y a pas de vraie race condition côté logique applicative, mais la génération des tokens est cassée : elle dépend d’une valeur prévisible (le temps), ce qui permet de forger un token valide pour un autre utilisateur en envoyant des requêtes au même instant.

Observations initiales

1. On utilise Forgot password avec l’utilisateur wiener.

• On reçoit un e-mail contenant un lien du type :

  • /forgot-password?user=wiener&token=<token>

Hello!

Please follow the link below to reset your password.

https://0a1300c9040343bf810b7f2a00e60085.web-security-academy.net/forgot-password?user=wiener&token=3930dc6d3d076151204ad4147326f81a5e1609a8

• Le token ressemble à un SHA1 (40 caractères hexadécimaux).

forgot-password?user=wiener&token=3930dc6d3d076151204ad4147326f81a5e1609a8

• Le token ressemble à un SHA1 (40 caractères hexadécimaux).

hashid '3930dc6d3d076151204ad4147326f81a5e1609a8'

1. En générant plusieurs tokens “normalement”, ils changent, mais ne semblent pas contenir d’entropie solide.

Hypothèse : le token est dérivé principalement d’un timestamp (ou d’une valeur basée sur le temps), plutôt que d’un secret robuste.

Idée clé : forcer deux demandes au même milliseconde

Si on arrive à déclencher deux réinitialisations au même moment, et que le token dépend uniquement du timestamp, alors les deux tokens seront identiques.

Problème : le serveur (PHP) évite parfois des collisions avec la même session / CSRF. Solution : obtenir deux sessions distinctes.

Préparation : obtenir deux couples Session + CSRF

On fait deux requêtes séparées vers :

• GET /forgot-password

GET /forgot-password HTTP/2

Host: 0a1300c9040343bf810b7f2a00e60085.web-security-academy.net

Cookie: 

Chaque réponse donne un nouveau couple :

• PHPSESSID=<...>

• un nouveau token CSRF (valeur cachée dans le formulaire)

On se retrouve avec deux requêtes prêtes, chacune avec :

• son cookie PHPSESSID

• son champ CSRF associé

Déclenchement : envoi en parallèle

On envoie ensuite en parallèle deux POST de reset (même endpoint), dans Burp (group + send parallel), afin qu’ils arrivent dans la même fenêtre de temps.

Résultat observé : les deux e-mails reçus contiennent exactement le même token :

933ccbd314dc37df95887cd914b07e330517f7bb
933ccbd314dc37df95887cd914b07e330517f7bb

Conclusion : le token dépend essentiellement du timestamp, pas d’un secret unique par utilisateur.

Exploitation : reset de Carlos avec le token de Wiener

Objectif : obtenir un token valable pour carlos.

Méthode :

1. Lancer en parallèle deux resets :

   • un pour wiener

   • un pour carlos

forgot-password?user=wiener&token=da1d6e3ed67bef3efa9fe74fcfbf7603120ea744
forgot-password?user=carlos&token=da1d6e3ed67bef3efa9fe74fcfbf7603120ea744

Puisque les tokens sont identiques, le token reçu (par exemple via l’e-mail de wiener) sera aussi valide pour carlos.

Si le site accepte cette URL, on peut définir un nouveau mot de passe pour carlos.

Finalisation du lab

1. Se connecter en tant que carlos avec le nouveau mot de passe.

2. Accéder au panneau admin.

3. Supprimer l’utilisateur carlos pour valider le lab.