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

AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

यदि आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे या HackTricks को PDF में डाउनलोड करें, तो सब्सक्रिप्शन प्लान्स देखें!
आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
The PEASS Family की खोज करें, हमारा विशेष NFTs संग्रह
💬 Discord group में शामिल हों या telegram group में या Twitter पर 🐦 @carlospolopm को फॉलो करें.
अपनी हैकिंग ट्रिक्स साझा करें HackTricks और HackTricks Cloud github repos में PRs सबमिट करके.

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

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

डोमेन टेकओवर

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

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

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

संभावित टेकओवर्स की जांच के लिए कई उपकरण और शब्दकोश हैं:

BBOT के साथ Hijackable सबडोमेन्स के लिए स्कैनिंग:

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

bbot -t evilcorp.com -f subdomain-enum

DNS Wildcard के माध्यम से Subdomain Takeover जनरेशन

जब किसी डोमेन में DNS wildcard का उपयोग किया जाता है, तो उस डोमेन का कोई भी अनुरोधित subdomain जिसका अलग से पता स्पष्ट रूप से नहीं है, एक ही जानकारी को हल करेगा। यह A ip पता, CNAME हो सकता है...

उदाहरण के लिए, अगर *.testing.com को 1.1.1.1 पर wilcarded किया गया है। तो, not-existent.testing.com 1.1.1.1 पर pointing होगा।

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

इस कमजोरी का एक उदाहरण आप CTF write-up में पा सकते हैं: https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api

Subdomain takeover का शोषण

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

हाल ही में, मैंने subdomain takeover के मूल बातों के बारे में लिखा था। हालांकि अब यह अवधारणा सामान्य रूप से समझी जा चुकी है, मैंने देखा कि लोग आमतौर पर subdomain takeover के जोखिमों को समझने में संघर्ष करते हैं। इस पोस्ट में, मैं गहराई से जाकर subdomain takeover के सबसे उल्लेखनीय जोखिमों को मेरे दृष्टिकोण से कवर करता हूँ।

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

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

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

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

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

वास्तव में, डोमेन नाम स्वयं एक सफल अभियान में महत्वपूर्ण भूमिका निभाता है। 5वें स्तर के subdomain को subdomain takeover के लिए संवेदनशील होना बहुत कम "वैध" है कि कुछ अनुकूल subdomain नाम के साथ 2nd स्तर के subdomain होना। मैंने फ़िशिंग के लिए सही subdomains के कई उदाहरण देखे हैं, जिनमें शामिल हैं:

purchases.SOMETHING.com
www.SOMETHING.com
online.SOMETHING.com
shop.SOMETHING.com

इन सभी को subdomain takeover के लिए संवेदनशील पाया गया। ये सभी बड़े ब्रांड थे। फ़िशिंग के बारे में बात करना?

फिर भी, हाल के फ़िशिंग अभियानों में लंबे डोमेन नामों के साथ डोमेन पर सामग्री होस्ट की जाती है जिसमें ब्रांड का नाम शामिल होता है (देखें Apple उदाहरण)। वैध SSL प्रमाणपत्र (इसके बारे में नीचे और अधिक), डोमेन नाम में कीवर्ड और लक्षित ब्रांड की वेबसाइट की नकल करने वाली वेबसाइट के साथ, लोग इन हमलों में फंस जाते हैं। इस ब्रांड के एक वैध subdomain के साथ मौके के बारे में सोचें।

Trickest का उपयोग करके आसानी

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 अनुरोध और प्रतिक्रिया हेडर्स के माध्यम से है।
* **Secure कुकी** — जब कुकी में वेब सर्वर द्वारा _Secure_ फ्लैग सेट किया जाता है, तो यह केवल HTTPS का उपयोग करते समय वेब सर्वर को वापस संवाद किया जा सकता है।

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

Arne Swinnen द्वारा बग बाउंटी [रिपोर्ट](https://hackerone.com/reports/172137) में टेकओवर का उपयोग करके कुकी चोरी की व्याख्या की गई थी। रिपोर्ट में _Ubiquiti Networks_ के सबडोमेन (_ping.ubnt.com_) की समस्या की व्याख्या की गई है। यह सबडोमेन सबडोमेन टेकओवर के लिए संवेदनशील था, जो अनक्लेम्ड AWS CloudFront वितरण की ओर इशारा कर रहा था। चूंकि Ubiquiti Networks SSO का उपयोग कर रहा है वाइल्डकार्ड सत्र कुकीज़ के साथ, _ping.ubnt.com_ पर जाने वाले सभी उपयोगकर्ताओं के सत्र कुकीज़ चोरी हो सकती हैं। यद्यपि यह डोमेन AWS CloudFront की ओर इशारा कर रहा है, CloudFront वितरण सेटिंग्स प्रत्येक अनुरोध के साथ कुकीज़ को लॉग करने की अनुमति देती हैं। इसलिए AWS CloudFront की ओर इशारा करने वाले सबडोमेन्स के साथ भी सत्र कुकीज़ को निकालने की परिदृश्य पूरी तरह से संभव है। 2017 में, Arne ने [Uber के SSO सिस्टम](https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/) के खिलाफ समान हमला वेक्टर का प्रदर्शन किया।

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

हालांकि, ब्राउज़र में जावास्क्रिप्ट फ़ाइलों की अखंडता की रक्षा करने का एक तरीका है। _Subresource Integrity_ [का प्रस्ताव किया गया](https://www.w3.org/TR/2016/REC-SRI-20160623/) एक तंत्र के रूप में HTML5 में _script_ टैग के लिए _integrity_ विशेषता के रूप में क्रिप्टोग्राफिक हैश शामिल करने के लिए। जब प्रदान किया गया क्रिप्टोग्राफिक हैश डाउनलोड फ़ाइल से मेल नहीं खाता है, तो ब्राउज़र इसे निष्पादित करने से इनकार कर देता है।

### ई-मेल्स <a href="#emails" id="emails"></a>

जब CNAME सबडोमेन टेकओवर संभव है, तो MX रिकॉर्ड्स को भी हमलावर द्वारा किसी मनमाने वेब सर्वर पर सेट किया जा सकता है। यह किसी ब्रांड के वैध सबडोमेन पर ई-मेल्स प्राप्त करने की अनुमति देता है - विशेष रूप से (स्पीयर) फ़िशिंग हमलों में उपयोगी जहां हमलावर और पीड़ित के बीच इंटरैक्शन आवश्यक है। हमलावर आमतौर पर `Return-Path` हेडर को स्पूफ करते हैं ताकि ई-मेल के जवाब को प्राप्त कर सकें। सही MX रिकॉर्ड्स के साथ, यह समस्या दरकिनार की जा सकती है।

दूसरी ओर, ई-मेल्स भेजना भी संभव है। हालांकि `From` हेडर को किसी भी ई-मेल पते को शामिल करने के लिए स्पूफ करना तुच्छ है, SPF फ़िल्टर्स आमतौर पर `Return-Path` हेडर और डोमेन के लिए अनुमत मेल-भेजने वाले होस्ट्स की जांच करते हैं। SPF DNS TXT रिकॉर्ड्स में कॉन्फ़िगरेशन स्टोर करता है। सबडोमेन टेकओवर के साथ, TXT रिकॉर्ड्स भी हमलावर के नियंत्रण में होते हैं - SPF जांच को आसानी से पास किया जा सकता है।

_जैसा कि मैंने शुरुआत में नोट किया, ये तकनीक

28 KiB Raw Blame History