कैसे मैंने एक होस्टिंग प्रदाता को हैक किया



हाल ही में, मुझे त्रुटियों और कमजोरियों के लिए विभिन्न सेवाओं के संचालन की जांच के लिए एक प्रस्ताव मिलना शुरू हुआ। और ऐसे प्रस्तावों में मैं परिणाम के लिए काम करने की कोशिश करता हूं और प्रक्रिया से अधिकतम आनंद प्राप्त करता हूं। लेकिन अंतिम "प्रोजेक्ट" के परिणाम ने मुझे कम से कम कहने के लिए झटका दिया।

मुझे होस्टिंग प्रदाता का परीक्षण करने के लिए कहा गया था।

मैं नाम का खुलासा नहीं करूंगा। और अपनी कहानी में मैं Hoster नाम का उपयोग करूंगा। साइट के साथ, होस्टिंग सेवा सभी मानक थी। VDS, डोमेन, एसएसएल प्रमाणपत्र खरीदने का प्रस्ताव।

सबसे पहले, मुझे आश्चर्य हुआ कि उपयोगकर्ता का व्यक्तिगत खाता कैसे लागू किया गया था? पंजीकरण के दौरान ईमेल पते के स्वामित्व का प्रमाण आवश्यक नहीं था। यही है, आप ईमेल पते steve.jobs@apple.com के साथ पंजीकरण कर सकते हैं। या बेहतर अभी तक, support@hoster.com।

लेकिन सौभाग्य से, इस कहानी के अनुरूप, सेवा समर्थन डेस्क की संवेदनशील जानकारी का खुलासा नहीं हुआ।

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

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

  • कितने सक्रिय उपयोगकर्ता हैं।
  • कितने डोमेन नियंत्रण में हैं।
  • कितने वीडीएस तैनात हैं।

और बहुत कुछ ...



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

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

परिणाम समझाने से अधिक थे। और मैंने पहले ही इस परियोजना को पूरा करने की योजना बना ली है। लेकिन किसी कारण से, मुझे फिर से पंजीकरण के दौरान ईमेल पते के मालिक की पुष्टि की कमी की समस्या याद आई। और वह उन स्थितियों के साथ आने लगा, जिसमें यह होस्टिंग और उसके मालिकों के लिए अधिकतम समस्याएं पैदा कर सकता है। कुछ बिंदु पर, मैंने उसी कंपनी की अन्य परियोजनाओं के साथ इस होस्टिंग सेवा के मालिकों के संबंधों के बारे में सोचना शुरू किया, जिनके बारे में मुझे पता था। कुछ मिनटों के बाद, मैंने उसी कंपनी की एक अन्य परियोजना के ईमेल पते के साथ एक खाता पंजीकृत किया (इसे support@example.com किया जाए)। फिर मैं अपने बनाए हुए खाते suppot@example.com पर domain example.com को बांधने में कामयाब रहा। लेकिन मैं अभी भी बाध्य डोमेन की सामग्री को नियंत्रित नहीं कर सका।

लेकिन वह example.com सेवा की ओर से ईमेल के साथ पूरी तरह से मछली पकड़ सकता है।



यह स्पष्ट नहीं है कि प्रतिक्रिया पत्र कहां आए। क्योंकि मैंने ऐसे ही एक परीक्षा पत्र का उत्तर दिया। लेकिन मुझे खुद जवाब नहीं मिला। यह शायद ईमेल अकाउंट support@example.com के असली मालिक की प्रतिक्रिया में चला गया।

और फिर कुछ ऐसा हुआ जिसके लिए मैंने इस लेख को लिखने का फैसला किया।

मैं भूले हुए उपडोमेन को हल करने में कामयाब रहा। क्लासिक सबडोमेन अधिग्रहण की चपेट में। आप इसके बारे में और अधिक यहाँ पढ़ सकते हैं।

मुझे नहीं पता कि क्यों, लेकिन मैंने एक गैर-डोमेन डोमेन के लिए एक बंधन जोड़ने की कोशिश की। और मैंने कर दिया।



उपडोमेन को सफलतापूर्वक जोड़ा गया था और मैं इस उपडोमेन की सामग्री को नियंत्रित कर सकता था। और सामग्री प्रदर्शित की गई थी।



लेकिन यह एक ही नहीं हो सकता है! ऐसा कैसे! सब के बाद, क्लासिक उपडोमेन अधिग्रहण कमजोरता केवल मौजूदा उपडोमेन के साथ काम करती है।

यह स्थिति बिल्कुल मेरे सिर में नहीं बैठी। यही है, ठीक है, मैं अपने रिश्ते के सत्यापन स्तरों को example.com पर बायपास करने में सक्षम था, जो कभी मेरा नहीं है ( उदाहरण के लिए धन्यवाद। मेरे खाते के नाम में .com)। लेकिन सबडोमेन को कैसे जोड़ना संभव है और ए, TXT, CNAME रिकॉर्ड में किसी भी जाँच घटक के बिना उन्हें नियंत्रित करना संभव है ...?

आमतौर पर मैं इसे देखता हूं - हम आपके साथ एक उपडोमेन जोड़ेंगे, केवल आप साबित करते हैं कि आप इसे कर सकते हैं। जाओ और TXT इस हैश ololopyshpyshpyshbdysh123 में जोड़ें

लेकिन ऐसा कुछ नहीं था। Admin.example.com उपडोमेन चाहते हैं? कोई बात नहीं!



मानो एक सबडोमेन टेकओवर वी 2 भेद्यता।

परीक्षण की गई होस्टिंग सेवा के मालिकों के साथ जल्दी से संवाद करने की क्षमता के कारण - मैंने यह बॉक्स पैंडोरा खोला।

यह निम्नलिखित निकला। होस्टिंग CloudFlare के माध्यम से काम किया। और उन्होंने बहुत ही चालाक तरीके से काम किया।
मैं सरल शब्दों में समझाने की कोशिश करूंगा।

मोटे तौर पर, मैं तुमसे कहता हूं, मेरे पास आओ, मैं तुम्हारी मेजबानी करूंगा। अपने डोमेन मुझे सौंप दें।
और फिर मैं उन्हें सही मानते हुए, सभी आवक कॉलों को CloudFlare पर अंधाधुंध भेज देता हूं।
और अगर आपने मुझ पर vasya.ru डोमेन के साथ भरोसा किया, और एक पड़ोसी आया और परीक्षण के साथ साइट को zapilit कर दिया। मुझे यह भी होस्टिंग के लिए दिया, तो मेरे सर्वर, CloudFlare तक पहुंच और पहले से ही vasya.ru के अधिकार होने के बाद, समस्याओं के बिना तीसरे स्तर को जोड़ा। एक पड़ोसी और सभी नियमों के लिए डोमेन, जल्दी और बिना सवाल के। सभी DNS के लिए, CloudFlare से सही जानकारी आ गई है। और CloudFlare मुझ पर भरोसा करता है।

आमतौर पर, होस्टिंग प्रदाता अपनी DNS सेवाओं को कॉन्फ़िगर करते हैं। लेकिन यहाँ यह पता चला है कि उन्होंने धोखा दिया और बस एक उपयोगकर्ता से CloudFlare को सब कुछ स्थानांतरित कर दिया।

इसलिए हमारे पास एक उपडोमेन टेकओवर God_mode है। सच है, यह केवल उन पतों के साथ काम करता है जो होस्टिंग पहले से ही नियंत्रित करते हैं। लेकिन पहले खोजे गए सर्विस एडमिन पैनल के साथ संयोजन में - यह होस्टर और होस्टिंग सेवा क्लाइंट दोनों पर एक चाल खेल सकता है।

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

पुनश्च: टिप्पणियाँ और लेख पर सुझावों का स्वागत है। तकनीकी सलाह के लिए Patriot2k को विशेष धन्यवाद! मैं कुछ दिलचस्प परीक्षण के लिए सुझावों के लिए भी खुला हूं।

Source: https://habr.com/ru/post/hi431398/


All Articles