Teku और Besu ने eMudhra घटना के बाद अपने-अपने Docker इमेज को अपडेट किया है, क्योंकि कमजोर सर्टिफिकेट कुंजी बाहरी सेवाओं से जुड़ने वाले सॉफ्टवेयर को जोखिम में डालती है, जिसमें कुछ ईथरियम वैलिडेटर डिप्लॉयमेंट भी शामिल हैं।
- Teku 26.10.3 और Besu 26.10.2 में eMudhra घटना के कारण प्रभावित प्रमाणपत्र विश्वास को Docker इमेज से हटा दिया गया है।
- Teku के अनुसार, डिफ़ॉल्ट मेननेट नोड प्रभावित नहीं होते हैं, और वास्तविक प्रकटता का स्तर HTTPS कनेक्शन और संचालक द्वारा उपयोग किए जाने वाले Java रनटाइम पर निर्भर करती है।
- प्रकट जोखिमों में छल किए गए सेवाओं और प्रमाणीकर्ता संचालन शामिल हैं, और टेकू की घोषणा में कोई दुरुपयोग का उल्लेख नहीं किया गया है।
ऑपरेटर्स के लिए वर्तमान में सबसे सीधा प्रश्न यह है कि अन्य सेवाओं से जुड़ते समय उनका सॉफ्टवेयर झूठे सर्टिफिकेट को स्वीकार करेगा या नहीं। उत्तर उपयोग किए जा रहे कनेक्शन और Java इंस्टॉलेशन पर निर्भर करता है, इसलिए क्लाइंट अपडेट का मतलब यह नहीं है कि प्रत्येक वेरिफायर को समान जोखिम का सामना करना पड़ रहा है।
Teku और Besu Docker इमेज़ अपडेट करें
एथेरियम क्लाइंट टीम ने ब्लॉकचेन के बाहर शुरू हुए सर्टिफिकेट समस्या को ठीक करने के लिए अपडेट जारी किया है। संबंधित परिवर्तन सॉफ्टवेयर के तरीके से संबंधित हैं कि यह दूरस्थ सेवाओं की प्रामाणिकता कैसे निर्धारित करता है।
Teku 26.10.3 और Besu 26.10.2 ने प्रभावित प्रमाणपत्र मूल पर विश्वास को अपने Docker इमेज से हटा दिया है। यह रिलीज eMudhra के साथ संबंधित कमजोर कुंजी के पता चलने के कारण आई है।
वेरिफायर ऑपरेटर्स के लिए, समस्या यह है कि हमलावर सॉफ्टवेयर द्वारा जुड़ी सेवा का नकली रूप अपनाता है। इस सेवा की भूमिका के आधार पर, झूठी प्रतिक्रिया जिम्मेदारियों को अव्यवस्थित कर सकती है, या कुछ ब्लॉक शुल्क के भुगतान की दिशा को प्रभावित कर सकती है।
लेकिन इसका अर्थ यह नहीं है कि प्रत्येक ईथरियम वैलिडेटर जोखिम में है। टेकू की सुरक्षा सूचना के अनुसार, डिफ़ॉल्ट मेननेट नोड प्रभावित नहीं हैं, और अभी तक कोई दुरुपयोग की रिपोर्ट नहीं हुई है।
अंतर स्थापना विधि में है। बाहरी HTTPS सेवा का उपयोग करने वाले संचालकों को उन संबंधों की जांच करनी चाहिए जो पूरी तरह स्थानीय घटकों के अधिष्ठापन में आवश्यक नहीं हो सकते।
ये अपडेट विशिष्ट स्थापना परिवेश के लिए लागू होते हैं। पैच किए गए Docker इमेज में कंटेनर के भीतर पैक किए गए रनटाइम संशोधन शामिल हैं, जबकि आर्काइव फ़ाइल से स्थापित सॉफ़्टवेयर में संचालक द्वारा प्रदान किया गया Java हो सकता है।
इस घटना से पुष्टिकर्ताओं के आसपास की बुनियादी ढांचे प्रभावित हुआ, जबकि ईथरियम के सहमति नियम अपरिवर्तित रहे।
Why do certificate issues turn into security risks?
सर्टिफिकेट सॉफ्टवेयर को यह निर्णय लेने में मदद करते हैं कि वह अपनी अपेक्षित सेवा से जुड़ा हुआ है या नहीं। विश्वसनीय सर्टिफिकेट प्रदाता सर्वर सर्टिफिकेट के संबंधित पहचान के लिए प्रमाणन प्रदान करते हैं।
यह तंत्र HTTPS वेबसाइट्स में सामान्य है, लेकिन ब्राउज़र के माध्यम से संचार न करने वाले एप्लिकेशन में भी लागू होता है। बैकएंड सेवाएँ भी इन पहचान सत्यापनों पर निर्भर कर सकती हैं।
सर्टिफिकेट अथॉरिटी ट्रस्टेड रूट सर्टिफिकेट के नीचे इंटरमीडिएट सर्टिफिकेट का उपयोग कर सकती है। इन इंटरमीडिएट सर्टिफिकेट्स से संबंधित प्राइवेट की को सुरक्षित रखा जाना चाहिए, क्योंकि इनका उपयोग अधिक सर्टिफिकेट जारी करने के लिए किया जा सकता है।
इस घटना में, समस्या केवल यह नहीं थी कि किसी ने सर्वर के सामान्य लॉगिन जानकारी प्राप्त कर ली। प्रभावित मध्यवर्ती कुंजियाँ पहले से उपलब्ध जानकारी से पुनः प्राप्त की जा सकती हैं।
Go सुरक्षा टीम के बयान के अनुसार, इस कमजोरी के कारण माइक्रोसेकंड स्तर पर निजी कुंजी पुनर्प्राप्त की जा सकती है। इसका वर्णन यह भी बताता है कि हमलावर बाद में अपने द्वारा नियंत्रित नहीं किए जा रहे डोमेन के लिए प्रमाणपत्र बना सकते हैं।
यदि कोई आसानी से हमले का शिकार होने वाला एप्लिकेशन इस बात पर विश्वास करता है कि यह प्रमाणपत्र अंततः उसके द्वारा विश्वसित संस्थान तक पहुँचता है, तो यह इसे स्वीकार कर सकता है। इस प्रकार, छल करने वाले की पहचान को मूल रूप से छलकारों को अस्वीकार करने के लिए डिज़ाइन किए गए जाँच से गुज़ारा जा सकता है।
हालाँकि, हमलावर को अभी भी किसी तरह से शिकार के कनेक्शन को इंटरसेप्ट या पुनः निर्देशित करने की आवश्यकता होती है। कमजोर कुंजियाँ स्वयं उन्हें प्रत्येक उपयोगकर्ता और प्रत्येक सर्वर के बीच नहीं ला सकतीं।
यह शर्त हमले के होने के तरीके को सीमित करती है, लेकिन प्रमाणपत्र को अमान्य करने को निरपेक्ष नहीं बनाती। जब तक सॉफ्टवेयर छलकारी को वास्तविक एंडपॉइंट मानता है, नेटवर्क इंटरसेप्शन अधिक खतरनाक हो जाता है।
Kudelski Security की अध्ययन ने प्रभावित प्रमाणपत्र स्तर की जांच की। समस्या यह है कि सॉफ्टवेयर उन प्रमाणपत्रों को स्वीकार कर सकता है जिन्हें हमलावर द्वारा पुनः उत्पन्न किया जा सकता है।
eMudhra ने कमजोर कुंजियों को संसाधन त्रुटि के कारण बताया है
eMudhra के घटना बयान के अनुसार, एक शोधकर्ता ने 17 अक्टूबर को 8 कमजोर मध्यवर्ती कुंजियों की रिपोर्ट की। कंपनी ने अगले दिन इन 8 कुंजियों को रद्द कर दिया।
कंपनी ने कहा कि ये मध्यवर्ती प्रमाणपत्र 30 अप्रैल, 2025 को एक कुंजी समारोह के दौरान उत्पन्न किए गए थे। कंपनी के अनुसार, दोषपूर्ण wrap और unwrap चरणों ने मजबूत कुंजी के अतिरिक्त कमजोर प्रतियाँ भी उत्पन्न कीं।
कंपनी ने कहा कि उसने प्रमाणित हार्डवेयर सिक्योरिटी मॉड्यूल का उपयोग किया है। उसने खराबी का कारण इस तरह के उपकरण की कमी के बजाय परिधीय प्रक्रियाओं में किसी एक चरण को बताया।
कंपनी ने यह भी कहा कि इनमें से 7 मध्यवर्ती प्रमाणपत्र कभी उत्पादन पर्यावरण में उपयोग नहीं किए गए थे, और शेष 1 का भी कोई प्रमाणपत्र जारी नहीं किया गया है। कंपनी ने कहा कि इस घटना से बुनियादी ढांचे का अवैध प्रवेश या डेटा लीक होने का कोई प्रमाण नहीं है।
ये बयान eMudhra द्वारा अपने आंतरिक संचालन के बारे में दी गई व्याख्या को समझाते हैं। हालाँकि, सॉफ्टवेयर आपूर्तिकर्ता को एक अन्य संभावना का सामना करना पड़ सकता है: अन्य पक्ष सुलभ कुंजियों का उपयोग कर सकते हैं।
सीएस केवल मूल संचालक द्वारा किसी भी चीज़ के जारी किए जाने का वादा करने पर निर्भर नहीं हो सकता। एक बार जब कोई और किसी साइनिंग कुंजी को पुनः उत्पन्न कर सकता है, तो ऐसी गारंटी सभी संभावित रूप से बनाए जा सकने वाले सर्टिफिकेट्स पर नियंत्रण नहीं रख सकती।
इसलिए, प्रतिक्रिया उस कंपनी से आगे बढ़ चुकी है जिसने कुंजी उत्पन्न की थी। ब्राउज़र निर्माता, ऑपरेटिंग सिस्टम आपूर्तिकर्ता और प्रोग्रामिंग भाषा टीमों को अपने उपयोगकर्ताओं के सॉफ़्टवेयर द्वारा क्या स्वीकार किया जाएगा, इसके बारे में विचार करना होगा।
ये ठीक किए गए संस्करण विभिन्न अपडेट के माध्यम से उपयोगकर्ताओं को प्राप्त होंगे। ब्राउज़र को ब्लॉक सूची प्राप्त हो सकती है, जबकि एक अलग Java ऐप अभी भी पुराने विश्वसनीय प्रमाणपत्र सेट का उपयोग कर सकता है।
Weak keys and applications that accept these keys are two different aspects of the same issue. Revoking certificates addresses the issue at the institutional record level, but clients also need a reliable way to identify which trust paths they should reject.
External services bring different risks to validators
Ethereum nodes consist of software that performs different roles. Ethereum client documentation distinguishes between execution clients and consensus clients: the former handles transaction execution and state, while the latter follows proof-of-stake consensus.
वेरिफायर सॉफ्टवेयर में ब्लॉक प्रस्तावित करने और चेन के लिए प्रमाण देने की जिम्मेदारियाँ शामिल हैं। ऑपरेटर इन घटकों को स्थानीय रूप से चला सकते हैं या कुछ को बाहरी सेवाओं के माध्यम से जोड़ सकते हैं।
Teku एक सहमति क्लाइंट है, Besu एक निष्पादन क्लाइंट है। दोनों जावा का उपयोग करते हैं, जिसके कारण उनके रनटाइम सर्टिफिकेट विश्वास उनके प्रकाशन से संबंधित है।
इस व्यवस्था के लिए स्थानीय मशीन के बाहर की सेवाएँ एक पहचान सत्यापन जोड़ती हैं। सॉफ़्टवेयर को यह सुनिश्चित करना होगा कि अनुरोध का उत्तर देने वाला एंडपॉइंट वास्तविक प्रदाता है।
उदाहरण के लिए, ऑपरेटर एक ही प्रक्रिया में हस्ताक्षर संचालन रखने के बजाय रिमोट साइनिंग सेवा का उपयोग कर सकते हैं। कुछ लोग डेटा या ब्लॉक बिल्डिंग सेवाएं प्रदान करने के लिए बाहरी एंडपॉइंट पर निर्भर कर सकते हैं।
दुर्भावनापूर्ण व्यक्ति कितना नुकसान पहुँचा सकता है, यह इस बात पर निर्भर करता है कि सेवा को क्या करने की अनुमति दी गई है। केवल मॉनिटरिंग डेटा स्वीकार करने वाली सेवा और हस्ताक्षर निर्णय में भाग लेने वाली सूचना प्रदान करने वाली सेवा में जोखिम अलग होता है।
नेटवर्क पथ भी समान रूप से महत्वपूर्ण है। सार्वजनिक बुनियादी ढांचे के माध्यम से कनेक्शन, एक ही होस्ट या कठोर नियंत्रित निजी नेटवर्क में केवल घटकों की तुलना में अलग अवरोधन के अवसर प्रदान करते हैं।
प्राइवेट नेटवर्क सभी खराबियों को असंभव नहीं बना सकता, लेकिन यह हमलावरों को ट्रैफिक विक्षेपित करने के लिए आवश्यक स्थान प्राप्त करने के अवसरों को कम कर सकता है।
इसलिए, क्लाइंट नाम केवल इस बात का निर्धारण नहीं कर सकता कि क्या यह उजागर है। समान सॉफ्टवेयर को विभिन्न एंडपॉइंट, ट्रस्ट लाइब्रेरी और एक्सेस कंट्रोल के साथ वातावरण में डिप्लॉय किया जा सकता है।
वास्तविक रूप से उत्तर देने की आवश्यकता वाला प्रश्न यह है कि प्रभावित पथ के माध्यम से कौन सा कनेक्शन प्रमाणपत्र स्वीकार करता है। जब यह स्पष्ट हो जाए, तो संचालक यह मूल्यांकन कर सकते हैं कि छलने वाली सेवा को वेरिफायर के कार्य में कितनी अधिकारिता प्राप्त होनी चाहिए थी।
क्यों Docker इमेज और आर्काइव इंस्टॉलेशन अलग हैं?
Docker इमेज एप्लिकेशन और उसके चलाने के लिए आवश्यक वातावरण को एक साथ पैक करता है, जिसमें Java रनटाइम और उस रनटाइम द्वारा विश्वसित प्रमाणपत्र शामिल हो सकते हैं।
होस्ट पर Java को अपडेट करने से मौजूदा इमेज में Java को स्वचालित रूप से प्रतिस्थापित नहीं किया जाता है। कंटेनर अभी भी अपने संपैक्टित फ़ाइलों का उपयोग करता रह सकता है।
यही कारण है कि क्लाइंट रिलीज नोट्स में डॉकर में बदलाव का उल्लेख किया गया है। टेकू के नोट्स के अनुसार, उस समय उनका Eclipse Temurin बेस इमेज इस हटाव को शामिल नहीं करता था, इसलिए क्लाइंट इमेज में सीधे संशोधन किए गए।
Besu के रिलीज नोट्स में यह भी बताया गया है कि इस अनुमति हटाने का अर्थ Docker इमेज के लिए है, और स्थापित उपयोगकर्ताओं को अपने द्वारा प्रदान किए गए Java वितरण की जांच करने का निर्देश दिया गया है।
Archiving the installation will leave this responsibility to the operator. The Ethereum client may have been updated, but its separate runtime may still contain old certificate stores.
विपरीत रूप से, रखरखाव के दौरान भी ऐसा ही अंतर दिखाई देता है। एक होस्ट रनटाइम को बदलने से उस रनटाइम का उपयोग करने वाली प्रक्रियाएं प्रभावित होती हैं, लेकिन अलग Java पथ का उपयोग करने वाली स्थापना प्रभावित नहीं होती।
Oracle की घटना निर्देशिका उपयोगकर्ताओं को प्रभावित रनटाइम को अपडेट करने या उनके दस्तावेज़ में दिए गए वैकल्पिक विकल्पों का पालन करने की सलाह देती है। इसके अलावा, यह चल रहे उदाहरणों को पुनः शुरू करने और प्रत्येक स्वतंत्र स्थापना को अलग से विचार करने की मांग करती है।
इससे चल रही प्रक्रियाएँ डाउनलोड की गई अपडेट से अधिक महत्वपूर्ण हो जाती हैं। सर्वर में पैच लगाए गए फाइलें हो सकती हैं, लेकिन पुरानी प्रक्रियाएँ तब तक चलती रहेंगी जब तक कि उन्हें प्रतिस्थापित या पुनः शुरू न किया जाए।
कस्टम सर्टिफिकेट स्टोर में एक और विविधता जोड़ी गई है। कोई संगठन अपनी सेवाओं के लिए बनाए गए सर्टिफिकेट स्टोर का उपयोग कर सकता है, केवल Java के डिफ़ॉल्ट सर्टिफिकेट स्टोर का उपयोग नहीं करता।
वास्तविक कार्य यह निर्धारित करना है कि क्लाइंट वास्तव में क्या उपयोग कर रहा है। स्थापना विधि, रनटाइम स्थान और विश्वास संरचना मिलकर यह निर्धारित करती हैं कि प्रकाशित ठीक किया गया संस्करण उस कनेक्शन तक पहुंच चुका है या नहीं जिसे इसकी आवश्यकता है।
Revocation checks vary across different applications
रद्द करने का अर्थ है कि प्रमाणपत्र को अब स्वीकार नहीं किया जाना चाहिए। लेकिन इसका अर्थ यह नहीं है कि प्रत्येक एप्लिकेशन संपर्क स्थापित करने से पहले नवीनतम रद्द की गई जानकारी की जांच करेगा।
विभिन्न अनुप्रयोग इन जानकारियों को प्राप्त करने के लिए अलग-अलग तरीके अपनाते हैं। कुछ ऑनलाइन सेवाओं की जांच करते हैं, कुछ आपूर्तिकर्ता द्वारा प्रदान किए गए ब्लॉकिंग सूचियों का उपयोग करते हैं, और कुछ मुख्य रूप से स्थानीय विश्वसनीय भंडार में प्रमाणपत्रों पर निर्भर करते हैं।
Go टीम के प्रतिक्रिया ने बताया कि रनटाइम विक्रेता को सीधे हस्तक्षेप करने की आवश्यकता क्यों हो सकती है। टीम ने 19 अक्टूबर को आपातकालीन सुरक्षा रिलीज शुरू की और बताया कि अलर्ट प्राप्त होने के लगभग 7.5 घंटे बाद ही पैच संस्करण उपलब्ध कराया गया।
यह क्रिया संबंधित Go सत्यापन व्यवहार का उपयोग करने वाले एप्लिकेशनों के प्रभावित प्रमाणपत्र पथ को रोक देती है। Java उपयोगकर्ताओं को अपने रनटाइम और विश्वास सेटिंग्स के माध्यम से सुरक्षा प्राप्त करनी होगी।
Teku के अनुसार, Java डिफ़ॉल्ट रूप से प्रतिकूलन की जांच नहीं करता है। इसीलिए, यद्यपि eMudhra ने इन मध्यवर्ती प्रमाणपत्रों को प्रतिकूलित कर दिया है, स्थानीय रूप से विश्वास को हटाना आवश्यक है।
रूट सर्टिफिकेट हटाना और मध्यवर्ती सर्टिफिकेट ब्लॉक करना भी अलग-अलग स्तरों पर कार्य कर सकते हैं। पहला एक विशिष्ट क्षतिग्रस्त पथ को अस्वीकार करता है, जबकि दूसरा हटाए गए रूट सर्टिफिकेट तक जाने वाली व्यापक सर्टिफिकेट श्रृंखला को अस्वीकार कर सकता है।
सही कार्यान्वयन आपूर्तिकर्ता और एप्लिकेशन के रखरखाव करने वाले संगठन का होता है। अगर आप अस्थायी रूप से पहचान सत्यापन को अक्षम करते हैं, तो यह केवल सुरक्षा को हटा देगा, विश्वास की समस्या का समाधान नहीं करेगा।
वैध सेवाओं को भी समायोजित करने की आवश्यकता हो सकती है। यदि उनके प्रमाणपत्र उन पथों पर निर्भर करते हैं जिन्हें अब ग्राहक अस्वीकार करता है, तो सेवा प्रदाता को असुरक्षित विश्वास को पुनर्स्थापित करने की उम्मीद नहीं करनी चाहिए, बल्कि स्वीकार्य विकल्प प्रदान करना चाहिए।
यह भी समझाता है कि एक प्रमाणपत्र घटना क्यों कई दिनों तक चल सकती है। खोज तुरंत हो सकती है, लेकिन सुरक्षा ब्राउज़र, पैकेज्ड ऐप्स और निजी बुनियादी ढांचे के विभिन्न प्रकाशन और रखरखाव प्रक्रियाओं के माध्यम से क्रमिक रूप से लागू होगी।
प्रमाणीकर्ता ऑपरेटर्स के लिए, महत्वपूर्ण परिणाम यह है कि संबंधित कनेक्शन ने अविश्वसनीय पहचान को अस्वीकार कर दिया है या नहीं। सॉफ्टवेयर इकोसिस्टम के अन्य स्थानों पर प्रतिकूल घोषणाएँ, इस बात का प्रमाण नहीं हैं कि उनके नोड प्रक्रिया ने इस परिणाम को प्राप्त कर लिया है।
क्या पुरस्कार और प्रमाणीकर्ता की स्टेकिंग समान तरीके से उजागर होते हैं?
वेरिफायर की स्टेकिंग, साइनिंग की जिम्मेदारियाँ और शुल्क भुगतान एक-दूसरे से संबंधित हैं, लेकिन वे अलग-अलग तंत्रों द्वारा नियंत्रित होते हैं। इनमें से किसी एक पर प्रभाव डालने वाली समस्या को स्वतः सभी के नियंत्रण के रूप में नहीं बताया जाना चाहिए।
ईथरियम स्टेकिंग दस्तावेज़ के अनुसार, प्रमाणीकर्ता अपने कर्तव्यों का पालन करके पुरस्कार प्राप्त करते हैं और ऑफलाइन होने या साबित किए जा सकने वाले अनुचित व्यवहार के कारण दंडित किए जाते हैं। हस्ताक्षर अधिकार और निकास अधिकार प्रणाली में अलग-अलग भूमिकाएँ निभाते हैं।
सर्टिफिकेट कुंजी जुड़ने के लिए उपयोग किए जाने वाले पहचान प्रणाली से संबंधित है। यह वैलिडेटर की निजी हस्ताक्षर कुंजी नहीं है और न ही इससे प्रतिबद्ध ETH निकासी के लिए प्रमाण पत्र सीधे प्रकट होते हैं।
हालांकि, छल किए गए सेवा का वैलिडेटर के व्यवहार पर प्रभाव पड़ सकता है। इसका प्रभाव इस बात पर निर्भर करता है कि सेवा कौन से अनुरोध या प्रतिक्रियाओं को संभालती है और कौन सी अतिरिक्त जांचें बनी हुई हैं।
ब्लॉक प्रस्ताव में संबंधित भुगतान के लिए शुल्क प्राप्त करने वाले का पता शामिल होता है। यदि कोई मार्ग प्रस्ताव या कॉन्फ़िगरेशन को बदलने में सक्षम है, तो पूरे स्टेकिंग पर नियंत्रण किए बिना भी परिणाम हो सकते हैं।
साइनिंग सेवा ने अन्य सेट के प्रश्न उठाए हैं, क्योंकि यह अधिकृत वैलीडेटर व्यवहार में शामिल है। इसकी अपनी सुरक्षा उपाय, जिनमें अनुरोधों की सीमा और विरोधी साइनिंग से बचाव शामिल हैं, हमलावर की क्षमता को प्रभावित करते हैं।
सेवा बाधा के कारण उत्तरदायित्व की लापरवाही भी एक संभावित परिणाम है। भले ही कोई भी भुगतान सफलतापूर्वक स्थानांतरित न हो, हमलावर केवल सही प्रतिक्रिया को रोककर पुरस्कार कम कर सकता है।
इन परिणामों का वित्तीय प्रभाव भिन्न होता है। प्रस्तावित ब्लॉक के अवसर को खोना, सामान्य ऑफलाइन दंड और कटौती दंड को मिला-जुला नहीं समझा जा सकता।
क्लाइंट अधिसूचना प्रभावित कॉन्फ़िगरेशन के तहत संभावित परिणामों का वर्णन करती है, लेकिन यह साबित नहीं करती कि प्रत्येक संचालक को इन परिणामों का सामना करना पड़ा है या उस संख्या में ETH चोरी हुआ है।
प्रतिभूति सेवादाता का उपयोग करने वाले धारकों के लिए, वास्तविक रूप से प्रासंगिक बात सेवादाता का वास्तविक अपडेट है। कितने ETH का प्रबंधन किया गया है, इससे यह नहीं पता चलता कि उनके संचालक ने कौन सी रिमोट सेवाएँ या सर्टिफिकेट लाइब्रेरी का उपयोग किया है।
वेरिफायर्स को ईथरियम के बाहर के सॉफ्टवेयर पर भी निर्भर करना पड़ता है।
Ethereum नेटवर्क नियम केवल संचालकों पर निर्भर करने वाले पहलुओं में से एक हैं। हार्डवेयर, रनटाइम, होस्टिंग, कॉन्फ़िगरेशन और बाहरी सेवाएँ यह तय करती हैं कि वैलिडेटर सही ढंग से अपने कर्तव्यों का पालन कर पाएगा या नहीं।
सर्टिफिकेट अथॉरिटी ईथेरियम प्रोटोकॉल के बाहर स्थित है, लेकिन जब वैलिडेटर सॉफ्टवेयर इसकी आवश्यकता सेवाओं की पहचान के लिए करता है, तो इसकी विफलता प्रासंगिक हो जाती है। इसके अलावा, यह प्रतिभूति बुनियादी ढांचे में एक सामान्य इंटरनेट सुरक्षा समस्या को लाने के लिए पर्याप्त है।
क्लाइंट विविधता अभी भी मूल्यवान है, क्योंकि विभिन्न कार्यान्वयन एकल कोडबेस पर निर्भरता को कम कर सकते हैं। लेकिन इसका अर्थ यह नहीं है कि प्रत्येक निर्भरता स्वतंत्र है।
दो क्लाइंट एक ही प्रोग्रामिंग भाषा रनटाइम का उपयोग कर सकते हैं। विभिन्न संचालक भी एक ही होस्टिंग सेवा प्रदाता, हस्ताक्षर सेवा या ब्लॉक बिल्डिंग बुनियादी ढांचे का उपयोग कर सकते हैं।
ये साझा घटक एथेरियम सॉफ्टवेयर के विभिन्न संस्करणों में सामान्य एक्सपोजर सतह बनाते हैं। इसलिए, डिप्लॉयमेंट को समझने के लिए केवल क्लाइंट ब्रांड की संख्या को देखना पर्याप्त नहीं है।
आउटसोर्सिंग से समझौते भी आते हैं। विशिष्ट हस्ताक्षर सेवा कुंजी सुरक्षा को बेहतर बना सकती है, लेकिन इस सेवा के साथ प्रमाणीकरण कनेक्शन को अधिक महत्वपूर्ण बना देती है।
स्थानीय रूप से चलाने के लिए अपनी अपनी रखरखाव की आवश्यकताएँ होती हैं। कंपोनेंट्स को एक ही मशीन पर रखने से कुछ नेटवर्क एक्सपोजर कम हो सकता है, लेकिन संचालक को उस मशीन पर सॉफ्टवेयर अपडेट्स और एक्सेस का प्रबंधन करना होगा।
यह घटना स्वतः किसी ऐसी व्यवस्था को नहीं देती जो सभी परिस्थितियों में सबसे सुरक्षित हो। यह बताती है कि प्रत्येक कनेक्शन के आसपास की जिम्मेदारियों को समझना और बनाए रखना आवश्यक है।
यह अंतर सामान्य ETH उपयोगकर्ताओं के लिए भी महत्वपूर्ण है। नोड बुनियादी ढांचे में सर्टिफिकेट पैच का अर्थ यह नहीं है कि प्रत्येक वॉलेट में धन का स्थानांतरण करना आवश्यक है, या यह कि ईथरियम खाते का शेष बदल गया है।
संबंधित कार्रवाई प्रभावित सॉफ्टवेयर ऑपरेटर्स की है। उन्हीं के पास शामिल रनटाइम, एंडपॉइंट और विश्वास सेटिंग्स की पहचान करने और फिर आपूर्तिकर्ता के संबंधित निर्देशों को इन कनेक्शन्स को स्थापित कर रहे सिस्टम पर लागू करने की क्षमता है।
ऑपरेटर को अपडेट लागू करने और जांचने की आवश्यकता है
ये प्रकाशन ऑपरेटर्स को समर्थित Docker इमेज से प्रभावित विश्वास पथ हटाने की अनुमति देते हैं। आर्काइव्ड उपयोगकर्ताओं को अपने-अपने Java विक्रेता के निर्देशों के अनुसार अलग-अलग रनटाइम कार्यों को संभालना होगा।
पैच उपलब्ध होना केवल प्रक्रिया का पहला चरण है। अपडेटेड वातावरण को वास्तविक रूप से चलाना होगा और उम्मीद के अनुसार कॉन्फ़िगरेशन और सेवाएँ सामान्य रूप से कार्य करती रहनी चाहिए।
सेवा प्रदाता के लिए, हाल ही में अस्वीकृत प्रमाणपत्र के कारण हुए विघ्न के कारण, एंडपॉइंट पर प्रमाणपत्र बदलने की आवश्यकता हो सकती है। सेवा को पुनः स्थापित करते समय, पहचान सत्यापन को बypass नहीं किया जाना चाहिए, बल्कि इसे बनाए रखा जाना चाहिए।
भविष्य के उद्घाटन अधिक विस्तार से प्रभाव को स्पष्ट कर सकते हैं। संचालक एक ऐसी कॉन्फ़िगरेशन की पहचान कर सकते हैं जिसने प्रभावित सर्टिफिकेट चेन को स्वीकार किया है, या विशिष्ट सेवाओं से संबंधित घटनाओं की रिपोर्ट कर सकते हैं।
अभी के लिए, Teku की सूचना रिपोर्ट का उपयोग नहीं किया गया है, और इसने डिफ़ॉल्ट मेननेट उपयोग और प्रभावित बाहरी कनेक्शन के बीच अंतर किया है। यह वर्तमान ईथरियम एक्सपोज़र को सबसे स्पष्ट रूप से वर्णित करने का आधार है।
प्रभावित ऑपरेटर्स को अपडेट करने का कारण है। कोई भी वित्तीय हानि हमलावर द्वारा किस सेवा का नकल किया गया, क्या ट्रैफिक अवरुद्ध किया गया, और प्रमाणीकर्ता ने उस सेवा को क्या अनुमति दी, इस पर निर्भर करती है।
क्या ध्यान देना चाहिए
- क्लाइंट अपडेट: Teku और Besu के रिलीज़ पर ध्यान दें और सुनिश्चित करें कि आपने ठीक किए गए संस्करण को चलाया है।
- Java सर्टिफिकेट: प्रत्येक स्थापना द्वारा उपयोग किए जा रहे Java रनटाइम और सर्टिफिकेट लाइब्रेरी के लिए विक्रेता निर्देश देखें।
- बाहरी लिंक: रिमोट साइनिंग, डेटा और ब्लॉक बिल्डिंग सेवाओं की HTTPS लिंक्स की समीक्षा करें।
- सुरक्षा सूचना: हमले की पुष्टि या अतिरिक्त जानकारी के लिए क्लाइंट टीम और जावा आपूर्तिकर्ता द्वारा जारी किए गए संदेशों का ध्यानपूर्वक अवलोकन करें।
अक्सर पूछे जाने वाले प्रश्न
eMudhra घटना क्या है?
इस घटना में, प्रमाणन प्राधिकरण eMudhra के मध्यवर्ती प्रमाणपत्र से संबंधित कमजोर निजी कुंजी शामिल है। शोधकर्ताओं ने पाया कि इन कुंजियों को जनसामान्य जानकारी से पुनः प्राप्त किया जा सकता है, जिससे अन्य लोग ऐसे डोमेन के प्रमाणपत्र बना सकते हैं जिन पर उनका नियंत्रण नहीं है। प्रमाणपत्र के मार्ग पर विश्वास करने वाले सॉफ़्टवेयर इस छलावरण को स्वीकार कर सकते हैं। हमलावर को लक्ष्य सेवा का नकली रूप धारण करने के लिए, संपर्क को अवरुद्ध या पुनः निर्देशित करने का कोई तरीका अभी भी आवश्यक है।
क्या ईथरियम कंसेंसस विफल हो गया है?
नहीं। रिपोर्ट में उल्लिखित समस्या सॉफ्टवेयर के बाहरी सेवाओं की पहचान कैसे जांचता है, इससे संबंधित है, न कि ईथरियम द्वारा ब्लॉकचेन पर सहमति के नियमों से। क्लाइंट अपडेट उन प्रभावित सॉफ्टवेयर वातावरणों में प्रमाणपत्र विश्वास को बदलते हैं। कुछ प्रमाणीकर्ता तैनातियाँ, यदि बाहरी सेवा का अपराधी द्वारा धोखा दिया जाता है, तो अभी भी संचालन जोखिम का सामना कर सकती हैं। यह संभावना संबंधित कनेक्शन और सेवा भूमिका पर निर्भर करती है, और इसका अर्थ यह नहीं है कि ईथरियम सहमति नियम भंग हो गए हैं।
किन क्लाइंट्स को अपडेट किया गया है?
Teku 26.10.3 और Besu 26.10.2 ने प्रभावित प्रमाणपत्र विश्वास को हटाने के लिए अपने Docker इमेज़ में संशोधन किए हैं। Teku समेकन क्लाइंट है और Besu निष्पादन क्लाइंट है, दोनों Java का उपयोग करते हैं। स्थापना विधि महत्वपूर्ण है, क्योंकि यह परिवर्तन इन इमेज़ में प्रदान किए गए वातावरण पर लागू होता है। क्लाइंट आर्काइव को स्थापित करने वाले और स्वयं Java रनटाइम प्रदान करने वाले संचालकों को उस रनटाइम के लिए अलग से मार्गदर्शन देखना चाहिए।
Will all validators be affected?
नहीं। टेकू के अधिसूचना के अनुसार, डिफ़ॉल्ट मेननेट नोड प्रभावित नहीं हैं। जोखिम इस बात पर निर्भर करता है कि किसी विशिष्ट डिप्लॉयमेंट ने संबंधित बाहरी HTTPS कनेक्शन किया है या नहीं, और उसकी प्रमाणपत्र जांच ने प्रभावित विश्वास पथ को स्वीकार किया है या नहीं। विभिन्न संचालक एक ही क्लाइंट को विभिन्न सेवाओं, Java संस्करणों और प्रमाणपत्र लाइब्रेरी के साथ चला सकते हैं। इसलिए, क्लाइंट का नाम या स्टेक किए गए ETH की संख्या, किसी विशिष्ट वैलिडेटर के प्रभावित होने का संकेत नहीं देते हैं।
क्या Docker अपडेट सभी स्थापना विधियों को कवर करता है?
नहीं। पैच किए गए Docker इमेज से इमेज में पैकेज किए गए वातावरण को अपडेट किया जाएगा, लेकिन आर्काइव इंस्टॉलेशन संचालक द्वारा प्रदान किए गए Java का उपयोग कर सकता है। अन्य कंटेनर या सेवाएँ भी अपने स्वयं के रनटाइम हो सकती हैं। संचालक को पहचानना होगा कि चल रही प्रक्रिया किस इंस्टॉलेशन विधि का उपयोग कर रही है और उसके विक्रेता के निर्देशों का पालन करना होगा। सर्वर पर पैच किए गए फ़ाइलें पुराने वातावरण में चल रही प्रक्रियाओं को सुरक्षित नहीं कर सकतीं।
क्या इसका दुरुपयोग सत्यापित किया गया है?
इस लेख में बताए गए समय बिंदु पर, टेकू के नोटिफिकेशन ने किसी दुरुपयोग की रिपोर्ट नहीं की है। संबंधित उद्घाटन एक कमजोरी और उसके संभावित परिणामों का वर्णन करता है, न कि यह साबित करता है कि हमलावर ने इसे वैलिडेटर के लिए इस्तेमाल किया है। हानि की चर्चा में यह अंतर महत्वपूर्ण है। एक सेवा का छल करने का संभावित मार्ग होना, साइनेचर के कर्तव्यों को हेरफेर करने, शुल्क भुगतान को स्थानांतरित करने या स्टेक किए गए ETH को चुराने के समान नहीं है।
Will validator deposits be automatically exposed?
नहीं। प्रमाणपत्र हस्ताक्षर कुंजी वैलिडेटर हस्ताक्षर कुंजी और निकासी के लिए अधिकार प्रदान करने वाली प्रमाणिकता से अलग होती है। प्रभावित प्रमाणपत्र कुंजी को पुनर्स्थापित करने से जमा किए गए ETH निकालने के लिए आवश्यक कुंजी स्वतः प्रकट नहीं होती। जो सेवा छलावरण का शिकार हुई है, वह इसके डिप्लॉयमेंट के आधार पर जिम्मेदारियों को उलट सकती है या वैलिडेटर्स द्वारा उपयोग की जाने वाली जानकारी को प्रभावित कर सकती है। इसे पूरे जमा राशि तक पहुँच का स्वतः संकेत मानने के बजाय, इस सेवा के लिए संभावित परिणामों का मूल्यांकन किया जाना चाहिए।
ऑपरेटर को क्या करना चाहिए?
ऑपरेटर्स को संबंधित Teku या Besu रिलीज नोट्स और उनके Java रिलीज के निर्देशों का पालन करना चाहिए। प्रत्येक प्रभावित प्रक्रिया द्वारा उपयोग किए जा रहे रनटाइम और सर्टिफिकेट स्टोर की पहचान की जानी चाहिए, जिसमें कंटेनर के भीतर प्रदान किए गए घटक शामिल हैं। सुझाए गए अपडेट लागू करने के बाद, यह सुनिश्चित करना चाहिए कि अपडेटेड सेवाएँ सक्रिय हैं और आवश्यक कनेक्शन सामान्य रूप से काम कर रहे हैं। विफल कनेक्शन को पुनः स्थापित करने के लिए सर्टिफिकेट जाँच को अक्षम करना, इन जाँचों द्वारा प्रदान की जाने वाली सुरक्षा को हटा देता है।