# Domain/Subdomain takeover

{{#include ../banners/hacktricks-training.md}}


## Domain takeover

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

### Subdomain takeover

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

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

- [https://github.com/EdOverflow/can-i-take-over-xyz](https://github.com/EdOverflow/can-i-take-over-xyz)
- [https://github.com/blacklanternsecurity/bbot](https://github.com/blacklanternsecurity/bbot)
- [https://github.com/punk-security/dnsReaper](https://github.com/punk-security/dnsReaper)
- [https://github.com/haccer/subjack](https://github.com/haccer/subjack)
- [https://github.com/anshumanbh/tko-sub](https://github.com/anshumanbh/tko-subs)
- [https://github.com/ArifulProtik/sub-domain-takeover](https://github.com/ArifulProtik/sub-domain-takeover)
- [https://github.com/SaadAhmedx/Subdomain-Takeover](https://github.com/SaadAhmedx/Subdomain-Takeover)
- [https://github.com/Ice3man543/SubOver](https://github.com/Ice3man543/SubOver)
- [https://github.com/antichown/subdomain-takeover](https://github.com/antichown/subdomain-takeover)
- [https://github.com/musana/mx-takeover](https://github.com/musana/mx-takeover)
- [https://github.com/PentestPad/subzy](https://github.com/PentestPad/subzy)
- [https://github.com/Stratus-Security/Subdominator](https://github.com/Stratus-Security/Subdominator)
- [https://github.com/NImaism/takeit](https://github.com/NImaism/takeit)

### Subdomain Takeover Generation via DNS Wildcard

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

उदाहरण के लिए, यदि `*.testing.com` को `1.1.1.1` पर वाइल्डकार्ड किया गया है। तब, `not-existent.testing.com` `1.1.1.1` की ओर इशारा करेगा।

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

आप इस कमजोरी का एक उदाहरण CTF लेखन में पा सकते हैं: [https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api](https://ctf.zeyu2001.com/2022/nitectf-2022/undocumented-js-api)

## Exploiting a subdomain takeover

उपडोमेन टेकओवर मूल रूप से इंटरनेट पर एक विशिष्ट डोमेन के लिए DNS धोखाधड़ी है, जिससे हमलावरों को एक डोमेन के लिए A रिकॉर्ड सेट करने की अनुमति मिलती है, जिससे ब्राउज़र हमलावर के सर्वर से सामग्री प्रदर्शित करते हैं। यह **पारदर्शिता** ब्राउज़रों में डोमेन को फ़िशिंग के प्रति संवेदनशील बनाती है। हमलावर [_typosquatting_](https://en.wikipedia.org/wiki/Typosquatting) या [_Doppelganger domains_](https://en.wikipedia.org/wiki/Doppelg%C3%A4nger) का उपयोग कर सकते हैं। विशेष रूप से संवेदनशील वे डोमेन हैं जहां फ़िशिंग ईमेल में URL वैध प्रतीत होता है, उपयोगकर्ताओं को धोखा देता है और डोमेन की अंतर्निहित विश्वसनीयता के कारण स्पैम फ़िल्टर से बचता है।

इस [पोस्ट को आगे की जानकारी के लिए देखें](https://0xpatrik.com/subdomain-takeover/)

### **SSL Certificates**

SSL प्रमाणपत्र, यदि हमलावरों द्वारा [_Let's Encrypt_](https://letsencrypt.org/) जैसी सेवाओं के माध्यम से उत्पन्न किए जाते हैं, तो इन नकली डोमेन की वैधता को बढ़ाते हैं, जिससे फ़िशिंग हमलों को और अधिक विश्वसनीय बनाया जा सकता है।

### **Cookie Security and Browser Transparency**

ब्राउज़र की पारदर्शिता कुकी सुरक्षा तक भी फैली हुई है, जिसे [Same-origin policy](https://en.wikipedia.org/wiki/Same-origin_policy) जैसी नीतियों द्वारा नियंत्रित किया जाता है। कुकीज़, जो अक्सर सत्रों का प्रबंधन करने और लॉगिन टोकन को स्टोर करने के लिए उपयोग की जाती हैं, उपडोमेन टेकओवर के माध्यम से शोषित की जा सकती हैं। हमलावर **सत्र कुकीज़** को केवल उपयोगकर्ताओं को एक समझौता किए गए उपडोमेन पर निर्देशित करके इकट्ठा कर सकते हैं, जिससे उपयोगकर्ता डेटा और गोपनीयता को खतरा होता है।

### CORS Bypass

यह संभव हो सकता है कि हर उपडोमेन को मुख्य डोमेन या अन्य उपडोमेन से CORS संसाधनों तक पहुंचने की अनुमति हो। इसका उपयोग एक हमलावर द्वारा **संवेदनशील जानकारी** तक पहुंचने के लिए CORS अनुरोधों का दुरुपयोग करने के लिए किया जा सकता है।

### CSRF - Same-Site Cookies bypass

यह संभव हो सकता है कि उपडोमेन को डोमेन या अन्य उपडोमेन को कुकीज़ भेजने की अनुमति हो, जिसे कुकीज़ के `Same-Site` विशेषता द्वारा रोका गया था। हालाँकि, ध्यान दें कि एंटी-CSRF टोकन अभी भी इस हमले को रोकेंगे यदि उन्हें सही तरीके से लागू किया गया हो।

### OAuth tokens redirect

यह संभव हो सकता है कि समझौता किया गया उपडोमेन OAuth प्रवाह के `redirect_uri` URL में उपयोग करने की अनुमति हो। इसका उपयोग एक हमलावर द्वारा **OAuth टोकन** चुराने के लिए किया जा सकता है।

### CSP Bypass

यह संभव हो सकता है कि समझौता किया गया उपडोमेन (या हर उपडोमेन) को CSP के `script-src` के लिए उपयोग करने की अनुमति हो। इसका उपयोग एक हमलावर द्वारा **दुष्ट स्क्रिप्टों को इंजेक्ट करने** और संभावित XSS कमजोरियों का दुरुपयोग करने के लिए किया जा सकता है।

### **Emails and Subdomain Takeover**

उपडोमेन टेकओवर का एक और पहलू ईमेल सेवाओं से संबंधित है। हमलावर **MX रिकॉर्ड** को हेरफेर कर सकते हैं ताकि वे एक वैध उपडोमेन से ईमेल प्राप्त या भेज सकें, जिससे फ़िशिंग हमलों की प्रभावशीलता बढ़ती है।

### **Higher Order Risks**

अन्य जोखिमों में **NS रिकॉर्ड टेकओवर** शामिल हैं। यदि एक हमलावर किसी डोमेन के एक NS रिकॉर्ड पर नियंत्रण प्राप्त करता है, तो वे संभावित रूप से ट्रैफ़िक के एक हिस्से को अपने नियंत्रण में सर्वर की ओर निर्देशित कर सकते हैं। यदि हमलावर DNS रिकॉर्ड के लिए उच्च **TTL (Time to Live)** सेट करता है, तो यह जोखिम बढ़ जाता है, जिससे हमले की अवधि बढ़ जाती है।

### CNAME Record Vulnerability

हमलावर उन अनक्लेम्ड CNAME रिकॉर्ड का शोषण कर सकते हैं जो अब उपयोग में नहीं हैं या जिन्हें बंद कर दिया गया है। इससे उन्हें विश्वसनीय डोमेन के तहत एक पृष्ठ बनाने की अनुमति मिलती है, जिससे फ़िशिंग या मैलवेयर वितरण को और बढ़ावा मिलता है।

### **Mitigation Strategies**

कमजोरियों को कम करने की रणनीतियों में शामिल हैं:

1. **कमजोर DNS रिकॉर्ड को हटाना** - यदि उपडोमेन अब आवश्यक नहीं है तो यह प्रभावी है।
2. **डोमेन नाम का दावा करना** - संबंधित क्लाउड प्रदाता के साथ संसाधन को पंजीकृत करना या एक समाप्त डोमेन को फिर से खरीदना।
3. **कमजोरियों के लिए नियमित निगरानी** - [aquatone](https://github.com/michenriksen/aquatone) जैसे उपकरण संवेदनशील डोमेन की पहचान करने में मदद कर सकते हैं। संगठनों को अपनी अवसंरचना प्रबंधन प्रक्रियाओं की समीक्षा करनी चाहिए, यह सुनिश्चित करते हुए कि DNS रिकॉर्ड निर्माण संसाधन निर्माण में अंतिम कदम और संसाधन विनाश में पहला कदम है।

क्लाउड प्रदाताओं के लिए, डोमेन स्वामित्व की पुष्टि करना उपडोमेन टेकओवर को रोकने के लिए महत्वपूर्ण है। कुछ, जैसे कि [GitLab](https://about.gitlab.com/2018/02/05/gitlab-pages-custom-domain-validation/), ने इस समस्या को पहचाना है और डोमेन सत्यापन तंत्र लागू किए हैं।

## References

- [https://0xpatrik.com/subdomain-takeover/](https://0xpatrik.com/subdomain-takeover/)
- [https://www.stratussecurity.com/post/subdomain-takeover-guide](https://www.stratussecurity.com/post/subdomain-takeover-guide)
- [https://www.hackerone.com/blog/guide-subdomain-takeovers-20](https://www.hackerone.com/blog/guide-subdomain-takeovers-20)

{{#include ../banners/hacktricks-training.md}}