hacktricks/pentesting-web/account-takeover.md

15 KiB

खाता अधिग्रहण

{% hint style="success" %} AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें
{% endhint %}

अधिकार समस्या

एक खाते का ईमेल बदलने का प्रयास किया जाना चाहिए, और पुष्टि प्रक्रिया की जांच की जानी चाहिए। यदि यह कमजोर पाया जाता है, तो ईमेल को लक्षित पीड़ित के ईमेल में बदलना चाहिए और फिर पुष्टि की जानी चाहिए।

यूनिकोड सामान्यीकरण समस्या

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

जैसा कि इस वार्ता में समझाया गया है, पिछले हमले को तीसरे पक्ष के पहचान प्रदाताओं का दुरुपयोग करके भी किया जा सकता है:

  • पीड़ित के समान ईमेल के साथ तीसरे पक्ष की पहचान में एक खाता बनाएं, जिसमें कुछ यूनिकोड वर्ण हों (vićtim@company.com)।
  • तीसरे पक्ष के प्रदाता को ईमेल की पुष्टि नहीं करनी चाहिए
  • यदि पहचान प्रदाता ईमेल की पुष्टि करता है, तो आप डोमेन भाग पर हमला कर सकते हैं जैसे: victim@ćompany.com और उस डोमेन को पंजीकृत कर सकते हैं और आशा करते हैं कि पहचान प्रदाता डोमेन का ASCII संस्करण उत्पन्न करे जबकि पीड़ित प्लेटफ़ॉर्म डोमेन नाम को सामान्यीकृत करता है।
  • इस पहचान प्रदाता के माध्यम से पीड़ित प्लेटफ़ॉर्म में लॉगिन करें, जिसे यूनिकोड वर्ण को सामान्यीकृत करना चाहिए और आपको पीड़ित खाते तक पहुंचने की अनुमति देनी चाहिए।

अधिक विवरण के लिए, यूनिकोड सामान्यीकरण पर दस्तावेज़ देखें:

{% content-ref url="unicode-injection/unicode-normalization.md" %} unicode-normalization.md {% endcontent-ref %}

रीसेट टोकन का पुन: उपयोग

यदि लक्षित प्रणाली रीसेट लिंक को पुन: उपयोग करने की अनुमति देती है, तो gau, wayback, या scan.io जैसे उपकरणों का उपयोग करके अधिक रीसेट लिंक खोजने का प्रयास किया जाना चाहिए।

पूर्व खाता अधिग्रहण

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

CORS गलत कॉन्फ़िगरेशन से खाता अधिग्रहण

यदि पृष्ठ में CORS गलत कॉन्फ़िगरेशन हैं, तो आप उपयोगकर्ता से संवेदनशील जानकारी चुराने में सक्षम हो सकते हैं ताकि उसका खाता अधिग्रहित किया जा सके या उसे उसी उद्देश्य के लिए प्रमाणीकरण जानकारी बदलने के लिए मजबूर किया जा सके:

{% content-ref url="cors-bypass.md" %} cors-bypass.md {% endcontent-ref %}

Csrf से खाता अधिग्रहण

यदि पृष्ठ CSRF के प्रति संवेदनशील है, तो आप उपयोगकर्ता को अपना पासवर्ड, ईमेल या प्रमाणीकरण संशोधित करने के लिए मजबूर कर सकते हैं ताकि आप फिर इसे एक्सेस कर सकें:

{% content-ref url="csrf-cross-site-request-forgery.md" %} csrf-cross-site-request-forgery.md {% endcontent-ref %}

XSS से खाता अधिग्रहण

यदि आप एप्लिकेशन में XSS पाते हैं, तो आप कुकीज़, स्थानीय भंडारण, या वेब पृष्ठ से जानकारी चुराने में सक्षम हो सकते हैं जो आपको खाता अधिग्रहण की अनुमति दे सकती है:

{% content-ref url="xss-cross-site-scripting/" %} xss-cross-site-scripting {% endcontent-ref %}

समान मूल + कुकीज़

यदि आप सीमित XSS या उपडोमेन अधिग्रहण पाते हैं, तो आप कुकीज़ के साथ खेल सकते हैं (उदाहरण के लिए, उन्हें स्थिर करना) ताकि पीड़ित के खाते को समझौता करने का प्रयास किया जा सके:

{% content-ref url="hacking-with-cookies/" %} hacking-with-cookies {% endcontent-ref %}

पासवर्ड रीसेट तंत्र पर हमला करना

{% content-ref url="reset-password.md" %} reset-password.md {% endcontent-ref %}

प्रतिक्रिया हेरफेर

यदि प्रमाणीकरण प्रतिक्रिया को सरल बूलियन में घटाया जा सकता है, तो बस false को true में बदलने का प्रयास करें और देखें कि क्या आपको कोई पहुंच मिलती है।

OAuth से खाता अधिग्रहण

{% content-ref url="oauth-to-account-takeover.md" %} oauth-to-account-takeover.md {% endcontent-ref %}

होस्ट हेडर इंजेक्शन

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

प्रतिक्रिया हेरफेर

  1. कोड हेरफेर: स्थिति कोड को 200 OK में बदला जाता है।
  2. कोड और बॉडी हेरफेर:
  • स्थिति कोड को 200 OK में बदला जाता है।
  • प्रतिक्रिया बॉडी को {"success":true} या एक खाली वस्तु {} में संशोधित किया जाता है।

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

वर्तमान सत्र का ईमेल बदलें

इस रिपोर्ट से:

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

यह इस रिपोर्ट में भी हुआ।

पुराने कुकीज़

जैसा कि इस पोस्ट में समझाया गया है, एक खाते में लॉगिन करना, कुकीज़ को एक प्रमाणित उपयोगकर्ता के रूप में सहेजना, लॉगआउट करना, और फिर फिर से लॉगिन करना संभव था।
नए लॉगिन के साथ, हालांकि विभिन्न कुकीज़ उत्पन्न हो सकती हैं, पुराने कुकीज़ फिर से काम करने लगे।

संदर्भ

{% hint style="success" %} AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks का समर्थन करें
{% endhint %}