Domain Mayday EP14: जब एक सुरक्षा फर्म का DNS हाईजैक हुआ — Fox-IT घटना

मैन-इन-द-मिडल हमले की खासियत यह है कि जब वह हो रहा होता है, तब सब कुछ सामान्य दिखता है।

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

अब कल्पना करें कि ऐसा उन लोगों के साथ हो रहा है जिनका काम ठीक यही पता लगाना है।

सितंबर 2017 में, Dutch साइबरसुरक्षा फर्म Fox-IT — एक कंपनी जो उल्लंघनों की जांच करती है, इंटरसेप्शन-डिटेक्शन सेंसर बनाती है, और सरकारों को यह सलाह देती है कि हमलावर कैसे चलते हैं — ने पाया कि एक हमलावर ने उसके अपने डोमेन का DNS हाईजैक कर लिया था, उसके नाम पर TLS सर्टिफिकेट प्राप्त कर लिया था, और दिन के बड़े हिस्से तक उसके क्लाइंट पोर्टल पर आने-जाने वाले ट्रैफिक को पढ़ता रहा। ताले बनाने वाले का अपना ताला ही तोड़ा गया। और फिर Fox-IT ने वह काम किया जो शायद ही कोई उल्लंघन-पीड़ित कंपनी करती है: उसने इसका विस्तृत विवरण प्रकाशित किया कि यह कैसे हुआ।

एक सुरक्षा फर्म भी अपने रजिस्ट्रार पर निर्भर करती है

यह वह असुविधाजनक सच है जो यह मामला ठोस रूप से सामने रखता है: चाहे आपकी आंतरिक सुरक्षा कितनी भी अच्छी हो, आपके अटैक सरफेस का एक बड़ा हिस्सा एक ऐसी कंपनी में रहता है जिसे आप नहीं चलाते।

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

Fox-IT किसी भी मानक से एक गंभीर सुरक्षा संगठन था। वह फुल पैकेट कैप्चर और अपने खुद के नेटवर्क सेंसर चलाता था। उसने अपने क्लाइंट-फेसिंग पोर्टल पर टू-फैक्टर ऑथेंटिकेशन का उपयोग किया। बाद में इसे NCC Group में अधिग्रहित किया गया। और फिर भी यह उस एक खाते के माध्यम से उजागर था जिसमें वह लगभग कभी लॉग इन नहीं करता था — क्योंकि, जैसा कि कंपनी ने खुद कहा, DNS सेटिंग्स आमतौर पर बहुत कम बदलती हैं, इसलिए उन्हें सुरक्षित करने वाली क्रेडेंशियल्स चुपचाप पुरानी हो गईं।

जैसा कि Fox-IT ने अपनी रिपोर्ट की शुरुआत में कहा: यदि ऐसा हमला एक सुरक्षा फर्म पर हो सकता है, तो संभवतः यह कई अन्य प्रकार के व्यवसायों पर भी हो सकता है जो सुरक्षा पर कम ध्यान देते हैं।

19 सितंबर 2017: हाईजैक और MITM

Fox-IT का विवरण एक ऐसी पंक्ति से शुरू होता है जो तब से इंसिडेंट-रिस्पांस लेखन में एक छोटी क्लासिक बन गई है: Fox-IT के लिए "अगर" "जब" बन गया मंगलवार, 19 सितंबर 2017 को, जब कंपनी एक मैन-इन-द-मिडल हमले का शिकार हुई।

जो हुआ वह कोई सर्वर एक्सप्लॉइट नहीं था। 19 सितंबर की सुबह-सुबह, एक हमलावर ने हमारे थर्ड-पार्टी डोमेन रजिस्ट्रार पर Fox-IT.com डोमेन के DNS रिकॉर्ड तक पहुंच बनाई। उन रिकॉर्ड पर नियंत्रण पाकर, हमलावर ने एक विशेष सर्वर के DNS रिकॉर्ड को अपने कब्जे के सर्वर की ओर इंगित करने और ट्रैफिक को इंटरसेप्ट तथा फॉरवर्ड करने के लिए संशोधित किया वास्तविक Fox-IT इंफ्रास्ट्रक्चर पर वापस।

वह अंतिम विवरण — ट्रैफिक को फॉरवर्ड करना — ने इसे एक साधारण आउटेज की बजाय मैन-इन-द-मिडल बनाया। विज़िटर अभी भी एक काम करने वाले पोर्टल तक पहुंचे। वे बस पहले हमलावर के माध्यम से पहुंचे।

लक्ष्य विशिष्ट था। यह हमला विशेष रूप से ClientPortal, Fox-IT के डॉक्यूमेंट एक्सचेंज वेब एप्लिकेशन पर लक्षित था, वह सिस्टम जिसे Fox-IT ग्राहकों, आपूर्तिकर्ताओं और अन्य संगठनों के साथ फाइलें सुरक्षित रूप से एक्सचेंज करने के लिए उपयोग करता था। दूसरे शब्दों में, हमलावर सीधे उस चैनल पर गया जहां से संवेदनशील क्लाइंट दस्तावेज प्रवाहित होते थे।

क्योंकि Fox-IT ने इसे पकड़ा और नियंत्रित किया, कंपनी ने कुल प्रभावी MitM समय को 10 घंटे और 24 मिनट तक सीमित किया। स्वतंत्र कवरेज ने भी वही संख्या दी: यह घटना 19 सितंबर को हुई और 10 घंटे और 24 मिनट तक चली।

वास्तव में क्या इंटरसेप्ट हुआ

एक डॉक्यूमेंट-एक्सचेंज पोर्टल पर दस घंटे का मैन-इन-द-मिडल विनाशकारी लगता है। वास्तविक नुकसान छोटा था — और वह छोटापन ही असली कहानी है।

उस अवधि के दौरान, नौ व्यक्तिगत उपयोगकर्ताओं ने लॉग इन किया और उनकी क्रेडेंशियल्स इंटरसेप्ट की गईं। लेकिन वे क्रेडेंशियल्स काफी हद तक बेकार थीं: Fox-IT के पोर्टल के लिए एक दूसरे ऑथेंटिकेशन फैक्टर की आवश्यकता थी जिसे हमलावर, नेटवर्क पाथ में बैठा होने के बावजूद, रीप्ले नहीं कर सकता था। Help Net Security ने उल्लेख किया कि नौ उपयोगकर्ताओं की लॉगिन क्रेडेंशियल्स कैप्चर की गईं लेकिन दूसरे ऑथेंटिकेशन फैक्टर के बिना बेकार थीं।

फाइलों के संदर्भ में, बारह फाइलें (जिनमें से दस अद्वितीय थीं) ट्रांसफर और इंटरसेप्ट की गईं। कुछ में गोपनीय क्लाइंट जानकारी थी। हमलावर ने ClientPortal उपयोगकर्ताओं के कुछ नाम और ईमेल पते, कुछ खाता नाम, और एक मोबाइल फोन नंबर भी कैप्चर किए, जैसा कि SecurityWeek ने सारांशित किया।

दो तथ्यों ने नुकसान को सीमित रखा। पहला, Fox-IT ने स्पष्ट रूप से कहा कि राज्य रहस्य के रूप में वर्गीकृत फाइलें कभी भी हमारे ClientPortal के माध्यम से स्थानांतरित नहीं की जाती हैं — सबसे संवेदनशील सामग्री बस उजागर चैनल में कभी थी ही नहीं। दूसरा, फर्म के अपने दूसरे फैक्टर ने क्रेडेंशियल चोरी को कम प्रभावी बना दिया। आर्किटेक्चर ने ब्लास्ट रेडियस को सीमित किया, भले ही परिधि — DNS — विफल हो गई हो।

यह कैसे हुआ: एक पुराना पासवर्ड, कोई दूसरा फैक्टर नहीं

तंत्र एक ऐसी चेकलिस्ट की तरह पढ़ा जाता है जो बताती है कि कैसे पीड़ित के सर्वर पर मैलवेयर की एक भी लाइन के बिना एक डोमेन ले लिया जाता है।

पहला चरण — रजिस्ट्रार खाते में पहुंचें। हमलावर ने हमारे थर्ड-पार्टी डोमेन रजिस्ट्रार प्रदाता के DNS कंट्रोल पैनल में वैध क्रेडेंशियल्स का उपयोग करके सफलतापूर्वक लॉग इन किया। Fox-IT की जांच ने निष्कर्ष निकाला कि हमलावर ने संभवतः एक थर्ड-पार्टी प्रदाता के समझौते के माध्यम से अपने डोमेन रजिस्ट्रार के DNS कंट्रोल पैनल की क्रेडेंशियल्स तक पहुंच प्राप्त की। दो संयुक्त कमजोरियों ने उस लॉगिन को सफल बनाया: पासवर्ड 2013 से नहीं बदला गया था, और रजिस्ट्रार बिल्कुल भी दूसरा फैक्टर प्रदान नहीं करता था — लेखन के समय, Fox-IT ने नोट किया, रजिस्ट्रार अभी भी 2FA का समर्थन नहीं करता।

दूसरा चरण — DNS बदलें और CA को "स्वामित्व" साबित करें। पैनल खुला होने पर, हमलावर ने DNS को पुनर्निर्देशित किया। लेकिन HTTPS साइट पर एक विश्वसनीय मैन-इन-द-मिडल चलाने के लिए, उन्हें fox-it.com के लिए एक वैध सर्टिफिकेट की जरूरत थी — और आधुनिक तरीका यह साबित करना है कि आप डोमेन को नियंत्रित करते हैं। तो हमलावर ने ठीक वही किया। 02:05–02:15 के आसपास एक संकीर्ण विंडो में, उन्होंने हमारे ClientPortal के लिए धोखाधड़ी से SSL सर्टिफिकेट पंजीकृत करने की प्रक्रिया में हमारे डोमेन का स्वामित्व साबित करने के विशिष्ट उद्देश्य के लिए Fox-IT ईमेल को अस्थायी रूप से पुनर्निर्देशित और इंटरसेप्ट किया। यह वह हिस्सा है जो हर पाठक को रुकने पर मजबूर करना चाहिए: DNS का नियंत्रण, व्यवहार में, डोमेन वैलिडेशन का नियंत्रण है। एक डोमेन-वैलिडेटेड सर्टिफिकेट उसे दिया जाता है जो CA की चुनौती का उत्तर दे सके — और यहां, DNS को नियंत्रित करने से हमलावर को वैलिडेशन ईमेल को पुनर्निर्देशित करने और उसका उत्तर देने का मौका मिला। DNS तय करता है कि वह स्वामित्व-प्रमाण कहां जाता है।

तीसरा चरण — बीच में बैठें। वैध रूप से जारी किए गए (लेकिन धोखाधड़ी से प्राप्त) सर्टिफिकेट से लैस, हमलावर ने डोमेन को विदेश में एक VPS पर इंगित किया और ट्रैफिक इंटरसेप्ट किया। जैसा कि SecurityWeek ने वर्णन किया, दुष्ट SSL सर्टिफिकेट का उपयोग ClientPortal पर MitM हमले के लिए किया गया, जहां पोर्टल पर ट्रैफिक को एक virtual private server (VPS) प्रदाता के माध्यम से विदेश में रूट किया गया। एक विज़िटर के लिए, कुछ भी गलत नहीं था। पैडलॉक असली था। सर्टिफिकेट वैलिडेट हुआ। बीच में बैठा आदमी एक ऐसी चाबी पकड़े था जिस पर ब्राउज़र को भरोसा था।

तीन परतें — DNS, सर्टिफिकेट अथॉरिटी, और TLS — सभी तकनीकी रूप से सही ढंग से काम कर रही थीं। हमलावर ने इनमें से किसी को नहीं तोड़ा। उसने तीनों को यह विश्वास दिलाया कि वह Fox-IT था, और एकमात्र चीज जिसने उसे यह करने दिया वह था एक रजिस्ट्रार पर एक पुराना, सिंगल-फैक्टर लॉगिन।

Fox-IT की प्रतिक्रिया: पता लगाएं, नियंत्रित करें, फिर सबको बताएं

जो इस घटना को सैकड़ों शांत घटनाओं से अलग करता है वह है प्रतिक्रिया — तकनीकी और संपादकीय दोनों।

पहचान तेज हुई। Fox-IT ने निर्धारित किया कि fox-it.com डोमेन के उसके नाम सर्वर पुनर्निर्देशित कर दिए गए थे, हमले के लगभग पांच घंटे बाद घुसपैठ को पकड़ा — Help Net Security के अनुसार हमले शुरू होने के लगभग पांच घंटे बाद। कंपनी जो फुल पैकेट कैप्चर और नेटवर्क सेंसर खुद पर चलाती थी, उसने उसे यह पुनर्निर्मित करने का फोरेंसिक रिकॉर्ड दिया कि क्या छुआ गया था और क्या नहीं।

नियंत्रण जानबूझकर था। पोर्टल को ऑफलाइन खींचने और हमलावर को सचेत करने की बजाय, Fox-IT ने एक शांत शमन चुना: उसने हमारे ClientPortal लॉगिन ऑथेंटिकेशन सिस्टम के लिए दूसरे फैक्टर ऑथेंटिकेशन को अक्षम किया — एक उल्टा कदम, लेकिन एक जिसने इसे स्थिति को प्रबंधित करने दिया जबकि DNS पर नियंत्रण वापस पाया, बिना यह बताए कि उसने घुसपैठ को देख लिया था। फिर उसने इन फाइलों के संदर्भ में प्रभावित क्लाइंट से तुरंत संपर्क किया।

फिर वह हिस्सा आया जिसने इसे एक केस स्टडी बनाया। तीन महीने बाद, विश्लेषण के बाद और एक कानून प्रवर्तन जांच चल रही होने पर, Fox-IT ने एक सरल थीसिस के तहत एक पूर्ण, टाइमस्टैम्प्ड पोस्ट-मॉर्टेम प्रकाशित किया: पारदर्शिता गोपनीयता से अधिक विश्वास बनाती है और सीखने के लिए सबक हैं। एक सुरक्षा कंपनी सबसे ऑन-ब्रांड तरीके से शर्मिंदा हुई थी — और इसे दफनाने की बजाय, उसने उद्योग को एक विस्तृत विश्लेषण सौंप दिया। BleepingComputer की हेडलाइन ने उस क्षण के लिए सही स्वर कैप्चर किया: शीर्ष सुरक्षा फर्म ने MitM सुरक्षा घटना स्वीकार की।

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

विशेषताओं को अलग करें और Fox-IT घटना एक सबक है कि असली परिधि कहां है। अधिकांश संगठनों के लिए, परिधि केवल फायरवॉल नहीं है। यह रजिस्ट्रार लॉगिन है। यहां बताया गया है कि यह मामला किसके लिए तर्क देता है:

1. रजिस्ट्रार खाते को उत्पादन बुनियादी ढांचे की तरह मानें। यह शायद ही कभी बदलता है, इसलिए इसे भूलना आसान है — और यही कारण है कि यह सड़ जाता है। 2013 से अछूता पासवर्ड "कम ट्रैफिक के कारण कम जोखिम" नहीं है; यह बिना किसी निगरानी के एक उच्च-मूल्य क्रेडेंशियल है।

2. रजिस्ट्रार पर मल्टी-फैक्टर ऑथेंटिकेशन की मांग करें — और अगर यह प्रदान नहीं किया जाता है तो चले जाएं। Fox-IT का रजिस्ट्रार 2FA का समर्थन नहीं करता था। आपके डोमेन की सुरक्षा श्रृंखला में सबसे महत्वपूर्ण खाता अकेले पासवर्ड से सुरक्षित था। रजिस्ट्रार पर 2FA की उपस्थिति या अनुपस्थिति एक खरीद मानदंड है, न कि एक अच्छी-से-होने वाली बात।

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

4. जहां हो सके DNSSEC तैनात करें। DNSSEC क्रिप्टोग्राफिक रूप से DNS प्रतिक्रियाओं पर हस्ताक्षर करता है ताकि रिज़ॉल्वर रिज़ॉल्यूशन पाथ में छेड़छाड़ का पता लगा सकें। यहां यह कोई सिल्वर बुलेट नहीं है — एक हमलावर जो आधिकारिक रिकॉर्ड को नियंत्रित करता है, उन्हें फिर से साइन कर सकता है — लेकिन यह लागत बढ़ाता है और ट्रांजिट में DNS हेरफेर की पूरी श्रेणियों को बंद करता है। DNS परत पर गहन सुरक्षा इसलिए महत्वपूर्ण है क्योंकि, जैसा कि इस मामले ने दिखाया, DNS ट्रस्ट स्टैक में TLS और सर्टिफिकेट जारी करने से ऊपर बैठता है।

5. याद रखें कि DNS नियंत्रण सर्टिफिकेट नियंत्रण के बराबर है। हमलावर को पुनर्निर्देशित ईमेल के माध्यम से डोमेन स्वामित्व साबित करके एक वैध TLS सर्टिफिकेट मिला। अपने डोमेन के विरुद्ध जारी अप्रत्याशित सर्टिफिकेट के लिए Certificate Transparency लॉग मॉनिटर करें। CT में दिखने वाला एक दुष्ट सर्टिफिकेट उन कुछ बाहरी संकेतों में से एक है जो यह संकेत दे सकते हैं कि DNS हाईजैक हो सकता है।

6. एप्लिकेशन पर ही एक दूसरा फैक्टर रखें। Fox-IT के पोर्टल 2FA का कारण यह है कि नौ चोरे गए पासवर्ड दूसरे ऑथेंटिकेशन फैक्टर के बिना बेकार थे। जब बाहरी परत (DNS) विफल हुई, तो आंतरिक परत (ऐप-स्तर MFA) ने अभी भी नुकसान को सीमित किया।

सुत्र: आपका डोमेन एक ऐसा सिंगल पॉइंट ऑफ फेलियर है जिसे आप आंशिक रूप से आउटसोर्स करते हैं। इसे मजबूत करना ग्लैमरस नहीं है, और यह केवल उस दिन फायदा देता है जब कोई Fox-IT के साथ हुआ वही करने की कोशिश करता है।

Namefi का कोण

Fox-IT घटना, मूल रूप से, एक नियंत्रण-और-उत्पत्ति की समस्या है। हमलावर को Fox-IT होने की जरूरत नहीं थी। उसे केवल एक सिस्टम — रजिस्ट्रार पैनल — को यह विश्वास दिलाने की जरूरत थी कि वह था, DNS को पुनर्निर्देशित करने और एक सर्टिफिकेट बनाने के लिए पर्याप्त समय के लिए। नीचे का सब कुछ उस विश्वास पर भरोसा करता था।

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

इनमें से कोई भी एक दृढ़ हमलावर को असंभव नहीं बना देगा। लेकिन Fox-IT की कहानी अंततः एक चोरे गए लॉगिन के बारे में है जो एक नाम के कुल नियंत्रण में तब्दील हो गया। जितना करीब डोमेन नियंत्रण सत्यापन योग्य स्वामित्व के पास होता है — और एक अकेले पुराने पासवर्ड से एक नाम को चुपचाप बदलना जितना कठिन होता है — उतनी ही कम Fox-IT के "अगर जब बन गया" जैसा एक क्षण किसी का ध्यान आने से पहले फैल सकता है।

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

स्रोत और आगे पढ़ें

• Fox-IT (NCC Group) — मैन-इन-द-मिडल हमले से सीखे गए सबक (प्राथमिक पोस्ट-मॉर्टेम)
• BleepingComputer — शीर्ष सुरक्षा फर्म ने MitM सुरक्षा घटना स्वीकार की
• Help Net Security — सुरक्षा कंपनी Fox-IT ने सितंबर में भोगे MitM हमले का खुलासा और विवरण दिया
• Graham Cluley — Fox-IT ने खुलासा किया कि हैकर्स ने DNS रिकॉर्ड हाईजैक किया और क्लाइंट फाइलों की जासूसी की
• SecurityWeek — हैकर्स ने सुरक्षा फर्म Fox-IT को निशाना बनाया
• GBHackers — अग्रणी IT सुरक्षा फर्म Fox-IT साइबर हमले की चपेट में
• Krebs on Security — हाल ही के व्यापक DNS हाईजैकिंग हमलों पर गहन जानकारी (संबंधित: बड़े पैमाने पर DNS-hijack + fraudulent-cert तकनीक)