hacktricks/pentesting-web/domain-subdomain-takeover.md

डोमेन/सबडोमेन टेकओवर

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप अपनी कंपनी को हैकट्रिक्स में विज्ञापित देखना चाहते हैं? या क्या आपको PEASS की नवीनतम संस्करण या HackTricks को PDF में डाउनलोड करने का उपयोग करने की इच्छा है? सदस्यता योजनाएं की जांच करें!
• The PEASS Family की खोज करें, हमारा विशेष NFT संग्रह
• आधिकारिक PEASS & HackTricks swag प्राप्त करें
• 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे Twitter पर फ़ॉलो करें 🐦@carlospolopm.
• अपने हैकिंग ट्रिक्स को hacktricks रेपो और hacktricks-cloud रेपो में PR जमा करके साझा करें।

Trickest का उपयोग करें और आसानी से वर्कफ़्लो बनाएं जो दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित होते हैं।
आज ही पहुंच प्राप्त करें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

डोमेन टेकओवर

यदि आपको कंपनी के एक डोमेन (domain.tld) का पता चलता है जो स्कोप के भीतर किसी सेवा द्वारा उपयोग किया जा रहा है, लेकिन कंपनी ने इसके स्वामित्व को खो दिया है, तो आप इसे रजिस्टर करने का प्रयास कर सकते हैं (यदि यह पर्याप्त सस्ता हो) और कंपनी को बता सकते हैं। यदि इस डोमेन के माध्यम से कुछ संवेदनशील जानकारी जैसे कि एक सत्र कुकी या GET पैरामीटर या Referer हैडर के माध्यम से प्राप्त हो रही है, तो यह निश्चित रूप से एक सुरक्षा कमजोरी है।

सबडोमेन टेकओवर

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

कई उपकरण हैं जिनमें शब्दकोश हैं जिनका उपयोग टेकओवर के लिए किया जा सकता है:

• https://github.com/EdOverflow/can-i-take-over-xyz
• https://github.com/blacklanternsecurity/bbot
• https://github.com/punk-security/dnsReaper
• https://github.com/haccer/subjack
• https://github.com/anshumanbh/tko-sub
• https://github.com/ArifulProtik/sub-domain-takeover
• https://github.com/SaadAhmedx/Subdomain-Takeover
• https://github.com/Ice3man543/SubOver
• https://github.com/m4ll0k/takeover
• https://github.com/antichown/subdomain-takeover
• https://github.com/musana/mx-takeover

BBOT के साथ हाइजैक करने योग्य सबडोमेन के लिए स्कैन करना:

BBOT के डिफ़ॉल्ट सबडोमेन जाँच में सबडोमेन टेकओवर शामिल हैं। हस्ताक्षर सीधे https://github.com/EdOverflow/can-i-take-over-xyz से लिए जाते हैं।

bbot -t evilcorp.com -f subdomain-enum

DNS Wildcard के माध्यम से सबडोमेन टेकओवर उत्पन्न करना

जब एक डोमेन में DNS वाइल्डकार्ड का उपयोग किया जाता है, तो उस डोमेन के किसी भी अनुरोधित सबडोमेन को जो कि विशेष रूप से अलग पता नहीं है, एक ही जानकारी पर पहुंचाया जाएगा। इसमें एक A IP पता, एक CNAME... हो सकता है।

उदाहरण के लिए, यदि *.testing.com को 1.1.1.1 पर वाइल्डकार्ड किया जाता है। तो, not-existent.testing.com 1.1.1.1 को पॉइंट करेगा।

हालांकि, यदि इसे एक IP पते की बजाय, सिसएडमिन इसे CNAME के माध्यम से तीसरी पक्ष सेवा पर पॉइंट करता है, जैसे कि एक github सबडोमेन उदाहरण के लिए (sohomdatta1.github.io)। एक हमलावर अपने खुद के तीसरे पक्ष पृष्ठ (इस मामले में Gihub) को बना सकता है और कह सकता है कि something.testing.com वहां पॉइंट कर रहा है। क्योंकि, CNAME वाइल्डकार्ड हमलावर से सहमत होगा, हमलावर को अपने पृष्ठों के लिए विक्टिम के डोमेन के लिए आर्बिट्रे सबडोमेन उत्पन्न करने की क्षमता होगी।

आप इस दुर्बलता का उदाहरण CTF लेख में ढूंढ सकते हैं: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

सबडोमेन टेकओवर का शोषण

यह जानकारी https://0xpatrik.com/subdomain-takeover/ से कॉपी की गई है

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

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

ब्राउज़र के लिए पारदर्शिता

शुरू करने के लिए, आइए DNS संकलन पर ध्यान दें जहां CNAME शामिल है:

ध्यान दें कि चरण #7 sub.example.com की बजाय anotherdomain.com का अनुरोध करता है। यह इसलिए है क्योंकि वेब ब्राउज़र को यह भी पता नहीं होता है कि anotherdomain.com मौजूद है या नहीं। हालांकि CNAME रिकॉर्ड का उपयोग किया जाता है, ब्राउज़र के URL बार में अभी भी sub.example.com होता है। यह ब्राउज़र के लिए पारदर्शिता है। इसके बारे में सोचें, ब्राउज़र डोमेन के बारे में सटीक जानकारी प्रदान करने के लिए DNS रिज़ॉल्वर पर पूरा विश्वास रखता है। सरलता से कहें तो, सबडोमेन टेकओवर इंटरनेट पर एक विशेष डोमेन के लिए DNS स्पूफिंग है। क्योंकि किसी भी असरित डोमेन पर DNS संकलन करने वाला ब्राउज़र एक हमलावर द्वारा सेट किए गए A रिकॉर्ड प्राप्त करता है। फिर ब्राउज़र खुशी-खुशी इस सर्वर से प्राप्त किसी भी जानकारी को दिखाता है (यह सोचता है कि यह वैध है)।

ऐसा डोमेन फिशिंग के लिए एक पूर्ण स्थिति बनाता है। हमलावर अक्सर त्रुटियों के लिए या इसे [_डोपेलगैं

कुकी चोरी

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

ब्राउज़र स्वचालित रूप से संग्रहीत कुकीज़ को हर अनुरोध के साथ प्रस्तुत करता है जो उन्हें जारी करने वाले डोमेन के लिए हैं। इसमें एक ऐसा अपवाद होता है कि कुकीज़ सबडोमेन के बीच साझा की जा सकती हैं (यहां पढ़ें, इसके अलावा ध्यान दें सेक्शन 8.7)। यह आमतौर पर तब होता है जब वेबसाइट कुकीज़-आधारित एकल प्रवेश (SSO) प्रणाली का उपयोग करती है। SSO का उपयोग करके, उपयोगकर्ता एक सबडोमेन का उपयोग करके लॉगिन कर सकता है और एक विस्तृत सबडोमेन समूह के बीच समान सत्र टोकन साझा कर सकता है। एक नियमित कुकी सेट करने के लिए निम्नलिखित वाक्यांश का उपयोग किया जाता है:

HTTP/1.1 200 OK
Set-Cookie: name=value

यदि यह कुकी example.com पर निवास करने वाले वेब सर्वर द्वारा जारी की जाती है, तो बाद में केवल यह सर्वर इस कुकी तक पहुंच सकता है। हालांकि, कुकी वाइल्डकार्ड डोमेन के लिए जारी की जा सकती है (ऊपर बताए गए कारणों के लिए) निम्नलिखित तरीके से:

HTTP/1.1 200 OK
Set-Cookie: name=value; domain=example.com

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

ब्राउज़र कुकीज़ के लिए अतिरिक्त सुरक्षा युक्तियाँ भी लागू करता है:

• HttpOnly कुकी - कुकीज़ को डिफ़ॉल्ट रूप से वेबसाइट के संदर्भ में चल रहे जावास्क्रिप्ट कोड द्वारा एक्सेस किया जा सकता है जो कुकीज़ बनाने वाली वेबसाइट में चल रहा है। जावास्क्रिप्ट कुकीज़ को पढ़ सकता है, अपडेट कर सकता है और हटा सकता है। वेब सर्वर द्वारा सेट किए गए HttpOnly कुकी फ़्लैग इसका संकेत देता है कि विशेष कुकी को जावास्क्रिप्ट कोड द्वारा एक्सेस नहीं किया जा सकता है। इसे केवल HTTP अनुरोध और प्रतिक्रिया हेडर के माध्यम से प्राप्त किया जा सकता है।
• सुरक्षित कुकी - जब कुकीज़ को वेब सर्वर द्वारा सेट किए गए सुरक्षित फ़्लैग के साथ, तो इसे केवल जब HTTPS का उपयोग किया जाता है, वेब सर्वर को संदेश भेजा जा सकता है।

यदि डोमेन सबडोमेन टेकओवर के लिए संकटग्रस्त है, तो हमलावर उस डोमेन द्वारा जारी की गई कुकीज़ को आसानी से इकट्ठा कर सकता है, बस उपयोगकर्ता को विकल्प सबडोमेन पर आमंत्रित करना होगा। HttpOnly और सुरक्षित फ़्लैग मदद नहीं करते क्योंकि कुकी जावास्क्रिप्ट का उपयोग नहीं करके एक्सेस नहीं किया जा रहा है और लिया गया डोमेन के लिए SSL प्रमाणपत्र आसानी से उत्पन्न किया जा सकता है।

टेकओवर का उपयोग करके कुकी चोरी को अर्ने स्विनेन द्वारा बग बाउंटी रिपोर्ट में समझाया गया था। रिपोर्ट में एक Ubiquiti Networks सबडोमेन (ping.ubnt.com) की समस्या का वर्णन किया गया था। यह सबडोमेन सबडोमेन टेकओवर के लिए संकटग्रस्त था, जो अदावत नहीं किए गए AWS CloudFront वितरण को निशानित कर रहा था। Ubiquiti Networks वाइल्डकार्ड सत्र कुकीज़ के साथ SSO का उपयोग कर रहा है, इसलिए ping.ubnt.com पर जाने वाले सभी उपयोगकर्ताओं की सत्र कुकीज़ चोरी हो सकती थी। हालांकि यह डोमेन AWS CloudFront को निशानित कर रहा है, CloudFront वितरण सेटिंग्स प्रत्येक अनुरोध के साथ कुकीज़ को लॉग करने की अनुमति देती हैं। इसलिए सभी सबडोमेन AWS CloudFront को निशानित करने के साथ भी सत्र कुकीज़ को निकालने की स्थिति पूरी तरह संभव है। 2017 में, अर्ने ने उबर के SSO सिस्टम के खिलाफ समान हमला वेक्टर भी प्रदर्शित किया।

ऊपर बताए गए व्यवहार को कुकीज़ तक ही सीमित नहीं किया जा सकता है। जैसा कि जावास्क्रिप्ट स्क्रिप्ट्स को पूरी तरह से

रोकथाम

सबडोमेन ले व्यवस्थापित डोमेन नामों के लिए रोकथाम रणनीतियाँ बहुत सीधी होती हैं:

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

भविष्य में सबडोमेन ले विरोध को रोकने के लिए, संगठनों को अपने अवसंरचना में संसाधनों को बनाने और नष्ट करने की प्रक्रिया में परिवर्तन करने की आवश्यकता होती है। संसाधन बनाने के मामले में, DNS रिकॉर्ड निर्माण को इस प्रक्रिया का अंतिम कदम होना चाहिए। यह शर्त किसी भी समय डीएनएस रिकॉर्ड को एक अस्तित्वहीन डोमेन पर पहुंचाने से रोकती है। संसाधन नष्टि के मामले में, उल्टा होता है: DNS रिकॉर्ड को इस प्रक्रिया का पहला कदम हटा देना चाहिए। aquatone जैसे उपकरण सबडोमेन ले विरोध के लिए जांच शामिल करते हैं। संगठन की सुरक्षा टीम द्वारा यह जांच नियमित रूप से की जानी चाहिए कि कोई भी विकल्पशील डोमेन नहीं है। अधिकांश संगठनों में उज्ज्वल टीमों के कारण, उज्ज्वल डोमेन नामों के लिए केंद्रीय संग्रह की प्रक्रियाएं आमतौर पर प्रभावी नहीं होती हैं और बाहरी मॉनिटरिंग आमतौर पर सबसे अच्छा तरीका होता है।

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

GitLab जैसे प्रदाताओं ने यह समझा कि सबडोमेन ले विरोध एक मुद्दा है और एक डोमेन सत्यापन मेकेनिज़्म को लागू किया है।

इस पोस्ट के कुछ हिस्से मेरे मास्टर थीसिस से लिए गए हैं।

अगली बार तक!

Patrik

Trickest का उपयोग करें और दुनिया के सबसे उन्नत समुदाय उपकरणों द्वारा संचालित वर्कफ़्लो आसानी से बनाएं और स्वचालित करें।
आज ही पहुंच प्राप्त करें:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• क्या आप किसी साइबर सुरक्षा कंपनी में काम करते हैं? क्या आप चाहते हैं कि आपकी कंपनी HackTricks में विज्ञापित की जाए? या क्या आप PEASS के नवीनतम संस्करण का उपयोग करना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं? सदस्यता योजनाएं देखें!
• The PEASS Family की खोज करें, हमारा विशेष NFT संग्रह
• आधिकारिक PEASS & HackTricks swag प्राप्त करें
• 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या मुझे ट्विटर 🐦@carlospolopm** का**