अकाउंट टेकओवर के लिए आईडीओआर

May 06 2023

सारांश नमस्कार लोगों! मेरे OSCP प्रमाणन के पूरा होने पर और फिर से बग बाउंटी में गोता लगाने की इच्छा रखते हुए, मैंने फैसला किया कि शायद मुझे अपने पिछले निष्कर्षों के आधार पर कुछ ब्लॉग लिखने चाहिए, इस उम्मीद में कि कोई इसे उपयोगी पा सकता है या इससे सीख सकता है। इस राइट-अप में दो IDOR कमजोरियों को खोजने और PII को लीक करने के लिए उनका लाभ उठाने पर जोर दिया गया है, जिसके परिणामस्वरूप खाता अधिग्रहण हो गया है।

सारांश

हैलो लोग! मेरे OSCP प्रमाणन के पूरा होने पर और फिर से बग बाउंटी में गोता लगाने की इच्छा रखते हुए, मैंने फैसला किया कि शायद मुझे अपने पिछले निष्कर्षों के आधार पर कुछ ब्लॉग लिखने चाहिए, इस उम्मीद में कि कोई इसे उपयोगी पा सकता है या इससे सीख सकता है।

इस राइट-अप में दो IDOR कमजोरियों को खोजने और PII को लीक करने के लिए उनका लाभ उठाने पर जोर दिया गया है, जिसके परिणामस्वरूप खाता अधिग्रहण हो गया है । कंपनी द्वारा खाता पुनर्प्राप्ति प्रक्रिया को संभालने के तरीके के कारण खाता अधिग्रहण संभव था और वास्तव में यह मेरे पहले निष्कर्षों में से एक था जब मैंने शुरू में बग बाउंटी शुरू की थी। इसे खोजने के रोमांच ने मुझे लगातार ओवरटाइम सीखने के लिए प्रेरित किया।

मैं किस आईडीओआर की बात कर रहा हूं?

Insecure Direct Object Referenceअक्सर "आईडीओआर" के रूप में संक्षेप में एक प्रकार की भेद्यता है जिसे वर्गीकृत किया जा सकता है access control। IDORsएप्लिकेशन के भीतर तब होता है जब ऐप बिना किसी जांच के सीधे ऑब्जेक्ट तक पहुंचने के लिए उपयोगकर्ता द्वारा प्रदान किए गए इनपुट का उपयोग करता है, यह देखने के लिए कि उपयोगकर्ता के पास सही प्राधिकरण अनुमतियां हैं या नहीं। अक्सर क्षैतिज विशेषाधिकार वृद्धि से जुड़ा IDORsअनुप्रयोग और उसके उपयोगकर्ता आधार पर हानिकारक प्रभाव डाल सकता है।

आम तौर पर आईडीओआर के लिए कमजोर विशिष्ट पैरामीटर का एक प्रमुख उदाहरण में शामिल हैं: id= | userID= | messageId=. एप्लिकेशन के प्रवाह को समझने से इस प्रकार की समस्याओं की पहचान करना आसान हो सकता है।

ऊपर दी गई छवि दो परिदृश्यों को दर्शाती है। Scenario Aबाईं ओर एक अधिक सुरक्षित एप्लिकेशन बताता है जहां users 2 and 3संवेदनशील रिकॉर्ड तक पहुंचने का प्रयास किया जाता है जो उनसे संबंधित नहीं है, हालांकि इसका परिणाम यह access denied errorहोना चाहिए।

Scenario Bहालांकि दाईं ओर, एक कमजोर एप्लिकेशन को दर्शाता है जहां खतरे का अभिनेता वेब सर्वर के लिए अनुरोध जारी कर सकता है और किसी भी उपयोगकर्ता के संवेदनशील रिकॉर्ड को एक्सेस से वंचित किए बिना पुनर्प्राप्त कर सकता है।

IDORs यदि आप विकी ली के बारे में अधिक पढ़ना चाहते हैं तो एक शानदार ब्लॉग पोस्ट है जो इस भेद्यता प्रकार के मूल सिद्धांतों पर प्रकाश डालती है। आप इसे यहां देख सकते हैं ।

उपरोक्त उदाहरण एक सरल उदाहरण है, हालांकि आवेदन के आधार पर आप प्रभाव को बढ़ाने के लिए रिपोर्ट करने से पहले जानकारी का लाभ उठाने में सक्षम हो सकते हैं, जो कि मैं हमेशा करना चाहता हूं।

अब जब हमें इस बात का अंदाजा हो गया है कि क्या IDORsहैं, उन्हें कहां पाया जा सकता है और साथ ही प्रभाव भी, मेरे शुरुआती निष्कर्षों में गोता लगाने देता है! :)

सैनिक परीक्षण

हालाँकि समस्या का समाधान हो गया था, लेकिन मैं पूर्ण सार्वजनिक प्रकटीकरण की अनुमति प्राप्त नहीं कर सका, इसलिए लक्ष्य को इस रूप में संदर्भित किया जाएगा: example.com. जैसा कि किसी भी लक्ष्य के साथ होता है scope, हमले की सतह का विस्तार करने के लिए उपडोमेन गणना महत्वपूर्ण है। हालाँकि, उपडोमेन गणना हमले की सतह का विस्तार करने का एकमात्र तरीका नहीं है क्योंकि हम JavaScriptसंवेदनशील जानकारी के लिए फ़ाइलों का विश्लेषण भी कर सकते हैं। Google Dorkइस दिए गए मामले में मैंने यह देखने के लिए एक त्वरित के उपयोग के साथ शुरू करने का फैसला किया कि क्या मुझे अधिक परिणामों के लिए स्वचालित टूल का उपयोग करने से पहले कोई दिलचस्प सबडोमेन मिल सकता है।

गूगल डॉर्क:site:*.example.com

Example.comलगभग 36 सबडोमेन थे इसलिए काम करने के लिए सबडोमेन की काफी अच्छी संख्या थी!
एक-एक करके उन्हें देखते हुए मैंने दो सबडोमेन नोट किए जिनमें बहुत अधिक कार्यक्षमता थी। मुझे इन सबडोमेन के चारों ओर नेविगेट करने और उस एप्लिकेशन के लिए विशिष्ट कुछ और दिलचस्प सुविधाओं का मानसिक ध्यान देने के दौरान विभिन्न सुविधाओं का परीक्षण करने में लगभग एक या दो दिन लग गए। उदाहरण के लिए, एप्लिकेशन में एक सुविधा थी जहां आप "भुगतान समस्या" जैसी विभिन्न श्रेणियों के तहत कर्मचारियों से सहायता प्राप्त करने के लिए टिकट बना सकते थे।

प्रारंभिक बग

मैंने साइन-अप और साइन इन प्रक्रिया के काम करने के तरीके का विश्लेषण करके शुरुआत करने का फैसला किया- एक मुख्य विशेषता जो आजकल लगभग सभी वेबसाइटों में लागू है। वेब एप्लिकेशन के साइन-अप प्रवाह को संक्षेप में प्रस्तुत किया जा सकता है:

उपयोगकर्ता ईमेल के माध्यम से साइन अप करता है
खाता निर्माण प्रक्रिया समाप्त होने से पहले उपयोगकर्ता को एक PIN No.और एक सेट करने के लिए कहा जाता है। security questionइसे केवल एक बार सेट किया जा सकता है और बदला नहीं जा सकता
उपयोगकर्ता को साइन इन करने से पहले ईमेल की पुष्टि करने के लिए कहा जाता है

का उपयोग करते हुए account A, मैंने निकाल दिया Burpsuiteऔर टिकट सुविधा का परीक्षण करना शुरू कर दिया और परीक्षण उद्देश्यों के लिए विभिन्न समर्थन श्रेणियों के तहत कुछ टिकटों के निर्माण के बाद दो परीक्षण खाते बनाए। HTTP Historyअंदर देखते हुए Burpsuiteकुछ दिलचस्प कॉल किए जा रहे थे।

पुरस्कार दावों से संबंधित टिकट में स्टाफ सदस्य को जवाब देते समय निम्नलिखित पहल की गई थी:POST request

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

तो अब तक के निष्कर्षों को समाप्त करने के लिए:

PIN No.साइन अप करने पर प्रत्येक उपयोगकर्ता को एक और बनाना होगाsecurity question
वेबसाइट उपयोगकर्ताओं को सहायता के लिए समर्थन टिकट बनाने की अनुमति देती है
समर्थन प्राप्त करने के लिए उपयोगकर्ता को उनके साथ PIN No.और security question answerखाता पुनर्प्राप्ति, पुरस्कार दावों और भुगतान समस्याओं जैसे संवेदनशील मामलों के लिए प्रतिक्रिया देने की आवश्यकता होती है
IDORटिकटिंग सिस्टम के भीतर खोजी गई भेद्यता एक विरोधी को टिकट मालिक या स्टाफ सदस्य के बिना किसी भी समर्थन टिकट के भीतर टिप्पणी करने की अनुमति देती है

तो अगर मैं बिना मालिक या स्टाफ सदस्य विशेषाधिकारों के किसी भी टिकट पर टिप्पणी पोस्ट कर सकता हूं ... निश्चित रूप से इसका मतलब है कि मैं किसी भी टिकट को सही पढ़ सकता हूं?

account Aमैंने निम्न जीईटी अनुरोध को के माध्यम से संबंधित टिकट देखने के प्रयास में कैप्चर किया account B, हालांकि, इससे अवैध 403त्रुटि हुई! इसलिए, मैं किसी भी समर्थन टिकट पर लिख सकता था लेकिन किसी एक की सामग्री को नहीं पढ़ सका। इस बिंदु पर मैं वास्तव में इसे और आगे ले जाने का कोई संभावित तरीका खोजना चाहता था।

वेब एप्लिकेशन पर टिकट पढ़ने के लिए एंडपॉइंट प्राप्त करें

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

टिकटिंग सुविधा का फायदा उठाने का प्रयास करते हुए, मुझे निम्नलिखित अनुरोध पर ठोकर लगी;

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

IOS ऐप में एपीआई के जरिए टिकट की सामग्री लीक करना

प्रारंभिक टोही के दौरान, मैंने देखा कि APIप्रोफ़ाइल जानकारी प्राप्त करते समय कुछ अनुरोध भेजे जा रहे थे, इसके अलावा लक्ष्य का mobile appदायरा भी था। यह अत्यधिक संभावना थी कि हालांकि वेब एप्लिकेशन पर अन्य उपयोगकर्ता टिकटों को पढ़ना स्वयं संभव नहीं था, यह मोबाइल एप्लिकेशन के माध्यम से प्राप्त किया जा सकता है क्योंकि यह API version/endpointवेब एप्लिकेशन की तुलना में भिन्न का उपयोग कर सकता है।

BurpsuiteIOS एप्लिकेशन के भीतर टिकट सत्र में फायरिंग और नेविगेट करते हुए, मैं निम्नलिखित समापन बिंदु पर पहुंचा:

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

तो अब मुझे दो बग मिल गए थे- किसी भी टिकट पर लिखना और किसी अन्य उपयोगकर्ता से संबंधित टिकट की सामग्री को देखना संभव था।

एस्केलेटिंग टिकट रीड आईडीओआर > अकाउंट टेकओवर

इस बिंदु पर मेरे पास खाता अधिग्रहण प्राप्त करने के लिए आवश्यक सभी तत्व थे। जैसा कि किसी भी टिकट को पढ़ना संभव था, उपयोगकर्ता खाता अधिग्रहण निम्न चरणों के माध्यम से किया जा सकता है:

समापन बिंदु पर जाएं /api/v1/support-tickets/234567/postsऔर इसे अधिक से अधिक टिकटों की गणना करने के लिए intruderभेजेंBurpsuite
Grepजैसे Pin Numberया Security Questionप्रतिक्रियाओं से खोजशब्दों के लिए
वेबसाइट पर एक नया खाता बनाएं और नीचे एक टिकट खोलेंaccount recovery
security question answerआवंटित कर्मचारी सदस्य उस खाते का उपयोगकर्ता नाम मांगेगा जिसे आप और के साथ पुनर्प्राप्त करना चाहते हैं PIN No., जो सभी को दूसरी आईडीओआर के माध्यम से लीक किया जा सकता है; इस प्रकार, एक खाता अधिग्रहण के परिणामस्वरूप।

हालाँकि खाता अधिग्रहण पहले ही हासिल कर लिया गया था, टिकट लिखने वाले IDOR का भी लाभ उठाया जा सकता था। कर्मचारी उपयोगकर्ता नाम कंपनी के नाम के साथ उपसर्ग किए गए थे उदा example-John। एक विरोधी कर सकता है;