Namefi

Domain Mayday EP10: सीरियाई इलेक्ट्रॉनिक आर्मी ने एक फ़िश्ड रिसेलर के ज़रिए NYTimes.com को कैसे बंद किया

27 अगस्त 2013 को, सीरियाई इलेक्ट्रॉनिक आर्मी ने Melbourne IT के एक रिसेलर को फ़िश किया, nytimes.com और Twitter के डोमेन के DNS रिकॉर्ड्स को फिर से लिखा, और न्यूयॉर्क टाइम्स को घंटों के लिए ऑफ़लाइन कर दिया। एक गहरी पड़ताल कि कैसे रजिस्ट्रार-चेन की कमज़ोर कड़ी एक अखबार की सामने की दरवाज़े की विफलता बनी — और रजिस्ट्री लॉक ने क्या बदला होता।

Fenwei BianFenwei BianलेखकVictor ZhouVictor ZhouसंपादकNirmit BuddhirajaNirmit Buddhirajaअनुवादक17 जून 2026लगभग 11 मिनट पढ़ाई
  • domains
  • security
  • dns
  • domain-security
X पर शेयर करें

एक अखबार का डोमेन नाम उसका मुख्य द्वार होता है। जब आप nytimes.com टाइप करते हैं, तो आप एक अदृश्य श्रृंखला पर भरोसा कर रहे होते हैं — एक डोमेन रजिस्ट्री, एक रजिस्ट्रार, और कभी-कभी उस रजिस्ट्रार के नीचे एक रिसेलर — जो आपको असली न्यूज़रूम तक और कहीं नहीं पहुंचाती है। किसी सामान्य दिन आप उस श्रृंखला के बारे में कभी नहीं सोचते। 27 अगस्त 2013 को, वह टूट गई, और लाखों पाठक The New York Times के मुख्य द्वार पर पहुंचे तो पाया कि उसे किसी और के द्वार से बदल दिया गया है।

वह "कोई और" था Syrian Electronic Army (SEA), एक असद-समर्थक हैकर समूह जिसने 2013 भर पश्चिमी मीडिया आउटलेट्स को निशाना बनाया। इस बार उन्होंने किसी एक लेख को नहीं बदला और न ही किसी कंटेंट मैनेजमेंट सिस्टम में सेंध लगाई। वे एक स्तर और गहरे गए — DNS रिकॉर्ड्स तक, जो तय करते हैं कि एक डोमेन कहाँ इशारा करता है — और कुछ घंटों के लिए उन्होंने ग्रह के सर्वाधिक पढ़ी जाने वाली न्यूज़ साइटों में से एक का पता अपने नियंत्रण में ले लिया।

डोमेन सामने का द्वार है, और उस द्वार पर एक ताला है जिसे आप नियंत्रित नहीं करते

जब The New York Times जैसी कोई कंपनी एक डोमेन रजिस्टर करती है, तो "यह किसका है और यह कहाँ इशारा करता है" का आधिकारिक रिकॉर्ड रजिस्ट्री पर रहता है (.com के लिए, यह Verisign है) और एक रजिस्ट्रार के ज़रिए प्रबंधित होता है। बड़े रजिस्ट्रार रिसेलर्स के ज़रिए भी बेचते हैं — छोटी फर्में जो डोमेन सेवाओं को री-सेल करती हैं और रजिस्ट्रार के सिस्टम में अपना लॉगिन रखती हैं।

यह परत-दर-परत व्यवस्था सुविधाजनक है। लेकिन यह विश्वास की एक ऐसी श्रृंखला भी है जहाँ सबसे कमज़ोर कड़ी पूरी चीज़ की सुरक्षा तय करती है। अगर कोई हमलावर उस श्रृंखला में किसी भी के रूप में प्रमाणीकरण कर सके — रजिस्ट्रेंट, रजिस्ट्रार स्टाफ, या रिसेलर — तो रजिस्ट्रार का सिस्टम डिज़ाइन के अनुसार उन्हें वैध मालिक मान लेगा। Melbourne IT के अपने मुख्य कार्यकारी अधिकारी ने इस विफलता के तरीके को एक विनाशकारी वाक्य में कह दिया: "वे सामने के दरवाज़े से आए," उन्होंने AP को बताया। यदि आपके पास एक वैध उपयोगकर्ता नाम और पासवर्ड है, तो सिस्टम मान लेता है कि आप अधिकृत मालिक हैं। यही पूरी समस्या का सार है।

27 अगस्त 2013: वह दिन जब nytimes.com कहीं और इशारा करने लगा

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

एक मंगलवार की देर दोपहर को, पाठक Times तक पहुंचना बंद हो गए। New York Times की वेबसाइट "कुछ उपयोगकर्ताओं के लिए अंधेरे में चली गई थी," ABC News ने रिपोर्ट किया, और अखबार ने पुष्टि की कि उसकी साइट "मंगलवार की दोपहर पाठकों के लिए अनुपलब्ध थी" अपने डोमेन रजिस्ट्रार पर हमले के बाद। यह कोई संक्षिप्त व्यवधान नहीं था। आगंतुकों को "मंगलवार को कई घंटों तक खाली ब्राउज़र स्क्रीन से रूबरू होना पड़ा," Christian Science Monitor ने रिपोर्ट किया — और इसे और बुरा बनाने के लिए, यह "इस महीने दूसरी बार" था जब साइट डाउन हो गई थी।

जो वास्तव में हुआ था वह रजिस्ट्रार स्तर पर एक DNS हाइजैक था। हमलावरों ने उन रिकॉर्ड्स में प्रवेश किया जो nytimes.com को एक IP पते में अनुवाद करते हैं और उन्हें फिर से लिख दिया। घटना के Wikipedia के विवरण के अनुसार, NYTimes.com "के DNS को एक पेज पर रीडायरेक्ट किया गया था जिसमें संदेश 'Hacked by SEA' प्रदर्शित था।" सामने का द्वार एक अलग दरवाज़े पर फिर से लगा दिया गया था।

Times उस अकाउंट पर एकमात्र लक्ष्य नहीं था। TechCrunch, रियल टाइम में रिपोर्ट करते हुए, पाया कि "New York Times और Twitter दोनों के नेम सर्वर ऐसे प्रतीत होते हैं जो रजिस्ट्रार Melbourne IT के ज़रिए रजिस्टर किए गए थे," और कि twimg.com डोमेन, "जो Twitter की छवियाँ और अवतार प्रदान करता है, उसमें भी बदलाव दिखाई देते हैं जो ऐसे सर्वर की ओर इशारा करते हैं जो स्पष्ट रूप से SEA के स्वामित्व में हैं।" Twitter की मुख्य साइट काफी हद तक सुरक्षित रही, लेकिन उसका इमेज-और-अवतार डोमेन डगमगा गया — इतना काफी था कि कुछ उपयोगकर्ताओं ने संक्षिप्त रूप से टूटी हुई छवियाँ देखीं।

प्रभाव: अंधकार के घंटे, और एक रीडायरेक्ट जिस पर भरोसा नहीं किया जा सकता था

एक समाचार संगठन के लिए, हाइजैक की कीमत केवल खोए हुए पेजव्यू में नहीं मापी जाती। यह विश्वास में मापी जाती है। आउटेज की अवधि के दौरान, nytimes.com तक पहुंचने वाले किसी भी व्यक्ति को हमलावर द्वारा रूट किया जा रहा था। Times के अपने मुख्य सूचना अधिकारी, Mark Frons, ने स्टाफ को बताया कि व्यवधान "Syrian Electronic Army या उनके बनने की कोशिश करने वाले किसी के द्वारा किए गए दुर्भावनापूर्ण बाहरी हमले का परिणाम था" — और कर्मचारियों को ईमेल के साथ सतर्क रहने की चेतावनी दी जबकि डोमेन अखबार के हाथ से बाहर था।

सोचें कि एक हाइजैक किया हुआ DNS रिकॉर्ड वास्तव में क्या सक्षम करता है। हमलावर नियंत्रित करता है कि नाम कहाँ resolve होता है, जिसका अर्थ है कि वे एक defacement पेज serve कर सकते हैं (जैसा उन्होंने किया), लेकिन वे उतनी ही आसानी से एक विश्वसनीय नकली लॉगिन serve कर सकते थे, क्रेडेंशियल्स एकत्र कर सकते थे, या ट्रैफिक को इंटरसेप्ट कर सकते थे। Defacement शोरगुल वाला और स्पष्ट होता है। एक शांत DNS हाइजैक कहीं अधिक खतरनाक होता है — और दोनों को वही कमज़ोरी सक्षम करती है। Huffington Post UK का डोमेन उसी घटना में फंस गया था, जो इस बात को रेखांकित करता है कि यह एक रजिस्ट्रार-अकाउंट समझौता था, न कि किसी एकल न्यूज़रूम के विरुद्ध एकबारगी मज़ाक।

यह कैसे हुआ: अखबार को नहीं, रिसेलर को फ़िश करो

एक फ़िश किए गए सोने के चाबी के अमूर्त रूटिंग डायल से चिह्नित एक चमकते कंट्रोल-रूम के दरवाज़े में खिसकने की ज्वलंत रंगीन कॉन्सेप्ट आर्ट, एक छायादार हाथ पते के तीरों की एक प्रकाशमान बही को फिर से लिख रहा है जबकि एक नकली ईमेल लिफाफा ताले में घुल जाता है

यह वह हिस्सा है जिस पर विचार करना आवश्यक है: SEA को कभी The New York Times में सेंध लगाने की ज़रूरत नहीं पड़ी। उन्होंने अखबार के सर्वर या उसके CMS को कभी नहीं छुआ। उन्होंने रजिस्ट्रार के नीचे की श्रृंखला पर हमला किया।

प्रवेश बिंदु Melbourne IT के एक US-आधारित रिसेलर को भेजा गया स्पीयर-फ़िशिंग ईमेल था। जैसा The Next Web ने रिपोर्ट किया, Melbourne IT ने "पुष्टि की कि SEA ने लॉग-इन विवरण प्राप्त करने के लिए फ़िशिंग रणनीति का उपयोग किया" — रिसेलर के स्टाफ को उनके ईमेल क्रेडेंशियल्स सौंपने के लिए बरगलाया गया, और हमलावरों ने फिर उन मेलबॉक्स से रजिस्ट्रार लॉगिन खोद निकाले। वहाँ से यह सरल था: Melbourne IT के एक रिसेलर के क्रेडेंशियल्स (उपयोगकर्ता नाम और पासवर्ड) का उपयोग Melbourne IT के सिस्टम पर एक रिसेलर अकाउंट तक पहुंचने के लिए किया गया, और अंदर जाकर, हमलावरों ने "कई डोमेन नामों के DNS रिकॉर्ड्स बदल दिए ... जिनमें Times के भी शामिल थे।"

TechCrunch का विवरण उतना ही स्पष्ट है: "उस रिसेलर अकाउंट पर कई डोमेन नामों के DNS रिकॉर्ड्स बदल दिए गए — जिनमें nytimes.com भी शामिल था।"

यही असमानता रजिस्ट्रार-चेन हमलों को इतना आकर्षक बनाती है। Times अपने स्वयं के बुनियादी ढांचे को चाँद तक कठोर कर सकता था और यह मायने नहीं रखता, क्योंकि कमज़ोर अकाउंट एक तृतीय-पक्ष रिसेलर का था जो न्यूज़रूम से कई कदम दूर था। एक छोटी कंपनी के कुछ कर्मचारियों पर एक स्पीयर-फ़िश लाखों पाठकों द्वारा पढ़े जाने वाले अखबार को रीडायरेक्ट करने के लिए पर्याप्त था।

प्रतिक्रिया और उपरांत

एक बार जब Melbourne IT समझ गया कि क्या हुआ था, तो सुधार सीधा था — और यह दिखाता है कि अगर आप रजिस्ट्रार को नियंत्रित करते हैं तो ये हमले कितने उलटने योग्य हैं। कंपनी ने सही सेटिंग्स बहाल कीं: इसने बदले हुए DNS रिकॉर्ड्स को वापस लिया और उन्हें आगे के परिवर्तन के विरुद्ध "लॉक" कर दिया। इसने समझौता किए गए रिसेलर अकाउंट पर पासवर्ड बदला और घुसपैठ का पता लगाने के लिए लॉग खींचे। Times ने बुधवार की सुबह तक सेवा बहाल कर ली।

लेकिन पूरे प्रकरण में सबसे शिक्षाप्रद विवरण यह है कि क्षति वहीं क्यों रुक गई जहाँ रुकी। उसी रिसेलर अकाउंट के कुछ डोमेन कभी प्रभावित ही नहीं हुए — क्योंकि उनके मालिकों ने एक मज़बूत सुरक्षा चालू की थी। Melbourne IT के अपने शब्दों में, "महत्वपूर्ण नामों के लिए हम सुझाते हैं कि डोमेन नाम के मालिक .com सहित डोमेन नाम रजिस्ट्रियों से उपलब्ध अतिरिक्त रजिस्ट्री लॉक सुविधाओं का लाभ उठाएं — रिसेलर अकाउंट पर लक्षित कुछ डोमेन नामों में ये लॉक सुविधाएं सक्रिय थीं और इसलिए वे प्रभावित नहीं हुए।"

एक रजिस्ट्री लॉक डोमेन को एक ऐसी स्थिति में रखता है (आप इसे WHOIS में serverUpdateProhibited जैसे फ्लैग के रूप में देख सकते हैं) जहाँ रजिस्ट्री तब तक बदलाव करने से इनकार करेगी जब तक एक सख्त, आउट-ऑफ-बैंड प्रक्रिया का पालन न किया जाए। जैसा कि उस समय डोमेन-इंडस्ट्री के जानकारों ने नोट किया, Twitter के रिकॉर्ड में ठीक उसी तरह का Verisign-lock status था। एक फ़िश किया गया रिसेलर पासवर्ड रजिस्ट्री लॉक को हराने के लिए पर्याप्त नहीं है — और यह एकल कॉन्फ़िगरेशन विकल्प "घंटों के लिए डाउन" और "कभी प्रभावित नहीं" के बीच की रेखा है।

यह रजिस्ट्रार और रिसेलर चेन, और रजिस्ट्री लॉक के बारे में क्या सिखाता है

27 अगस्त का हाइजैक एक लगभग-परिपूर्ण शिक्षण मामला है क्योंकि विफलता श्रृंखला की हर कड़ी दिखाई देती है।

  1. आपका डोमेन उतना ही सुरक्षित है जितना उसे बदल सकने वाला सबसे कमज़ोर अकाउंट। इसमें आपके रजिस्ट्रार का स्टाफ और उनके नीचे कोई भी रिसेलर शामिल है — जिनमें से किसी को भी आप सीधे नियंत्रित नहीं करते। Times ने अपने सर्वर पर कुछ गलत नहीं किया; समझौता कई कदम दूर था।
  2. फ़िशिंग फ़ायरवॉल को मात देती है। कोई विदेशी exploit का उपयोग नहीं किया गया था। एक नकली ईमेल ने कुछ रिसेलर कर्मचारियों को वे क्रेडेंशियल्स दे दिए जिन्हें रजिस्ट्रार के सिस्टम ने पूरी तरह से अधिकृत माना। "वे सामने के दरवाज़े से आए।"
  3. रजिस्ट्री लॉक वह नियंत्रण है जो वास्तव में मायने रखता था। अतिरिक्त रजिस्ट्री लॉक सुविधाओं वाले डोमेन "इस प्रकार प्रभावित नहीं हुए।" किसी भी मिशन-क्रिटिकल डोमेन के लिए, रजिस्ट्री लॉक (साथ ही रजिस्ट्रार-लॉक और रजिस्ट्रार अकाउंट पर 2FA) वैकल्पिक कठोरीकरण नहीं है — यह आधार रेखा है।
  4. DNS परिवर्तन शक्तिशाली और तेज़ हैं। नेम-सर्वर या A रिकॉर्ड का एकल पुनर्लेखन तुरंत एक पूरे ब्रांड को रीडायरेक्ट कर देता है। एक समझौता किए गए अकाउंट का विस्फोट क्षेत्र वे सभी डोमेन हैं जिन्हें वह छू सकता है।
  5. अपने स्वयं के रिकॉर्ड्स की निगरानी करें। WHOIS और DNS निगरानी मिनटों में अनधिकृत परिवर्तन को फ़्लैग कर देती। जितनी जल्दी आप एक अप्रत्याशित नेम-सर्वर परिवर्तन नोटिस करते हैं, आउटेज उतना ही छोटा होता है।

Namefi का दृष्टिकोण

सत्यापन योग्य, छेड़छाड़-प्रतिरोधी डोमेन स्वामित्व का रंगीन चित्रण — एक हरे ढाल, एक हरे Namefi टोकन, और DNS निरंतरता द्वारा सुरक्षित एक डोमेन कार्ड

SEA हाइजैक, अपने मूल में, एक प्राधिकरण समस्या थी। रजिस्ट्रार का सिस्टम असली मालिक और एक फ़िश किए गए पासवर्ड को रखने वाले किसी व्यक्ति के बीच का अंतर नहीं बता सका, इसलिए उसने वही किया जो वह करने के लिए बना था और परिवर्तन स्वीकार कर लिया। हर वह बचाव जो काम किया — रजिस्ट्री लॉक, आउट-ऑफ-बैंड पुष्टि, सावधानीपूर्वक निगरानी — वास्तव में यह साबित करने की बाधा बढ़ाने का तरीका है कि परिवर्तन अनुरोध वास्तव में मालिक से आया है।

Namefi उसी सटीक आधार से शुरू करता है: डोमेन स्वामित्व और नियंत्रण सत्यापन योग्य और छेड़छाड़-प्रतिरोधी होना चाहिए, न कि एक रिसेलर के इनबॉक्स में तैरता हुआ एकल पुन: उपयोग योग्य पासवर्ड। डोमेन स्वामित्व को एक ऑन-चेन, क्रिप्टोग्राफ़िक रूप से सत्यापन योग्य एसेट के रूप में प्रदर्शित करके जो DNS के साथ संगत रहता है, Namefi "इस डोमेन को बदलने की अनुमति किसे है" के सवाल को एक मज़बूत, ऑडिट योग्य उत्तर देता है, न कि जो भी लॉग इन किया उस पर निहित विश्वास। नियंत्रण परिवर्तन स्पष्ट, हस्ताक्षरित क्रियाएं बन जाते हैं जो मालिक से बंधी होती हैं — एक रजिस्ट्री लॉक के करीब जिसकी चाबी आपके पास हो, न कि एक ऐसे सामने के दरवाज़े के जिसे सही पासवर्ड वाला कोई भी खोल सकता है।

एक अखबार का डोमेन उसका सामने का दरवाज़ा है। 27 अगस्त 2013 का सबक यह है कि सबसे मज़बूत संभव डेडबोल्ट किसी काम का नहीं है यदि कई इमारतें दूर कोई अजनबी चाबी की एक प्रति देने के लिए बरगलाया जा सकता हो। समाधान यह है कि स्वामित्व को स्वयं साबित करने योग्य बनाया जाए — ताकि "सामने के दरवाज़े से आए" ऐसी बात हो जो कोई अजनबी कभी न कह सके।

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

योगदानकर्ता

Fenwei Bian
Fenwei Bianलेखक
सॉफ़्टवेयर डेवलपर और लेखिका • Namefi

Fenwei Bian तीसवें दशक की सॉफ़्टवेयर डेवलपर हैं, जो अपने काम के घंटे पुल रिक्वेस्ट्स में और सप्ताहांत मिट्टी या लकड़ी के बुरादे में हाथ डालकर बिताती हैं। GitHub पर वर्षों तक ओपन सोर्स में काम करने से उन्होंने सीखा कि नाम इंटरफ़ेस होते हैं: अच्छा नाम स्पष्ट होता है, वह जो करता है उसे ईमानदारी से बताता है और अगले उपयोगकर्ता का खयाल रखता है।

वे बागवानी करती हैं क्योंकि वह धैर्य का फल देती है और खुशफ़हमी को सज़ा देती है। वे लकड़ी का काम करती हैं क्योंकि कोई जोड़ या तो ठीक बैठता है या नहीं। दोनों आदतें नामकरण पर उनके लेखन में दिखती हैं — दो बार नापो, स्रोत जाँचो और किसी खुरदुरी जगह को ऊपर-ऊपर घिसकर यह उम्मीद मत करो कि किसी की नज़र नहीं पड़ेगी।

Namefi के लिए वे लिखती हैं कि डोमेन बाज़ार वास्तव में कैसे चलते हैं, नामों को टोकनाइज़ और फ़्लिप करने में कौन-से व्यावहारिक ट्रेडऑफ़ होते हैं, और ऐसा डोमेन कैसे चुनें जिसे बीस साल बाद भी अपने पास रखकर खुशी हो।

Victor Zhou
Victor Zhouसंपादक
संस्थापक और मानक संपादक • Namefi

Victor Zhou डिजिटल पहचान और भरोसे पर केंद्रित टेक्नोलॉजी उद्यमी और मानक संपादक हैं। उन्होंने Namefi की स्थापना की, Ethereum Improvement Proposals का संपादन करते हैं और इससे पहले Google Labs में स्मार्ट-कॉन्ट्रैक्ट आर्किटेक्चर के काम का नेतृत्व कर चुके हैं।

उनका काम नामकरण, स्वामित्व और उन प्रणालियों के संगम पर है जिनका उपयोग लोग ऑनलाइन अपनी पहचान स्थापित करने के लिए करते हैं। यही नज़रिया उन्हें इस बात में खास दिलचस्पी देता है कि नाम निजी अर्थ, सार्वजनिक मान्यता और डिजिटल इन्फ़्रास्ट्रक्चर के बीच कैसे आते-जाते हैं।

Namefi के लिए Victor टिकाऊ डिजिटल पहचान के रूप में डोमेन पर संपादन और लेखन करते हैं: नाम कैसे मालिकाना हक़ वाले ऑनचेन एसेट बनते हैं, टोकनाइज़ेशन कस्टडी और भरोसे को कैसे बदलता है, और नामकरण उन प्रणालियों से क्या सीख सकता है जिनका उपयोग लोग ऑनलाइन अपनी पहचान स्थापित करने के लिए करते हैं।

Nirmit Buddhiraja
Nirmit Buddhirajaअनुवादक
हिंदी लोकलाइज़ेशन अनुवादक • Namefi

Nirmit Buddhiraja (निर्मित बुद्धिराजा) बीसवें दशक के उत्तरार्ध के अनुवादक हैं, जो जयपुर में पले-बढ़े और अब बेंगलुरु से काम करते हैं। मैकेनिकल इंजीनियरिंग में स्नातक होने के बाद वे IT सपोर्ट में गए और फिर अंग्रेज़ी व हिंदी के बीच तकनीकी और संपादकीय सामग्री को लोकलाइज़ करने लगे।

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

Namefi के लिए वे डोमेन और नामकरण से जुड़े लेखों को हिंदी में लोकलाइज़ करते हैं — देवनागरी IDN, .in और .bharat नेमस्पेस, और लिप्यंतरण के उन फैसलों का ध्यान रखते हुए जो तय करते हैं कि कोई ब्रांड नाम एक साथ दो लिपियों में सही दिखेगा या नहीं।

संबंधित गाइड

इस लेख पर चर्चा करें

Namefi Discuss पर चर्चा देखें