असल में डोमेन हाईजैक कैसे होता है: हमले के 5 तरीके और उन्हें रोकने के उपाय

"डोमेन हाईजैकिंग" (Domain hijacking) एक ऐसा वाक्यांश है जो सुनने में काफी नाटकीय लगता है, लेकिन यह कैसे होता है, इसके आधार पर इसके कई अलग-अलग मतलब हो सकते हैं। फ़िशिंग ईमेल के ज़रिए रजिस्ट्रार अकाउंट पर कब्ज़ा करना एक हाईजैक है। DNS प्रोवाइडर पर चुपके से नेमसर्वर रिकॉर्ड बदल देना भी हाईजैक है। कोई एक्सपायर हो चुका डोमेन जिसे कोई और कब्ज़ा कर ले और री-पॉइंट कर दे, तो एक तरह से यह भी हाईजैक ही है।

हर मामले में, परिणाम एक ही होता है: कोई और अब दुनिया को बता रहा होता है कि आपका डोमेन नाम कहाँ पॉइंट करता है। ईमेल, पेमेंट्स, लॉगिन फ्लो, और SaaS इंटिग्रेशन—ये सभी हमलावर को ट्रैफ़िक भेजना शुरू कर देते हैं। रिकवरी (बहाली) में अक्सर कई दिन, और कभी-कभी हफ़्तों लग जाते हैं। यदि डोमेन किसी दूसरे रजिस्ट्रार को ट्रांसफर कर दिया गया था, तो ICANN की Transfer Dispute Resolution Policy (TDRP) काम आ सकती है; अन्य मामलों में अक्सर रजिस्ट्रार एस्केलेशन, रजिस्ट्री एस्केलेशन, प्लेटफ़ॉर्म रिकवरी, या कोर्ट के आदेश की आवश्यकता होती है। इससे बचने का सबसे तेज़ और बेहतरीन तरीका यही है कि आप कभी इस स्थिति में पहुँचें ही नहीं।

यह पोस्ट उन पाँच हमलावर तरीकों (attack paths) के बारे में बताती है जिन्हें हम सबसे ज़्यादा देखते हैं, बचाव पक्ष के नज़रिए से वे कैसे दिखते हैं, और वे कौन से विशिष्ट सुरक्षा उपाय (controls) हैं जो असल में इन्हें रोकते हैं।

1. रजिस्ट्रार की सपोर्ट टीम के ख़िलाफ़ सोशल इंजीनियरिंग

पिछले दशक के सबसे ज़्यादा हाई-प्रोफाइल हाईजैक मामलों में किसी तकनीकी कमज़ोरी का इस्तेमाल नहीं किया गया था। वे सिर्फ एक फ़ोन कॉल के ज़रिए हुए थे।

पैटर्न: हमलावर अपने लक्ष्य के बारे में पर्याप्त जानकारी इकट्ठा करता है—जैसे WHOIS हिस्ट्री, LinkedIn, लीक हुए पासवर्ड डंप, सोशल मीडिया—और फिर मालिक (owner) होने का नाटक करते हुए रजिस्ट्रार की सपोर्ट टीम को कॉल या ईमेल करता है। वे पासवर्ड रीसेट, ईमेल बदलने, या ट्रांसफर ऑथराइज़ेशन (auth) कोड की माँग करते हैं। यदि सपोर्ट एजेंट उस चेकलिस्ट का इस्तेमाल करता है जिसकी तैयारी हमलावर ने पहले से कर रखी है, तो अकाउंट का कंट्रोल बदल जाता है।

क्रिप्टोकरेंसी एक्सचेंजों, विज्ञापन प्लेटफ़ॉर्मों, और इंफ्रास्ट्रक्चर ब्रांडों से जुड़े कई सबसे विनाशकारी हाईजैक मामलों के पीछे यही तरीका था। इसके लिए रजिस्ट्रार के कोड में किसी कमज़ोरी की ज़रूरत नहीं होती; यह प्रक्रिया में शामिल इंसानी कमज़ोरी का फ़ायदा उठाता है।

इसे क्या रोकता है:

• रजिस्ट्रार के स्तर पर एक सख़्त नियम कि ओनरशिप बदलने के लिए या तो नोटराइज़्ड दस्तावेज़ की आवश्यकता होगी, या रजिस्ट्रेंट के मौजूदा चैनल के माध्यम से मल्टी-फैक्टर चैलेंज पास करना होगा।
• रजिस्ट्री लॉक (Registry lock) (रजिस्ट्रार लॉक से अलग), जहाँ रजिस्ट्री ऑपरेटर स्वयं आउट-ऑफ़-बैंड कन्फर्मेशन (out-of-band confirmation) के बिना ट्रांसफर या संपर्क विवरण बदलने से इनकार कर देता है। यह .com, .net, और कई ccTLDs पर उपलब्ध है।
• यह वेरिफ़ाई करना कि आप असल में किस रजिस्ट्रार का उपयोग करते हैं और बाकी को हटा देना। 2007 में शुरू हुए ब्रांडों के पास अक्सर तीन या चार रजिस्ट्रारों पर कमज़ोर क्रेडेंशियल्स वाले पुराने और निष्क्रिय अकाउंट होते हैं।

2. रजिस्ट्रार अकाउंट कॉम्प्रोमाइज (क्रेडेंशियल पाथ)

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

इसे क्या रोकता है:

• रजिस्ट्रार अकाउंट पर फ़िशिंग-प्रतिरोधी 2FA लगाना। ऑथेंटिकेटर ऐप के ज़रिए TOTP बुनियादी स्तर है; हार्डवेयर कीज़ (WebAuthn / FIDO2) उच्चतम स्तर हैं। SMS-आधारित 2FA पर्याप्त नहीं है—SIM-स्वैपिंग हमलों ने इसे बार-बार मात दी है। अमेरिकी सरकार के CISA दिशानिर्देश स्पष्ट रूप से SMS आधारित 2FA को छोड़ने की सलाह देते हैं।
• एक ऐसा रजिस्ट्रार जो प्रति-अकाउंट लॉक के साथ-साथ प्रति-डोमेन लॉक (per-domain locks) को भी सपोर्ट करता हो, ताकि एक अकाउंट के हैक होने से सब कुछ एक साथ अनलॉक न हो सके।
• संपर्क बदलने, नेमसर्वर में बदलाव, और ट्रांसफर रिक्वेस्ट पर ऑडिट ट्रेल और अलर्टिंग (Audit trail and alerting) व्यवस्था। हमलावर का पहला कदम इन अलर्ट्स को म्यूट करना होता है; यदि वे किसी ऐसे चैनल पर भेजे जाते हैं जो हमलावर के नियंत्रण में नहीं है, तो आपको चेतावनी का समय मिल जाता है।

3. DNS प्रोवाइडर टेकओवर (कब्ज़ा)

भले ही रजिस्ट्रार अकाउंट पूरी तरह से सुरक्षित और लॉक हो, फिर भी रजिस्ट्रार द्वारा पब्लिश किए गए नेम सर्वर्स (name servers) किसी ऐसे DNS प्रोवाइडर की ओर पॉइंट कर सकते हैं जिसका एक अलग अकाउंट हो—जैसे Cloudflare, Route 53, NS1, DNSimple, या आपका अपना BIND सर्वर। यदि हमलावर उस DNS अकाउंट में घुसपैठ कर लेता है, तो उसे रजिस्ट्रार के अकाउंट को छूने की भी ज़रूरत नहीं है। वे बस A, MX, और TXT रिकॉर्ड्स को फिर से लिख देते हैं और सारा ट्रैफ़िक उनके पास जाने लगता है।

हमलावरों के लिए अक्सर यह एक आसान रास्ता होता है, क्योंकि ब्रांड्स रजिस्ट्रार की सुरक्षा पर तो निवेश करते हैं लेकिन DNS प्रोवाइडर को "बुनियादी ढांचा (infrastructure)" मानकर वहाँ कमज़ोर सुरक्षा उपाय रखते हैं।

इसे क्या रोकता है:

• DNS प्रोवाइडर अकाउंट पर भी रजिस्ट्रार जैसी ही सख़्त 2FA व्यवस्था। इसे भी उतना ही संवेदनशील मानें। क्योंकि यह है।
• ज़ोन लेवल पर हस्ताक्षरित DNSSEC। DNSSEC किसी DNS प्रोवाइडर अकाउंट को हैक होने से नहीं रोकता: यदि कोई हमलावर प्रोवाइडर के माध्यम से रिकॉर्ड पब्लिश कर सकता है और प्रोवाइडर उन्हें ज़ोन की एक्टिव कीज़ के साथ साइन करता है, तो वैलिडेटिंग रिज़ॉल्वर उन जवाबों को असली मानेंगे। DNSSEC जो रोकता है, वह है इन-पाथ (in-path) छेड़छाड़, कैश पॉइज़निंग (cache poisoning), और ऐसे जाली जवाब जो बिना साइन किए हुए हैं या गलत तरीके से साइन किए गए हैं, बशर्ते पैरेंट डोमेन सही DS रिकॉर्ड्स पब्लिश कर रहा हो। प्रोटोकॉल विवरण के लिए RFC 4033-4035 देखें।
• अलग-अलग अकाउंट्स और क्रेडेंशियल्स के साथ मल्टी-प्रोवाइडर DNS, जिसमें multi-signer DNSSEC का उपयोग किया गया हो। यह उपलब्धता (availability) और प्रोवाइडर आइसोलेशन (provider isolation) में मदद करता है, लेकिन यह तभी काम करता है जब हर प्रोवाइडर सही ज़ोन डेटा परोसता हो और DNSKEY/DS सेट्स ठीक से कॉर्डिनेट किए गए हों। यह कोई जादुई समाधान नहीं है जहाँ रिज़ॉल्वर अपने आप सुरक्षित प्रोवाइडर को प्राथमिकता दे दें।

4. स्टेल डेलीगेशन और डैंगलिंग रिकॉर्ड्स के ज़रिए नेमसर्वर हाईजैक

यह एक अधिक सूक्ष्म (subtler) तरीका है: इसमें आपका मुख्य डोमेन तो सुरक्षित होता है, लेकिन एक सबडोमेन (CNAME या NS रिकॉर्ड के ज़रिए) किसी ऐसी थर्ड-पार्टी सर्विस को पॉइंट करता है जिस पर मूल मालिक का अब कोई नियंत्रण नहीं है। हमलावर उस थर्ड-पार्टी साइड पर रिसोर्स रजिस्टर कर लेता है और अब वह उस सबडोमेन का नियंत्रण ले लेता है।

उदाहरण:

• एक सबडोमेन जो किसी ऐसे पुराने Heroku, S3, या Azure एसेट पर CNAME किया गया है जिसे अब छोड़ दिया गया है। हमलावर उस एसेट के नाम पर फिर से दावा कर लेता है और एक वैलिड TLS सर्टिफ़िकेट प्राप्त कर लेता है।
• एक डेलीगेटेड NS रिकॉर्ड जो किसी ऐसे DNS प्रोवाइडर अकाउंट की ओर पॉइंट कर रहा है जिसे डिलीट किया जा चुका है। हमलावर उसी सटीक होस्ट पैटर्न का उपयोग करके एक नया अकाउंट बनाता है और सबडोमेन के लिए जो चाहे वह रिकॉर्ड सर्व करता है।

इन्हें व्यापक रूप से डैंगलिंग DNS (dangling DNS) नाम से जाना जाता है, और आज के ओपन वेब पर ये "असली" डोमेन हाईजैक का सबसे आम रूप हैं क्योंकि ज़्यादातर बड़े संगठनों के पास सैकड़ों या हज़ारों सबडोमेन होते हैं और वे उनमें से केवल कुछ का ही ऑडिट करते हैं।

इसे क्या रोकता है:

• आपके द्वारा स्वामित्व वाले प्रत्येक ज़ोन में हर NS, CNAME, और ALIAS रिकॉर्ड की पूरी सूची, जिसमें हर एक के लिए एक ज़िम्मेदार व्यक्ति (owner) तय हो।
• स्वचालित डैंगलिंग-DNS स्कैनर (Automated dangling-DNS scanners) जो एक तय शेड्यूल पर हर रिकॉर्ड को फिर से रिज़ॉल्व करते हैं और उन रिकॉर्ड्स को फ़्लैग करते हैं जो ऐसी थर्ड-पार्टी सेवाओं की ओर पॉइंट कर रहे हैं जो अब रिस्पॉन्स नहीं दे रही हैं। इस तरह के हमलों के बारे में GitHub's blog और Detectify Labs के पास विस्तृत आर्टिकल्स मौजूद हैं।
• जिस दिन आप किसी अंतर्निहित सेवा (underlying service) को बंद करते हैं, उसी दिन उसके रिकॉर्ड्स को भी डीकमीशन (हटाना) करना।

5. एक्सपायर हो चुके डोमेन पर फिर से कब्ज़ा (Expired-domain reclamation)

यह सबसे सरल हमला है जिससे किसी को सहानुभूति नहीं होती: रजिस्ट्रेंट (मालिक) डोमेन को रिन्यू करना भूल गया। ग्रेस पीरियड (छूट की अवधि) खत्म हो जाती है। डोमेन वापस पब्लिक पूल में आ जाता है। कोई और इसे रजिस्टर कर लेता है।

यह किसी सुरक्षा घटना के बजाय एक ऑपरेशनल चूक (operational failure) जैसा लगता है, लेकिन इसका प्रभाव बिल्कुल वैसा ही होता है—कोई और अब आपके नाम को नियंत्रित करता है, और सालों में बनाए गए भरोसे के सभी सिग्नल्स (SPF, DKIM, OAuth कॉलबैक, पासवर्ड रीसेट ईमेल, पेमेंट इंटिग्रेशन) किसी अजनबी के पास जाने लगते हैं। कई सार्वजनिक घटनाओं में हमलावरों ने एक्सपायर हो चुके डोमेन को विशेष रूप से इसलिए खरीदा क्योंकि पिछले मालिक ने उन्हें OAuth टोकन में iss क्लेम के रूप में या ट्रांसेक्शनल ईमेल के प्रेषक (sender) के रूप में रजिस्टर किया हुआ था।

इसे क्या रोकता है:

• किसी भी ऐसे डोमेन पर जो ऑथेंटिकेशन, पेमेंट्स, या प्रोडक्शन ट्रैफ़िक से जुड़ा हो, उस पर मल्टी-ईयर रिन्यूअल (5-10 साल) अपनाना। इसकी लागत मामूली होती है; लेकिन सुरक्षा बहुत बड़ी होती है।
• एक ऐसे भुगतान तरीके के साथ ऑटो-रिन्यूअल जो अचानक से फ़ेल न हो। क्रेडिट/डेबिट कार्ड का एक्सपायर होना, डोमेन के गलती से एक्सपायर होने का सबसे बड़ा और आम कारण है।
• 90, 60, 30, और 7 दिनों पर कैलेंडर रिमाइंडर्स सेट करना जो किसी एक व्यक्ति (जो कंपनी छोड़ भी सकता है) के इनबॉक्स में जाने के बजाय किसी टीम एड्रेस पर जाएँ।

एक अच्छी सुरक्षा व्यवस्था कैसी दिखती है

सभी सुरक्षा उपायों (controls) को एक साथ मिलाएँ, तो किसी भी महत्वपूर्ण डोमेन के लिए बुनियादी ढांचा कुछ ऐसा दिखता है:

यदि आप किसी डोमेन के लिए ज़िम्मेदार हैं और इस लिस्ट की हर पंक्ति पर सही का निशान नहीं लगा सकते, तो समझ लीजिए कि हमलावर का काम काफी आसान हो जाता है।

Namefi इस पूरी तस्वीर को कैसे बदलता है

ऊपर बताए गए ज़्यादातर सुरक्षा उपाय किसी एक रजिस्ट्रार, किसी एक DNS प्रोवाइडर, या किसी एक वर्कफ़्लो टूल के फ़ीचर्स के तौर पर मौजूद हैं, और आपकी सुरक्षा इस बात पर निर्भर करती है कि आपका कौन सा अकाउंट सबसे कमज़ोर है। Namefi रजिस्ट्रेंट के रिश्ते को ऑन-चेन (on-chain) टोकनाइज़ करता है, जिसका मतलब है कि इस नाम का असली मालिक कौन है, इसका प्रामाणिक रिकॉर्ड किसी एक रजिस्ट्रार के ग्राहक डेटाबेस के बाहर मौजूद रहता है। किसी भी एक प्रोवाइडर का सपोर्ट एजेंट असली मालिक की मंज़ूरी वाले हस्ताक्षरित ट्रांज़ैक्शन (signed transaction) के बिना चुपके से ओनरशिप नहीं बदल सकता। रजिस्ट्रार अब भी तकनीकी डेलीगेशन (technical delegation) को ऑपरेट करता है, लेकिन कंट्रोल (नियंत्रण) लेयर एक ऐसी जगह पर चली जाती है जहाँ सोशल इंजीनियरिंग काम नहीं करती।

यह ऊपर दी गई टेबल के सुरक्षा उपायों का पूरा विकल्प नहीं है—आपको अभी भी DNSSEC की ज़रूरत है, आपको अभी भी DNS प्रोवाइडर पर 2FA की ज़रूरत है, और आपको अभी भी डोमेन रिन्यू करने की ज़रूरत है। लेकिन यह थ्रेट मॉडल (threat model) में से सबसे आम और सबसे ज़्यादा असरदार हाईजैक वेक्टर (तरीका 1) को पूरी तरह से हटा देता है।

स्रोत और आगे पढ़ने के लिए

• ICANN — Transfer Dispute Resolution Policy scope।
• IETF — DNSSEC RFCs 4033/4034/4035 और multi-signer DNSSEC RFC 8901।
• CISA — Multi-factor authentication guidance।
• Detectify Labs — Hostile subdomain takeover write-up।
• Verisign — Registry lock for .com/.net।