themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyCVE-2024-7344 के बाद Howyar SysReturn NetCopy का विश्लेषण - रिवर्स इंजीनियरिंग नोट्स, कमजोर बाइनरीज़, विक्रेता पत्राचार, और CVE-2026-79298 (BOOTia32.efi में RxPE कस्टम PE लोडर के माध्यम से IA-32 Secure Boot बायपास) के लिए प्रूफ-ऑफ-कॉन्सेप्ट टूलिंग।
Secure Boot के आवरण के नीचे, कुछ संरचनाएँ उन कमज़ोरियों से भी गहरे तक डूब जाती हैं जिन्होंने उन्हें उजागर किया। कुछ बाइनरीज़ रद्द कर दी जाती हैं। कुछ पैच जारी कर दिए जाते हैं। लेकिन सतह के गहरे नीचे, पुरानी आदतें निशान छोड़ जाती हैं। जब कोई कमज़ोरी उजागर होती है, पैच होती है, और भुला दी जाती है, तो यही बचता है।
इस रिपॉज़िटरी में प्रलेखित निष्कर्षों को CVE-2026-79298 आवंटित किया गया है।
समन्वित प्रकटीकरण प्रक्रिया के दौरान, विक्रेता ने पुष्टि की कि CVE-2024-7344 से जुड़ा उपचार केवल x64 बूट पथ को संबोधित करता था। IA-32 बूट पथ - जिसमें SysReturn NetCopy सुविधा के हिस्से के रूप में वितरित BOOTia32.efi भी शामिल है - को मूल उपचार में कभी शामिल नहीं किया गया था। परिणामस्वरूप, कमज़ोर IA-32 घटक संस्करण 11.3.034 (जुलाई 2026) तक व्यावसायिक रूप से वितरित होता रहा।
समर्पित CVE रिपॉज़िटरी पूर्ण तकनीकी गहराई के लिए यहाँ वापस लिंक करती है: रिवर्स इंजीनियरिंग, बाइनरी विश्लेषण, विक्रेता पत्राचार, पुनरुत्पादन आर्टिफ़ैक्ट्स, और प्रूफ़-ऑफ़-कॉन्सेप्ट टूलिंग।
2026 के दौरान मैं UEFI सुरक्षा में गहराई से लगा रहा - बूटकिट विकास, Secure Boot बायपास, फ़र्मवेयर शोषण, CVE विश्लेषण, आक्रामक टूलिंग का विकास, अनुसंधान का प्रकाशन। यह वह क्षेत्र है जिसे मैंने विशेषज्ञता के लिए चुना है और हर सप्ताह कुछ नया लेकर आता है। उस कार्य का एक हिस्सा UEFI घटकों में ज्ञात CVE का शोषण करना है। एक हिस्सा उन सॉफ़्टवेयर का अनुसंधान करना है जो UEFI बूटलोडर वितरित करते हैं लेकिन जिन्हें बहुत कम सार्वजनिक जाँच मिली है। और एक हिस्सा - वह हिस्सा जिसे यह रिपॉज़िटरी प्रलेखित करती है - एक ऐसा प्रश्न पूछना है जो मुझे लगता है अक्सर अनदेखा कर दिया जाता है:
किसी CVE के बाद कोई उत्पाद कैसा दिखता है?
पैच की भागदौड़ के दौरान नहीं। उस सप्ताह नहीं जब सलाह जारी होती है। अठारह महीने बाद, जब दबाव खत्म हो जाता है, जब शोधकर्ता आगे बढ़ चुके होते हैं, जब कोई और नहीं देख रहा होता।
यह रिपॉज़िटरी एक विशिष्ट उत्पाद के लिए उस प्रश्न का उत्तर देने का मेरा प्रयास है: Howyar SysReturn NetCopy।
और मुझे लगता है कि मैंने जो पाया वह लोगों को चौंकाएगा।
सुरक्षा अनुसंधान में सब कुछ किसी और चीज़ से जुड़ता है यदि आप सूत्रों का पर्याप्त दूर तक पीछा करें। यह विशेष सूत्र काम पर शुरू हुआ। हमें एक विशिष्ट प्रकार के वातावरण के विरुद्ध UEFI और बूटकिट हमलों के वास्तविक-विश्व जोखिम का विश्लेषण करने का कार्य सौंपा गया था: शैक्षिक केंद्र। यह विशिष्ट लगता है। यह है नहीं।
यहाँ वह वास्तविकता है जिसे इस क्षेत्र के बाहर के अधिकांश लोग पूरी तरह से नहीं समझते। एक मध्यम आकार के शहर में, स्कूलों में आसानी से 70,000 या अधिक साझा उपकरण तैनात हो सकते हैं - लैपटॉप और वर्कस्टेशन जिनका उपयोग आठ से पंद्रह वर्ष की आयु के छात्र करते हैं, जो Linux वितरण चलाते हैं क्योंकि उस पैमाने पर Windows लाइसेंसिंग अक्सर निषेधात्मक होती है।
अब अपने आप से पूछें: उनमें से कितनी मशीनों में Secure Boot ठीक से सक्षम है? ईमानदार उत्तर, अधिकांश जगहों पर, बहुत कम है। और इसका कारण लापरवाही नहीं है। यह परिचालन वास्तविकता है।
Linux वातावरण में Secure Boot को ठीक से सक्षम करने का मतलब है हर कर्नेल पर हस्ताक्षर करना। हर कर्नेल अपडेट - और हाल के वर्षों में Linux कर्नेल कमज़ोरियाँ तेज़ी से आ रही हैं - के लिए हर एक मशीन पर एक नई हस्ताक्षरित इमेज तैनात करने की आवश्यकता होती है। इसका मतलब है समन्वित अपडेट पाइपलाइन, कुंजी प्रबंधन अवसंरचना, प्रशिक्षित कर्मचारी, और दर्जनों स्थानों पर वितरित हज़ारों एंडपॉइंट्स में निरंतर रखरखाव।
उन संगठनों के लिए जिनके पास वे संसाधन हैं, यह प्रबंधनीय है। अधिकांश स्कूल जिलों के लिए, यह नहीं है। उस पैमाने पर इसे ठीक से करने के लिए पर्याप्त लोग, पर्याप्त बजट, और पर्याप्त टूलिंग बस नहीं है। इसलिए Secure Boot अक्षम ही रहता है।
BIOS पासवर्ड सेट नहीं किए जाते - क्योंकि सीमित कर्मचारियों के साथ 70,000 मशीनों में उन्हें बदलना अव्यावहारिक है। और वे मशीनें वहीं पड़ी रहती हैं, फ़र्मवेयर स्तर पर पूरी तरह से उजागर, हर दिन सैकड़ों छात्रों द्वारा उपयोग की जाती हैं।
सुरक्षा के दृष्टिकोण से इसका वास्तव में क्या मतलब है, वह यह है कि UEFI शोषण को समझने वाला हमलावर उन मशीनों में से एक को फ़र्मवेयर परत पर समझौता कर सकता है - OS लोड होने से पहले, कोई भी सुरक्षा सॉफ़्टवेयर शुरू होने से पहले, किसी भी सुरक्षा तंत्र के हस्तक्षेप का मौका मिलने से पहले। एक बूटकिट रीबूट्स में, OS पुनर्स्थापनाओं में, हर चीज़ में बनी रह सकती है। मैं यह जानता हूँ क्योंकि मैं स्वयं उस प्रकार की टूलिंग विकसित करता हूँ। तकनीकें मौजूद हैं। वे सैद्धांतिक नहीं हैं।
यह एक ज्ञात समस्या है। इसे व्यापक रूप से स्वीकार किया जाता है। और यह जल्द ही खत्म होने वाली नहीं है।
उस समस्या का परिचालन उत्तर - वह चीज़ जो स्कूल वास्तव में उचित Secure Boot के बजाय तैनात करते हैं - है रिकवरी सॉफ़्टवेयर।
विचार सीधा है: एक सत्र के दौरान छात्र जो भी करे, अगले रीबूट के बाद सब कुछ ज्ञात-स्वच्छ स्थिति में लौट आता है। मैलवेयर, कॉन्फ़िगरेशन परिवर्तन, टूटी सिस्टम फ़ाइलें, गलती से या जानबूझकर हटाया गया डेटा - सब चला जाता है। यह रखरखाव लागत को नाटकीय रूप से कम करता है और प्रशासकों को हर डिवाइस पर सही फ़र्मवेयर-स्तरीय सुरक्षा नियंत्रणों की आवश्यकता के बिना साझा मशीनों को प्रबंधित करने का तरीका देता है।
जब हमने मूल्यांकन करना शुरू किया कि इन वातावरणों में कौन से उत्पाद उपयोग किए जा रहे थे, तो कई नाम सामने आए। उनमें से एक था Howyar SysReturn - एक ताइवानी उत्पाद जो विशेष रूप से शैक्षिक तैनातियों के लिए डिज़ाइन किया गया है, जिसमें स्कूल कंप्यूटर लैब, साझा वर्कस्टेशन, और बड़े पैमाने पर प्रबंधित वातावरणों के लिए स्पष्ट समर्थन है।
जैसे ही मैंने वह नाम देखा, मुझे ठीक-ठीक पता था कि मैं क्या करना चाहता हूँ।
जनवरी 2025 में, ESET Research ने CVE-2024-7344 का प्रकटीकरण प्रकाशित किया - एक Secure Boot बायपास जो SysReturn और उसी कोडबेस पर बने कई अन्य रिकवरी उत्पादों को प्रभावित करता है।
यह कमज़ोरी गहराई से निराशाजनक तरीके से सुंदर थी। एक Microsoft-हस्ताक्षरित UEFI एप्लिकेशन - जिस पर फ़र्मवेयर भरोसा करता है, जो Secure Boot सक्षम होने पर भी चल सकता है - ने पूरी तरह से शून्य से अपना स्वयं का कस्टम PE लोडर लागू किया था। मानक UEFI LoadImage और StartImage फ़ंक्शन्स का उपयोग करने के बजाय, जो Secure Boot हस्ताक्षर सत्यापन लागू करते हैं, इसने cloak.dat नामक फ़ाइल से EFI बाइनरीज़ को मैन्युअल रूप से पार्स और निष्पादित किया। सिंगल-बाइट कुंजी के साथ XOR-एन्क्रिप्टेड। कोई हस्ताक्षर जाँच नहीं। उस फ़ाइल के अंदर जो भी था, वह पूर्ण फ़र्मवेयर-स्तरीय विश्वास के साथ चला।
Microsoft ने जनवरी 2025 Patch Tuesday अपडेट में कमज़ोर बाइनरीज़ को रद्द कर दिया। सुरक्षा उद्योग अगली चीज़ पर आगे बढ़ गया। लेकिन मैं इसके बारे में सोचता रहा।
