डिबग मोड की उपस्थिति के साथ माइक्रोसॉफ्ट से "गोल्डन की" के हालिया लीक ने विंडोज़ उपकरणों पर सुरक्षित बूट को अक्षम करने की अनुमति दी है। पढ़ते रहिये!
विंडोज़-आधारित ओएस अब मोबाइल परिदृश्य में डिफ़ॉल्ट और शीर्ष विकल्प नहीं हैं। एंड्रॉइड की ओपन सोर्स प्रकृति को ओईएम में कई प्रशंसक मिल गए हैं, और परिणामस्वरूप, इन दिनों कम से कम फोन विंडोज का उपयोग करते हैं।
लेकिन अगर आप उन लोगों में से हैं जो अभी भी अपने दैनिक जीवन में विंडोज डिवाइस का उपयोग करना जारी रखते हैं, तो आपके लिए एक खबर है। अच्छा या बुरा, यह इस समाचार के उपयोग के मामलों पर आपके रुख और व्याख्या पर निर्भर करेगा।
जैसा कि रिपोर्ट किया गया है आर्स टेक्निका और रजिस्टर ए से उत्पन्न समाचार के साथ ऐसी वेबसाइट जो संभवतः आपके लिए सिरदर्द बन जाएगी (मज़ाक नहीं कर रहे), कुछ डेवलपर्स (@कभी_रिलीज़ नहीं हुआ और @TheWack0lian) पता चला है कि डिबग प्रयोजनों के लिए माइक्रोसॉफ्ट द्वारा बनाए गए पिछले दरवाजे ने विंडोज उपकरणों पर सुरक्षित बूट को अक्षम करने की संभावनाएं खोल दी हैं।
सुरक्षित बूट और यह क्या है?
जब आप पहली बार किसी विंडोज़ डिवाइस को बूट करते हैं, तो बूट प्रक्रिया इस सामान्य क्रम में होती है: यूईएफआई (यूनिफाइड एक्स्टेंसिबल फ़र्मवेयर इंटरफ़ेस, जो BIOS का प्रतिस्थापन है) -> बूट मैनेजर -> बूट लोडर -> खिड़कियाँ। यूईएफआई वह जगह है जहां सुरक्षित बूट कार्यक्षमता मौजूद है। जैसा कि नाम से ही स्पष्ट है
सिक्योर बूट एक वैकल्पिक सुविधा है, लेकिन माइक्रोसॉफ्ट ने विंडोज 8 और उसके बाद से विंडोज प्रमाणन प्राप्त करने के लिए इसे सक्षम करना अनिवार्य बना दिया है। यहां तर्क यह था कि सुरक्षित बूट से मैलवेयर लेखकों के लिए बूट प्रक्रिया में कोड डालना मुश्किल हो जाएगा। हालाँकि, सिक्योर बूट का एक साइड इफेक्ट यह था कि इसने विंडोज मशीनों पर डुअल-बूट को थोड़ा जटिल बना दिया था या तो दूसरे ओएस और उसकी सभी पूर्व-आवश्यकताओं को भी डिजिटल रूप से हस्ताक्षरित करने की आवश्यकता होगी, या सिक्योर बूट की आवश्यकता होगी अक्षम। इसमें कई अन्य मुद्दे भी हैं, और अनुभवी डुअल-बूटर्स उनके बारे में जितना मैं एक पैराग्राफ में समझा सकता हूं उससे कहीं अधिक जानते होंगे।
अब, कुछ डिवाइस ऐसे हैं जिन पर सिक्योर बूट को उपयोगकर्ता चाहकर भी अक्षम नहीं कर सकता है। यह वह क्षेत्र है जहां हमारी विषय-वस्तु सभी विंडोज़ डिवाइसों (जिनमें शामिल हैं) से काफी कम हो जाती है डेस्कटॉप) विशिष्ट विंडोज़ डिवाइस जैसे विंडोज़ फोन डिवाइस, विंडोज़ आरटी डिवाइस, कुछ सरफेस डिवाइस और यहां तक कि होलोलेन्स। ये अंतिम उपयोगकर्ता डिवाइस हैं सुरक्षित बूट चालू है, जिसका अर्थ है कि एक अंतिम उपयोगकर्ता सुरक्षित बूट से संबंधित पहलुओं को संशोधित या अक्षम नहीं कर सकता है, और विस्तार से, वे अंतिम उपयोगकर्ता के लिए Microsoft द्वारा अधिकृत नहीं किए गए तरीकों से OS को नहीं छू सकते हैं।
लेकिन चल रहे आधिकारिक विकास के प्रयोजनों के लिए, सिक्योर बूट को थोड़ा ढीला करने की आवश्यकता है। जिन उपकरणों पर सिक्योर बूट लॉक है, उन पर सिक्योर बूट नीतियां मौजूद हैं जो सिक्योर बूट को अक्षम किए बिना अधिकृत विकास में मदद कर सकती हैं। जैसा कि शोध करने वाले उपयोगकर्ताओं का उल्लेख है, यह सुरक्षित बूट नीति फ़ाइल विंडोज़ के लिए बूट प्रक्रिया के आरंभ में बूट प्रबंधक द्वारा लोड की जाती है। पॉलिसी फ़ाइलों में रजिस्ट्री नियम भी शामिल हो सकते हैं जिनमें अन्य चीज़ों के अलावा पॉलिसी के लिए कॉन्फ़िगरेशन शामिल करने की क्षमता होती है। फिर से, नीति फ़ाइल पर हस्ताक्षर किए जाने चाहिए और इसमें अन्य प्रावधान भी हैं जो यह सुनिश्चित करने के लिए मौजूद हैं कि केवल Microsoft ही इन परिवर्तनों का प्रावधान कर सकता है।
हस्ताक्षर करने वाला तत्व डिवाइस आईडी पर भी निर्भर करता है, जिसका उपयोग आवेदन करते समय किया जाता है। मैं ब्लॉग पोस्ट को यहाँ समझाने दूँगा, क्योंकि कुछ हिस्से हैं जो मेरे लिए उतने स्पष्ट नहीं हैं:
इसके अलावा, डिवाइसआईडी नाम की भी एक चीज़ होती है। यह कुछ UEFI PRNG आउटपुट के नमकीन SHA-256 हैश के पहले 64 बिट हैं। इसका उपयोग विंडोज फोन और विंडोज आरटी पर नीतियों को लागू करते समय किया जाता है (मोबाइलस्टार्टअप इसे फोन पर सेट करता है, और सिक्योरबूटडिबग.ईएफआई जब इसे आरटी पर पहली बार लॉन्च किया जाता है)। फ़ोन पर, पॉलिसी डिवाइसआईडी के हेक्स-फॉर्म सहित फ़ाइल नाम के साथ ईएफआईईएसपी विभाजन पर एक विशिष्ट स्थान पर स्थित होनी चाहिए। (रेडस्टोन के साथ, इसे अनलॉकआईडी में बदल दिया गया, जो बूटएमजीआर द्वारा सेट किया गया है, और सिर्फ कच्चा यूईएफआई पीआरएनजी आउटपुट है)।
मूल रूप से, बूटएमजीआर लोड होने पर पॉलिसी की जांच करता है, यदि इसमें एक डिवाइसआईडी शामिल है, जो उस डिवाइस के डिवाइसआईडी से मेल नहीं खाता है जिस पर बूटएमजीआर चल रहा है, तो पॉलिसी लोड होने में विफल हो जाएगी। कोई भी नीति जो टेस्टसाइनिंग को सक्षम करने की अनुमति देती है (एमएस इन रिटेल डिवाइस अनलॉक/आरडीयू नीतियों को कॉल करता है, और)। उन्हें इंस्टॉल करना एक डिवाइस को अनलॉक करना है), एक डिवाइसआईडी पर लॉक किया जाना चाहिए (रेडस्टोन पर अनलॉकआईडी और)। ऊपर)। दरअसल, मेरे पास इस तरह की कई नीतियां (विंडोज फोन उत्पादन प्रमाणपत्र द्वारा हस्ताक्षरित) हैं, जहां केवल शामिल डिवाइस आईडी और हस्ताक्षर में अंतर है। यदि कोई वैध नीति स्थापित नहीं है, तो बूटएमजीआर अपने संसाधनों में स्थित एक डिफ़ॉल्ट नीति का उपयोग करने के लिए वापस आ जाता है। यह नीति वह है जो बीसीडी नियमों का उपयोग करके परीक्षण हस्ताक्षर आदि को सक्षम करने से रोकती है।
यह वह हिस्सा है जहां चीजें दिलचस्प हो जाती हैं। विंडोज़ 10 v1607 के विकास के दौरान, माइक्रोसॉफ्ट ने आंतरिक परीक्षण और डिबगिंग उद्देश्यों के लिए एक नई प्रकार की सुरक्षित बूट नीति (संक्षिप्तता के लिए एसबीपी के रूप में संदर्भित) बनाई। नीति प्रकृति में "पूरक" है जिसमें कोई डिवाइस आईडी मौजूद नहीं है, और यह इसकी सेटिंग्स को मौजूदा बूट नीति में विलय कर देता है। बूट मैनेजर पुराने प्रकार के एसबीपी में लोड करता है, फिर उसके हस्ताक्षर और प्रामाणिकता की पुष्टि करता है और फिर इन पूरक बूट नीतियों में लोड करता है। यहां मुद्दा यह है कि पूरक नीति पर कोई और सत्यापन नहीं है। साथ ही, Windows 10 v1511 से पहले के बूट प्रबंधकों को इन नीतियों की पूरक प्रकृति के अस्तित्व के बारे में पता नहीं है, और इसलिए, इस तरह प्रतिक्रिया करें जैसे कि उन्होंने पूरी तरह से वैध और हस्ताक्षरित पॉलिसी लोड की हो. फिर, यह व्यवहार आंतरिक विकास के लिए होने की संभावना थी, ताकि डेवलपर्स को प्रत्येक ओएस संस्करण पर हस्ताक्षर न करना पड़े और उन्हें डिवाइस पर मामूली बदलाव न करना पड़े।
इस एसबीपी को "गोल्डन की" के रूप में संदर्भित किया जा रहा है क्योंकि यह मूल रूप से हस्ताक्षर जांच के उद्देश्य को समाप्त कर देता है। यह एसबीपी अनजाने में खुदरा उपकरणों पर भेज दिया गया था, यद्यपि निष्क्रिय अवस्था में। डेवलपर्स ने इस एसबीपी को पाया और अपने निष्कर्षों से अवगत कराया। अब, एसबीपी हो सकता है इंटरनेट पर तैरता हुआ पाया गया, इस विशेष ज़िप का उपयोग विंडोज़ आरटी उपकरणों पर एसबीपी स्थापित करने के लिए किया जा रहा है।
इसका अर्थ क्या है?
यदि आपने एक पूरक एसबीपी लोड किया है, तो आप अहस्ताक्षरित ड्राइवरों को लोड करने की अनुमति देने के लिए विंडोज़ के लिए परीक्षण हस्ताक्षर सक्षम कर सकते हैं। इसके अलावा, चूंकि ये नीतियां बूट प्रक्रिया में बूट मैनेजर चरण से पहले लागू होती हैं, आप पूरे ऑर्डर की सुरक्षा से समझौता कर सकते हैं और अनधिकृत (स्वयं हस्ताक्षरित पढ़ें) कोड चला सकते हैं। यह विंडोज़ के कुछ हिस्सों को प्राधिकरण से परे संशोधित करने का इरादा रखने वाले उपयोगकर्ताओं और मैलवेयर रचनाकारों के लिए समान रूप से बहुत सारी संभावनाएं खोलता है।
इस खोज के लेखक पूरे उपद्रव की विडंबना पर ध्यान केंद्रित करते हैं। Microsoft ने अनधिकृत परिवर्तनों को दूर रखने के लिए कुछ उपकरणों पर सिक्योर बूट को लॉक कर दिया, लेकिन फिर उन्हें विकास और डिबगिंग जारी रखने देने के लिए एक पिछले दरवाजे का निर्माण किया। लेकिन यही पिछला दरवाज़ा विंडोज़ चलाने वाले सभी उपकरणों पर सिक्योर बूट को अक्षम करने का मार्ग प्रशस्त करता है, जिससे पूरी प्रक्रिया व्यर्थ हो जाती है।
न केवल इच्छुक उपयोगकर्ता अब केवल विंडोज़ टैबलेट पर लिनक्स डिस्ट्रोस (और संभवतः एंड्रॉइड) इंस्टॉल कर सकते हैं फ़ोन, अनिच्छुक उपयोगकर्ताओं के पास दुर्भावनापूर्ण बूटकिट भी स्थापित हो सकते हैं यदि वे अपनी भौतिक पहुंच से समझौता करते हैं उपकरण। जबकि पहली ऐसी चीज़ है जिस पर हम हवा में उछल सकते हैं, दूसरी वास्तव में बहुत अधिक आत्मविश्वास पैदा नहीं करती है। यह दोनों तरफ जाता है, और यह हमें दिखाता है कि सुरक्षा एक दोधारी तलवार क्यों है। इसके अलावा, एसबीपी प्रकृति में सार्वभौमिक है, जो वास्तुकला की परवाह किए बिना किसी भी उपकरण पर इसके उपयोग की अनुमति देता है। यह डेस्कटॉप के मामलों के लिए विशेष रूप से उपयोगी नहीं है जहां सिक्योर बूट को आसानी से टॉगल किया जा सकता है, लेकिन यह उन डिवाइसों के लिए अत्यधिक गुंजाइश है जहां आप सिक्योर बूट के साथ खिलवाड़ नहीं कर सकते हैं।
तो, समाधान क्या है?
माइक्रोसॉफ्ट ने कुछ पैच जारी किए, लेकिन डेवलपर्स का कहना है कि समस्या पूरी तरह से ठीक नहीं हुई है। आप इन पैच की जांच कर सकते हैं (एमएस16-094 और एमएस16-100) और फिर पढ़ें ब्लॉग भेजा खुद इस बात पर कि वे इस मुद्दे का समाधान क्यों नहीं करते। यदि वे सही हैं, तो इस समस्या का कोई समाधान या पैच नज़र नहीं आता है, हालाँकि यह Microsoft को रास्ते में और अधिक बाधाएँ डालने की कोशिश करने से नहीं रोकेगा।
आगे क्या?
संभावनाओं की एक दुनिया है, और उनमें से कुछ हमारे विंडोज़ फ़ोरम पर विकसित हो रही हैं। आप हमारे मंचों को देख सकते हैं विंडोज फोन 8 विकास और हैकिंग और हमारे मंचों के लिए विंडोज 8, विंडोज आरटी और सरफेस डेवलपमेंट और हैकिंग. आप भी पा सकते हैं कुछ उपकरणों के लिए निर्देश सूत्र, जहां अन्य उपयोगकर्ता भी इसी पर चर्चा कर रहे हैं।
इस डिबग बैकडोर की उपस्थिति और एसबीपी का रिसाव न केवल तीसरे पक्ष के लिए महत्वपूर्ण है लॉक्ड विंडोज़ उपकरणों के विकास के साथ, वे हमें एक गंभीर अनुस्मारक भी दिखाते हैं कि यदि जानबूझकर किया गया तो क्या हो सकता है पिछले दरवाजे बचे हैं. सुरक्षा पर हालिया ध्यान जांच एजेंसियों की ओर केंद्रित हो गया है जो अपने कानूनी जांच उद्देश्यों में सहायता के लिए ऐसे पिछले दरवाजे की उपस्थिति के लिए दबाव डाल रहे हैं। लेकिन देर-सबेर ये तरीके इच्छा गलत हाथों में पड़ना. जिसे अपराध से लड़ने और न्याय में सहायता के लिए एक उपकरण के रूप में उपयोग करने का इरादा है, वह एक दिन स्वयं अपराध का उपकरण बन जाएगा।
डिबग एसबीपी के लीक पर आपके क्या विचार हैं? क्या आपको लगता है कि इस तरह की "गोल्डन कीज़" अस्तित्व में होनी चाहिए? नीचे टिप्पणी करके हमें बताएं!