साइटों पर कमजोरियों की एक उलझन को उजागर करना

कोडबी पर प्रकाशित मेरे पहले लेख के बाद, जिसने सप्ताह के शीर्ष 3 प्रकाशनों में प्रवेश किया, मैं अगले एक को लिखने के लिए बहुत प्रेरित हुआ। लेकिन 11 वीं कक्षा परीक्षा और ओलंपियाड की तैयारी के लिए खाली समय पर प्रतिबंध लगाती है। इसलिए, मैं सभी ओलंपियाड से बाहर उड़ान भरने के कुछ महीनों के बाद ही दूसरा लिखता हूं।

यह प्रकाशन एक दिलचस्प मामले के बारे में बात करेगा जब एक संसाधन पर मिली एक भेद्यता ने उन्हें कई अन्य साइटों पर खोजने की एक श्रृंखला प्रदान की।

शुरू

यह सब जाली उत्पादों के एक प्रमुख निर्माता की साइट की जाँच के साथ शुरू हुआ। उपयोगकर्ता का व्यक्तिगत खाता नहीं था, और भेद्यता खोज क्षेत्र बहुत व्यापक नहीं था।

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

मैंने प्राप्त कुकीज़ को प्रतिस्थापित किया और साइट सिस्टम के crm खाते में लॉग इन किया (मैं विरोध नहीं कर सकता था, पहली बार मैं इतना भाग्यशाली था)। अधिकार व्यवस्थापक नहीं थे, लेकिन वे आदेश सहित किसी भी आंकड़े तक पहुंचने के लिए पर्याप्त थे और ग्राहक डेटा।



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



ऑर्डर सबमिशन फॉर्म का परीक्षण करने के बाद, मैंने यह भी पाया कि एक iDOR भेद्यता है जो आपको POST अनुरोध में डोमेन "json_order [0] [मूल्य]" और "json_order [0] [कुल]" मापदंडों को संपादित करके domain.ru/shop.php की अनुमति देता है। । Json_order [0] [href] फ़ील्ड में एक ही अनुरोध में आदेश लिंक का प्रतिस्थापन एक RFI के लिए नेतृत्व किया।

नए खोज के बारे में संदेश को कोई जवाब नहीं मिला ...

विस्तार

उस crm साइट पर सिस्टम स्व-लिखित नहीं था, लेकिन एक प्रसिद्ध सेवा द्वारा भुगतान के लिए प्रदान किया गया था। कुकी के साथ उनकी गलती के बाद, यह मानना ​​तर्कसंगत था कि अन्य कमजोरियां होंगी।

यदि ऑर्डर फॉर्म के माध्यम से मेरे द्वारा भेजी गई स्क्रिप्ट काम करती है, तो वांछित साइट पर और crm सिस्टम में कोई फ़ील्ड सत्यापन नहीं था। x2। इसलिए, एक परीक्षण खाता प्राप्त करने के बाद, मैंने xss के लिए असुरक्षित क्षेत्रों की खोज करके शुरुआत की।

व्यापक crm प्रणाली के माध्यम से लंबी यात्राओं के बाद, अपर्याप्त सत्यापन के साथ एक दर्जन से अधिक क्षेत्रों की पहचान की गई थी। कहीं, आप सीधे स्क्रिप्ट टैग को सम्मिलित कर सकते हैं, कहीं आपको "ऑनमॉउवर = अलर्ट ()" प्रकार की इन-लाइन स्क्रिप्ट का उपयोग करना था। इसके अलावा, कुछ स्थानों पर एक स्क्रिप्ट को एम्बेड करना संभव था, लेकिन कुछ स्थानों में, मुझे आश्चर्य है कि वे किस तर्क द्वारा निर्देशित थे, कुछ स्थानों में फ़िल्टरिंग और अन्य में नहीं? खेतों के तार्किक उद्देश्य के दृष्टिकोण से, मैंने एक पैटर्न नहीं देखा। कुछ स्थानों पर, जहां लगभग सभी लोग नहीं जाएंगे, सब कुछ ठीक रहा, लेकिन उदाहरण के लिए, उन्होंने प्रतिपक्ष के नाम पर फ़िल्टरिंग को जोड़ने की जहमत नहीं उठाई।

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

एक्सएस के साथ उस पर यह खत्म हो गया था, अधिक दिलचस्प चीजों को पारित करना संभव था।

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

हैरानी की बात है कि सीएसआरएफ के खिलाफ कोई सुरक्षा नहीं थी। किसी भी अनुरोध को भेजना संभव था, चेक कहीं भी नहीं किए गए थे।
- खाता जानकारी बदलें? - कृपया
- माल का नाम और कीमत बदलें? - कोई सवाल नहीं

एक ही समय में, कुकीज़ में "सिस्टरफोकन" नामक कुछ समाहित था।

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

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

खोजे गए csrf के साथ, हमारा xss, जो पहले बाहर से सुलभ नहीं था, दूसरा जीवन प्राप्त करता है। आखिरकार, हमें कमजोर क्षेत्रों को संपादित करने के लिए अपने खाते में जाने की आवश्यकता नहीं है।

इसके अलावा, फ़ाइल के माइम-प्रकार के प्रतिस्थापन के माध्यम से, सर्वर पर मनमानी फ़ाइलों को अपलोड करना संभव था। लेकिन सर्वर को सही तरीके से कॉन्फ़िगर किया गया था और php स्क्रिप्ट को वहां निष्पादित नहीं किया गया था।

आगे और भी दिलचस्प। ऑनलाइन स्टोर माल के बारे में सभी डेटा crm से लिया। यानी नाम, विवरण, फोटो। उत्पाद छवि का लिंक "yyyy.domain.ru/file/get/id=xxx" था। ऑनलाइन स्टोर छवियों को लेने में सक्षम होने के लिए, उनके पास सभी के लिए पढ़ने के अधिकार होने चाहिए। 122।

उन रास्तों की जाँच की जिनके साथ अन्य, अधिक निजी फाइलें संग्रहीत हैं, मैंने वही url देखा। यह आश्चर्य की बात नहीं है, उनके पास संभवतः अन्य एक्सेस अधिकार हैं। निश्चित रूप से 022 से कम नहीं है। लेकिन, वास्तविकता थोड़ी अलग हो गई, उनके पास अनधिकृत उपयोगकर्ताओं के लिए मुफ्त पहुंच भी थी।

- क्या आपने एक्सेल फ़ाइल में ऑर्डर डेटा आयात करने का अनुरोध किया है? - बढ़िया, अब कोई भी इसे डाउनलोड कर सकता है।

शायद वहाँ आईडी "yt5bjFb54hb # HJ% $ p" जैसी दिखती थी और ब्रूट फोर्स में नहीं दी थी? नहीं, या तो। सभी आईडी फ़ाइलों में एक संख्यात्मक प्रारूप था और कई हजार की सीमा में थे। क्रूरता के खिलाफ संरक्षण, मैंने भी ध्यान नहीं दिया। 1 से 10000 बाधाओं तक सभी आईडी को स्कैन करने से मुलाकात नहीं हुई। कई बार दोहराया गया, किसी को भी इस तरह की गतिविधि में कोई दिलचस्पी नहीं थी।

उन्होंने 3 दिनों में मेरी रिपोर्ट का जवाब दिया।

एक झंडे की कमी के बारे में, httponly ने कहा कि यह गायब था "जाहिर है बहुत समय पहले, क्योंकि php संस्करण अद्यतन किया गया था।" उसी दिन मुड़ गए।

Xss के अनुसार उन्होंने कहा कि हर कोई जानता है कि गर्मी की शुरुआत में फ़िल्टर बंद कर दिया गया था (उस समय यह पहले से ही अगस्त था), यह निश्चित रूप से नहीं समझाता है कि कहीं और क्यों फ़िल्टर किया गया था, लेकिन कहीं नहीं, लेकिन चलो बहाना करते हैं कि हमने इस पर ध्यान नहीं दिया विसंगति। उन्होंने यह भी आश्वासन दिया कि फिल्टर एक दो दिनों में लॉन्च किया जाएगा। वास्तव में, यह पता चला है कि कुछ महीनों में। लेकिन, यहां मैं उन्हें पूरी तरह से समझता हूं: मैंने भी कुछ दिनों में परीक्षा की तैयारी शुरू करने की योजना बनाई ...

सर्वर के लिए मनमानी फ़ाइलों को अपलोड करना उनके लिए थोड़ा चिंता का विषय था, क्योंकि वे सर्वर पर निष्पादित नहीं होते हैं, जिसका अर्थ है कि चिंता करने की कोई बात नहीं है। केवल लेख लिखने के समय ही मुझे इस बात का अंदाजा हो गया था कि अगर कोई साइट जो पहले से ही crm के अलावा किसी अन्य होस्टिंग पर है, वह स्टोरफ्रंट के लिए उत्पाद की एक छवि लेने की कोशिश कर रही है, लेकिन उसे php स्क्रिप्ट मिलती है, तो क्या वह इसे निष्पादित करेगा? या इस तथ्य के कारण कि यह img टैग के लिए अभिप्रेत है, क्या इसे केवल एक छवि के रूप में संसाधित किया जाएगा? या यह सर्वर सेटिंग्स पर निर्भर करता है? कृपया जानकार लोगों को जवाब दें।

सीएसआरएफ रिपोर्ट की प्रतिक्रिया काफी दिलचस्प रही। उन्होंने एक सवाल का जवाब दिया: "आप सीएसआरएफ हमलों के खिलाफ सुरक्षा के लिए एक टोकन को क्या मानते हैं?" वास्तव में, मैं किस बारे में बात कर रहा हूं?



उन्होंने किसी भी फाइल तक मुफ्त पहुंच के बारे में कहा कि उन्होंने इस क्षण को ध्यान में नहीं रखा। तुरंत बंद कर दिया गया।

मुझे कहना होगा कि यह एकमात्र ऐसा समय था जब मुझे वास्तव में नकद पुरस्कार प्राप्त होने की उम्मीद थी। साइट बड़ी है, crm को छोड़कर अभी भी एक भुगतान परियोजना नहीं है। लोकप्रिय ऑनलाइन पत्रिका। लेकिन उन्हें केवल मौखिक आभार प्राप्त हुआ।
मुझे उन्हें धन्यवाद देना चाहिए, मैं भुगतान के मुद्दे के बारे में और भी शांत हो गया। किसी भी रूप में कृतज्ञता के लिए काम अंत में कुछ भी नहीं होगा। आपको किसी भी प्रशंसा और अन्य सम्मान की आदत होगी, और वे संतुष्टि लाने के लिए संघर्ष करेंगे। और अगर आपने उनके लिए सब कुछ किया, तो कुछ करने का अर्थ खो जाएगा। और आप अपनी गतिविधि की प्रक्रिया का आनंद नहीं खो सकते हैं, नई समस्याओं को हल कर सकते हैं, कुछ नया बना सकते हैं। काम के लिए काम करो, चाहे वह कितना भी अच्छा क्यों न हो। जिस काम के दौरान आप यह नहीं देखते हैं कि घंटे कैसे चलते हैं, सूरज न केवल क्षितिज से परे जाने में कामयाब रहा, बल्कि इसके कारण फिर से उठने के लिए।

'' ''
हम छोटे से संतुष्ट हैं, खुशी बड़े पैसे में नहीं है
"आप जो प्यार करते हैं वह करें" - हमारी मंडलियों में सराहना की
'' '© कोल्या मनु - हर दिन

अंत

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



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



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

कुछ हफ़्ते के बाद, बग को ठीक किया गया था।

मैं अंत तक पढ़ने वाले सभी को धन्यवाद देता हूं!