Account Takeover

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

Authorization Issue

एक अकाउंट का ईमेल बदला जाना चाहिए, और confirmation प्रक्रिया की कठोर जाँच की जानी चाहिए। अगर यह कमज़ोर पाई जाती है, तो ईमेल को लक्षित पीड़ित के ईमेल में बदलकर पुष्टि की जानी चाहिए।

Unicode Normalization Issue

  1. लक्षित पीड़ित का अकाउंट victim@gmail.com
  2. Unicode का उपयोग करके एक अकाउंट बनाया जाना चाहिए, उदाहरण के लिए: vićtim@gmail.com

जैसा कि इस टॉक में समझाया गया है, ऊपर दिया गया हमला तीसरे पक्ष के identity providers का दुरुपयोग करके भी किया जा सकता है:

  • Create an account in the third party identity with similar email to the victim using some unicode character (vićtim@company.com).
  • The third party provider shouldn’t verify the email
  • If the identity provider verifies the email, maybe you can attack the domain part like: victim@ćompany.com and register that domain and hope that the identity provider generates the ascii version of the domain while the victim platform normalize the domain name.
  • Login via this identity provider in the victim platform who should normalize the unicode character and allow you to access the victim account.

For further details, refer to the document on Unicode Normalization:

Unicode Normalization

Reusing Reset Token

यदि target सिस्टम reset link to be reused की अनुमति देता है, तो gau, wayback, या scan.io जैसे टूल्स का उपयोग करके और भी reset links find करने की कोशिश करनी चाहिए।

Pre Account Takeover

  1. प्लेटफ़ॉर्म पर signup करने के लिए victim का ईमेल इस्तेमाल किया जाना चाहिए, और एक password सेट किया जाना चाहिए (इसे confirm करने का प्रयास किया जाना चाहिए, हालांकि victim के ईमेल्स तक पहुँच न होने पर यह संभव न भी हो)।
  2. प्रतीक्षा करनी चाहिए जब तक कि victim OAuth का उपयोग करके signup न कर ले और account confirm न कर दे।
  3. आशा यह होती है कि regular signup confirm हो जाएगा, जिससे victim के अकाउंट तक पहुँच मिल सकती है।

CORS Misconfiguration to Account Takeover

यदि पेज में CORS misconfigurations हैं तो आप यूज़र से संवेदनशील जानकारी चुरा कर सकते हैं ताकि आप उसका अकाउंट takeover कर सकें या उसे auth जानकारी बदलने के लिए मजबूर कर सकें:

CORS - Misconfigurations & Bypass

Csrf to Account Takeover

यदि पेज CSRF के लिए vulnerable है, तो आप यूज़र को उसकी password, email या authentication बदलने के लिए मजबूर कर सकते हैं ताकि आप फिर उसे access कर सकें:

CSRF (Cross Site Request Forgery)

XSS to Account Takeover

यदि आप application में XSS पाते हैं तो आप cookies, local storage, या वेब पेज से जानकारी चुरा सकते हैं जो आपको अकाउंट takeover करने की अनुमति दे सकती है:

XSS (Cross Site Scripting)

Same Origin + Cookies

यदि आप एक limited XSS या subdomain take over पाते हैं, तो आप cookies के साथ (उदाहरण के लिए उन्हें fixating करके) छेड़छाड़ कर सकते हैं ताकि victim का अकाउंट compromise करने की कोशिश की जा सके:

Cookies Hacking

Attacking Password Reset Mechanism

Reset/Forgotten Password Bypass

Security-question resets that trust client-supplied usernames

यदि “update security questions” flow में username parameter लिया जाता है, भले ही caller पहले से authenticated हो, तो आप किसी भी खाते की recovery data (admins सहित) overwrite कर सकते हैं क्योंकि backend आमतौर पर UPDATE ... WHERE user_name = ? जैसे statement को आपके untrusted value के साथ चलाता है। पैटर्न है:

  1. एक throwaway user से लॉगिन करें और session cookie कैप्चर करें।
  2. reset form के माध्यम से victim का username और नए answers सबमिट करें।
  3. तुरंत security-question login endpoint के माध्यम से उन्हीं answers का उपयोग करके authenticate करें जो आपने अभी inject किए हैं, ताकि आप victim की privileges inherit कर सकें।
POST /reset.php HTTP/1.1
Host: file.era.htb
Cookie: PHPSESSID=<low-priv>
Content-Type: application/x-www-form-urlencoded

username=admin_ef01cab31aa&new_answer1=A&new_answer2=B&new_answer3=C

Anything gated by the victim’s $_SESSION context (admin dashboards, dangerous stream-wrapper features, etc.) is now exposed without touching the real answers.

गिनती किए गए usernames को फिर ऊपर बताए गए overwrite technique के जरिए लक्षित किया जा सकता है या सहायक सेवाओं (FTP/SSH password spraying) पर पुन: उपयोग किया जा सकता है।

Response Manipulation

If the authentication response could be reduced to a simple boolean just try to change false to true and see if you get any access.

यदि authentication response को सरल boolean में घटाया जा सकता है तो सिर्फ false को true में बदलकर देखें कि आपको कोई access मिल जाता है या नहीं।

OAuth to Account takeover

OAuth to Account takeover

Host Header Injection

  1. पासवर्ड रीसेट अनुरोध शुरू करने के बाद Host header को संशोधित किया जाता है।
  2. X-Forwarded-For proxy header को attacker.com में बदला जाता है।
  3. Host, Referrer, और Origin headers को एक साथ attacker.com में बदल दिया जाता है।
  4. पासवर्ड रीसेट शुरू करने और फिर मेल resend करने का विकल्प चुनने के बाद, ऊपर बताए गए तीनों तरीकों का उपयोग किया जाता है।

Response Manipulation

  1. Code Manipulation: स्टेटस कोड को 200 OK में बदल दिया जाता है।
  2. Code and Body Manipulation:
  • स्टेटस कोड को 200 OK में बदल दिया जाता है।
  • response body को {"success":true} या खाली object {} में संशोधित किया जाता है।

ये manipulation techniques उन स्थितियों में प्रभावी हैं जहाँ JSON डेटा ट्रांसमिशन और रिसीव के लिए उपयोग किया जाता है।

Change email of current session

From this report:

  • आक्रमणकर्ता अपने ईमेल को नए ईमेल से बदलने का अनुरोध करता है।
  • आक्रमणकर्ता को ईमेल परिवर्तन की पुष्टि करने के लिए एक लिंक मिलता है।
  • आक्रमणकर्ता वह लिंक पीड़ित को भेजता है ताकि वह उस पर क्लिक करे।
  • पीड़ित का ईमेल आक्रमणकर्ता द्वारा बताये गए ईमेल पर बदल जाता है।
  • इस हमले से पासवर्ड पुनर्प्राप्त किया जा सकता है और खाता हथियाया जा सकता है।

This also happened in this report.

Bypass email verification for Account Takeover

  • आक्रमणकर्ता attacker@test.com से लॉगिन करता है और signup पर ईमेल सत्यापित करता है।
  • आक्रमणकर्ता verified ईमेल को victim@test.com में बदल देता है (email change पर कोई secondary verification नहीं)
  • अब वेबसाइट victim@test.com को लॉगिन करने की अनुमति देती है और हमने पीड़ित उपयोगकर्ता की ईमेल सत्यापन को बायपास कर लिया है।

Old Cookies

जैसा कि in this post में समझाया गया है, किसी खाते में लॉगिन कर के authenticated user के रूप में cookies सेव करना, logout करना, और फिर दोबारा login करना संभव था.
नए लॉगिन के साथ, हालांकि अलग cookies जनरेट हो सकती थीं, पुराने cookies फिर से काम करने लगे।

संदर्भ

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