$57,500 मूल्य का एक एपिक अकाउंट टेकओवर

नमस्कार दोस्तों! मैं एक दिलचस्प (पूर्व) खाता अधिग्रहण बग के साथ लंबे समय के बाद वापस आ गया हूं और मैंने इसे XSS के साथ कैसे जोड़ा। आप भ्रमित हो सकते हैं क्योंकि यह एक लंबा लेखन है, लेकिन चिंता न करें, इसे अंत तक बांधे रखें; मैंने बेहतर समझ के लिए अंत में चीजों को सरल बनाया है।

इस ब्लॉग में, मैं अपनी दिलचस्प प्री-अकाउंट टेकओवर कहानी साझा करने जा रहा हूं जो ब्रोकन एक्सेस कंट्रोल के कारण हुई और मैं इसे एक वैध मुद्दा बनाने में कैसे कामयाब रहा।

मैं एक पुराने निजी बग बाउंटी प्रोग्राम का शिकार कर रहा था। मैं अपने मन में जानता था कि डुप्लीकेट से बचने के लिए मुझे एक अनूठा मुद्दा खोजने की जरूरत है। हमेशा की तरह, मेरे डकार को निकाल दिया और बेतरतीब ढंग से लक्ष्य को ब्राउज़ करना शुरू कर दिया।
मैं साइट के एक प्रोफ़ाइल अनुभाग में आया था। केवल नाम और पासवर्ड संपादित करने का विकल्प था न कि ईमेल।

ईमेल बदलने का कोई विकल्प नहीं

मैंने ईमेल पता बदलने का फैसला किया। उसके लिए, मैंने अन्य सेटिंग्स की जांच शुरू कर दी, नाम बदल दिया और बर्प में अनुरोध पर कब्जा कर लिया।

मैंने देखा और UserAttributes के साथ खेलना शुरू कर दिया। सबसे पहले, मैंने नाम को update_email और मान को मौजूदा खाते के मेल में बदल दिया।
मुझे एक त्रुटि मिली -
{
"__type":"InvalidParameterException",
"message":"user.update_email: विशेषता स्कीमा में मौजूद नहीं है"
}

फिर से, मैंने नाम बदलकर change_email कर दिया और अनुरोध भेज दिया, लेकिन मुझे वही त्रुटि मिली -
{
"__type":"InvalidParameterException",
"message":"user.change_email: विशेषता स्कीमा में मौजूद नहीं है। n"
}

फिर मैं साइनअप प्रवाह अनुरोध पर वापस गया और देखा कि साइन अप करते समय एप्लिकेशन उपयोगकर्ता नाम विशेषता में एक नया ईमेल पता भेज रहा था। मैंने नाम को उपयोगकर्ता नाम में बदल दिया लेकिन फिर से वही त्रुटि मिली -
{
"__type":"InvalidParameterException",
"message":"user.Username: विशेषता स्कीमा में मौजूद नहीं है"
}

मैं हार मानने वाला था, लेकिन अंतिम प्रयास के रूप में, मैंने केवल एक ईमेल के साथ एक अनुरोध भेजा , और मुझे एक नई त्रुटि मिली!

मैंने अपना ध्यान पूर्व — खाता अधिग्रहण पर केंद्रित कर दिया क्योंकि इस त्रुटि ने पुष्टि की कि मैं किसी अन्य उपयोगकर्ता के खाते का अधिग्रहण नहीं कर सकता। मैंने ईमेल पते को अपंजीकृत ईमेल में बदल दिया, और यह काम कर गया।

मुझे एक नए ईमेल पर सत्यापन ओटीपी प्राप्त हुआ। हालाँकि, मैं सत्यापन प्रक्रिया से गुजरे बिना ईमेल पते को सफलतापूर्वक नए में बदलने में सक्षम था और बिना किसी सत्यापन के खाता प्राप्त कर लिया।

बहुत खूब! मैं बहुत उत्साहित हो गया, एक रिपोर्ट बनाई और इसे जमा कर दिया
कुछ घंटों के भीतर, उन्होंने इसे लागू नहीं करने योग्य में बदल दिया और मुझे यह जवाब भेजा:

मैं अपने आप को

यह प्रतिक्रिया प्राप्त करने के बाद, मैं आवेदन पर वापस लौटा और पीड़ित के मेल ( [email protected] ) और हमलावर के पासवर्ड से लॉगिन करने का प्रयास किया और एक त्रुटि मिली - "उपयोगकर्ता नाम या पासवर्ड गलत है"

फिर, मैंने यह देखने के लिए पासवर्ड रीसेट करने का प्रयास किया कि क्या उसने कोई ओटीपी भेजा है।
लेकिन एक नई त्रुटि मिली - "पासवर्ड रीसेट नहीं किया जा सका, क्योंकि ईमेल पंजीकृत या सत्यापित नहीं है।"

मैंने अपनी सभी त्रुटियों को नोट कर लिया और सो गया। अगले दिन मैंने फिर से शुरुआत की लेकिन कुछ भी नया नहीं मिला। फिर से अपने नोट्स खोले और उन्हें 2-3 बार पढ़ा। इस त्रुटि को पढ़ने के बाद - "पासवर्ड रीसेट नहीं किया जा सका, क्योंकि ईमेल पंजीकृत या सत्यापित नहीं है।"
मैंने पीड़ित के ईमेल से पंजीकरण करने का प्रयास करने का निर्णय लिया। जब मैंने पंजीकरण किया, तो एप्लिकेशन ने एक नई त्रुटि फेंकी - "आपका खाता अस्थायी रूप से उपलब्ध नहीं है। कृपया 15 मिनट में लॉग इन करने का प्रयास करें।"

15 मिनट के बाद, मैंने पंजीकरण के दौरान उपयोग किए गए पीड़ित के ईमेल और पासवर्ड से लॉगिन करने का प्रयास किया। लेकिन मुझे अभी भी यह त्रुटि मिली - "उपयोगकर्ता नाम या पासवर्ड गलत है।"
फिर मैंने पीड़ित के ईमेल ( [email protected] ) और हमलावर के ( [email protected] ) पासवर्ड से लॉग इन करने की कोशिश की । और मेरे आश्चर्य के लिए, मुझे खाते तक पहुंच प्राप्त हुई!

अब मुख्य समस्या थी-

"पासवर्ड किसी भी समय ईमेल पते के स्वामी द्वारा आराम किया जा सकता है"

इसलिए मैं रीसेट पासवर्ड सुविधा पर वापस गया, मैंने पासवर्ड रीसेट करने का प्रयास किया और एक त्रुटि मिली - "पासवर्ड रीसेट नहीं किया जा सका, क्योंकि ईमेल पंजीकृत या सत्यापित नहीं है।"

फिर मैंने पीड़ित के ईमेल पर एक नया सत्यापन कोड प्राप्त करने का प्रयास किया और एक त्रुटि मिली - " अमान्य उपयोगकर्ता नाम ।"

मैं जैसा था:

समस्या हल हो गई! उपयोगकर्ता पासवर्ड रीसेट लिंक के माध्यम से अपना पासवर्ड रीसेट नहीं कर सकता।

यह अब तक बहुत स्पष्ट नहीं हो सकता है, लेकिन मैं इसे संक्षेप में प्रस्तुत करूँगा:

• दो ईमेल:
  अटैकर- रेसलिंगमास्टर[email protected]
  विक्टिम (अनरजिस्टर्ड अकाउंट)- [email protected]
• एप्लिकेशन में ईमेल बदलने की कार्यक्षमता नहीं है ।
• हमलावर खाते से, UserAttributes मान की गणना करके पीड़ित के ईमेल पते को बदलें ।
  "उपयोगकर्ता विशेषताएँ": [
  {"नाम": "ईमेल",
  "मूल्य": " [email protected] "
  }
• जब हमलावर मेल बदलता है, तो पीड़ित को सत्यापन के लिए ओटीपी कोड प्राप्त होगा।
• लेकिन मेल को सत्यापित करने की आवश्यकता नहीं है, हमलावर ने पहले ही पीड़ित के ईमेल को उनके खाते से जोड़ दिया है।
• हमलावर लॉग आउट करता है और पीड़ित के ईमेल और हमलावर के पासवर्ड से लॉग इन करने का प्रयास करता है । आवेदन इसकी अनुमति नहीं देगा क्योंकि पीड़ित का ईमेल अभी तक पंजीकृत नहीं है।
• हमलावर पंजीकरण के लिए नेविगेट करता है और पीड़ित के ईमेल के साथ पंजीकरण करता है। एप्लिकेशन एक त्रुटि फेंकता है - "आपका खाता अस्थायी रूप से उपलब्ध नहीं है। कृपया 15 मिनट में लॉग इन करने का प्रयास करें।"
• 15 मिनट के बाद, हमलावर लॉगिन पैनल पर वापस जाता है और पीड़ित के ईमेल और हमलावर के पासवर्ड से सफलतापूर्वक लॉग इन करता है ।
• जब पीड़ित अपना पासवर्ड रीसेट करने का प्रयास करता है या खाता एप्लिकेशन को सत्यापित करने का प्रयास करता है तो एक त्रुटि होती है - "अमान्य उपयोगकर्ता नाम", जिसका अर्थ है कि पीड़ित ने अपना खाता पुनर्प्राप्त करने के अपने सभी तरीके खो दिए हैं।
• भारी गलत कॉन्फ़िगरेशन (टूटा एक्सेस कंट्रोल) के कारण, हमलावर का खाता पीड़ित के ईमेल से जुड़ा हुआ है। हमलावर ने केवल ईमेल पंजीकृत किया और खाता सत्यापित नहीं किया, इसलिए बैकएंड सर्वर के पास पीड़ित के ईमेल का रिकॉर्ड नहीं है। (यह मेरा अनुमान है, निश्चित नहीं)

• पीड़ित "रीसेट पासवर्ड कार्यक्षमता" द्वारा अपना पासवर्ड रीसेट नहीं कर सकता है।
• यदि पीड़ित पासवर्ड रीसेट करने के लिए समर्थन टीम से संपर्क करने का प्रयास करता है, तो संभावना है कि समर्थन टीम बैकएंड में पीड़ित के ईमेल को खोजने में सक्षम नहीं होगी क्योंकि यह एक असत्यापित ईमेल है - (त्रुटि I के आधार पर मेरा अनुमान पासवर्ड रीसेट और सत्यापन पुनः भेजने के दौरान मिला)

जब मैंने एप्लिकेशन पर शिकार करना शुरू किया तो मुझे नाम फ़ील्ड में एक HTML इंजेक्शन मिला। मैंने इसे नजरअंदाज कर दिया क्योंकि कोई प्रभाव नहीं पड़ा।
तब मुझे एक विचार आया कि अगर किसी तरह मैं इसे संग्रहीत XSS में परिवर्तित करने और पीड़ित के खाते में XSS पेलोड डालने में कामयाब रहा, तो जब भी पीड़ित अपने खाते को पुनः प्राप्त करने का प्रबंधन करेगा, XSS ट्रिगर हो जाएगा।

मैंने मूल XSS पेलोड को अंतिम नाम फ़ील्ड में रखा, लेकिन एप्लिकेशन ने खाली सफेद स्थान और कोई अलर्ट नहीं दिखाया।

कुछ घंटों के प्रयास के बाद, मुझे पता चला कि एप्लिकेशन में केवल XSS के खिलाफ बुनियादी सुरक्षा है, और यह केवल <script>, <img>, अलर्ट इत्यादि को फ़िल्टर करता है।
फिर मैंने एक पेलोड बनाया, अलर्ट को प्रॉम्प्ट से बदल दिया, और यह काम कर गया!

<a onmouseover=”prompt(document.cookie)”>यहां</a>

जैसे ही पीड़ित अंतिम नाम पर स्क्रॉल करेगा, XSS ट्रिगर हो जाएगा।

मैंने पीड़ित के लिए अपना पासवर्ड पुनः प्राप्त करने के सभी तरीकों को अवरुद्ध कर दिया, और यहां तक ​​कि अगर वे ऐसा करने में कामयाब रहे (जो लगभग असंभव है), तो XSS प्रोफ़ाइल अनुभाग में प्रतीक्षा कर रहा है।

व्यवसाय प्रभाव:

• एप्लिकेशन में एक महत्वपूर्ण भेद्यता है जो हमलावरों को प्रमाणीकरण तंत्र को बायपास करने और ओटीपी सत्यापन के बिना खाता बनाने की अनुमति देती है।
• भेद्यता एक हमलावर को एप्लिकेशन की कार्यक्षमताओं का दुरुपयोग करने की अनुमति देती है, जैसे कि प्रोफ़ाइल अनुभाग में ईमेल पता बदलना, जिसे एप्लिकेशन द्वारा जानबूझकर अनुमति नहीं दी जाती है।
• एक हमलावर के रूप में, मैं शिकार के नाम को संग्रहीत XSS पेलोड के रूप में सेट कर सकता था, क्योंकि एप्लिकेशन संग्रहीत XSS के लिए असुरक्षित है। जब पीड़ित अपना पासवर्ड रीसेट करता है (जो लगभग असंभव है), तो वे अपने खाते में लॉग इन करेंगे। जैसे ही पीड़ित लॉग इन करता है, XSS पेलोड ट्रिगर हो जाएगा, जिससे कुकीज़ को उजागर किया जा सकेगा।
• इस एप्लिकेशन के प्रमाणीकरण तंत्र को दरकिनार करने से एक हमलावर पीड़ित के खाते को (पूर्व) टेकओवर कर सकता है। एक हमलावर के रूप में, मैं खाते को पंजीकृत/लिंक करने और पीड़ित की ओर से कार्रवाई करने के लिए किसी भी पीड़ित के ईमेल पते का उपयोग कर सकता था।