Race condition sur un endpoint unique
Single-endpoint race conditions
Contexte du lab
La fonctionnalité de changement d’adresse e-mail contient une condition de course qui permet d’associer une adresse arbitraire à notre compte.
Un utilisateur avec l’adresse [email protected] a une invitation en attente pour devenir administrateur, mais il n’a pas encore créé de compte. Donc, si quelqu’un parvient à revendiquer cette adresse, il récupère automatiquement les droits admin.
Objectif
Trouver une condition de course permettant de revendiquer une adresse e-mail arbitraire.
Changer l’e-mail du compte en [email protected].
Accéder au panneau d’administration.
Supprimer l’utilisateur carlos.
Identifiants fournis : wiener:peter Accès à un client mail pour les adresses @exploit-…exploit-server.net.
Observation du flux “normal” (changement d’e-mail)
On tente d’abord de changer l’e-mail vers une adresse contrôlée :
Nouvelle adresse :
wiener@exploit-0a10009b04efd21981a1bafc0102005d.exploit-server.net
Réponse de l’application :
“Please click the link in your email to confirm the change of e-mail to …”
Un e-mail arrive avec un lien de confirmation, par exemple :
/confirm-email?user=wiener&token=ob0dI7AMlwX2Y2uw
Une fois le lien cliqué :
“Your email has been successfully updated”
Derrière, la requête ressemble à :
Test en rafale (sans course)
On envoie plusieurs requêtes “change email” avec des e-mails différents (test1, test2, … test20), chacune séparée, et les confirmations reçues correspondent bien aux adresses demandées.
Mais quand on exécute ces mêmes requêtes en parallèle, un comportement inattendu apparaît : on reçoit parfois des confirmations qui ne correspondent pas au bon destinataire.
Analyse de la condition de course
Le comportement observé suggère un traitement en deux phases :
Une phase qui prépare/rédige l’e-mail de confirmation
Une phase qui détermine à quelle adresse l’e-mail est envoyé
En envoyant un lot de requêtes en parallèle, on arrive à “croiser” ces deux phases : le contenu d’un e-mail peut être associé à une autre adresse de destination.
Principe : envoyer en parallèle un mix de requêtes contenant :
Une partie avec :
L’autre partie avec une adresse contrôlée :
Résultat : on reçoit un e-mail indiquant :
“To confirm your email change to [email protected], click the link below”
Donc on obtient le lien de confirmation pour l’adresse de Carlos et on peut finaliser le changement d’e-mail vers [email protected].
Mis à jour