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 अपडेट में कमज़ोर बाइनरीज़ को रद्द कर दिया। सुरक्षा उद्योग अगली चीज़ पर आगे बढ़ गया। लेकिन मैं इसके बारे में सोचता रहा।
इसलिए नहीं कि कमज़ोरी स्वयं अनसुलझी थी - ESET ने इसे अच्छी तरह से प्रलेखित किया और रद्दीकरण स्पष्ट था। जो मुझे खींचता रहा वह एक अलग प्रश्न था। उस प्रकार का प्रश्न जो केवल समय के साथ उत्तर देने योग्य होता है:
क्या उन्होंने वास्तव में इसे ठीक किया? या उन्होंने बस दबाव के इर्द-गिर्द काम किया?
एक अंतर है। एक वास्तविक समाधान मूल कारण को संबोधित करता है - इस मामले में, एक कस्टम PE लोडर का उपयोग जो Secure Boot को बायपास करता है। एक वर्कअराउंड तत्काल समस्या को गायब कर देता है जबकि अंतर्निहित आर्किटेक्चर को बरकरार छोड़ देता है।
मैं जानना चाहता था कि Howyar ने इनमें से कौन सा किया था।
मैंने सीधे Howyar Technologies से संपर्क किया और एक पेशेवर खरीद मूल्यांकन के लिए SysReturn की एक मूल्यांकन प्रति का अनुरोध किया - जो, इस अनुसंधान को जन्म देने वाले पेशेवर संदर्भ को देखते हुए, पूरी तरह से सटीक था।
विक्रेता सहायक और उत्तरदायी था। उन्होंने एक पूर्ण परीक्षण लाइसेंस, मैनुअल, ट्यूटोरियल वीडियो, और एक पूर्ण मूल्यांकन पैकेज प्रदान किया। उन्होंने Secure Boot संगतता के बारे में विस्तृत प्रश्नों का भी उत्तर दिया, जो बाद में मैंने जो पाया उससे सीधे प्रासंगिक निकला।
वह सारा पत्राचार इस रिपॉज़िटरी में शामिल है, बिना संपादन के।
मैं यहाँ तकनीकी विवरण बर्बाद नहीं करने वाला - वह Vulnerability Research निर्देशिका के लिए है, और मैं वास्तव में इसे पूरा पढ़ने की सलाह देता हूँ। लेकिन मैं इतना कहूँगा।
UEFI अपनी ही दुनिया है। इसमें काम करने वाले डेवलपर्स कम हैं। एप्लिकेशन सॉफ़्टवेयर या वेब सेवाओं के लिए जो सुरक्षा समीक्षा प्रक्रियाएँ मौजूद हैं, वे नियमित रूप से फ़र्मवेयर घटकों तक नहीं पहुँचतीं। बुरी प्रथाएँ, एक बार स्थापित होने के बाद, बनी रहती हैं - दुर्भावना से नहीं, बल्कि इसलिए कि पारिस्थितिकी तंत्र छोटा है, जाँच दुर्लभ है, और इसे गलत करने के परिणाम अक्सर उन मुट्ठी भर शोधकर्ताओं के अलावा सभी के लिए अदृश्य होते हैं जो ध्यान दे रहे हैं।
SysReturn v11.2.031 में मैंने जो पाया - जो अप्रैल 2026 में जारी हुआ, Microsoft के रद्दीकरण के पंद्रह महीने से अधिक बाद - वह ठीक उसी गतिशीलता का स्पष्ट उदाहरण है।
मूल कारण ठीक नहीं किया गया था। कमज़ोर बाइनरी को बदला नहीं गया था। जो बदला वह परिचालन था: Secure Boot-सक्षम सिस्टम के लिए एक अलग बूट पथ, बाकी लगभग सब कुछ अछूता छोड़कर।
कस्टम PE लोडर - RxPE घटक, जिसका नाम बाइनरी के अपने डीबग स्ट्रिंग्स में है - अप्रैल 2026 रिलीज़ में मौजूद है, ठीक उसी तरह कार्य कर रहा है जैसे उसने 2024 में ESET द्वारा विश्लेषित संस्करण में किया था।
अप्रैल 2026 में Howyar द्वारा वितरित बाइनरी का Authenticode हैश, बाइट-दर-बाइट, उस हैश से मेल खाता है जिसे Microsoft ने जनवरी 2025 में रद्द किया था।
मुझे लगता है कि यह मायने रखता है। मुझे लगता है कि लोगों को इसके बारे में पता होना चाहिए। और मुझे लगता है कि इस रिपॉज़िटरी में तकनीकी प्रलेखन इतना विस्तृत है कि जो कोई भी इन निष्कर्षों को स्वयं सत्यापित करना चाहता है, वह कर सकता है।
| निर्देशिका | विवरण |
|---|---|
📚 00 Manual | Howyar द्वारा प्रदान किए गए विक्रेता मैनुअल, ब्रोशर, और आधिकारिक उत्पाद प्रलेखन |
📦 01 Binaries | विश्लेषण के लिए मूल्यांकन पैकेज से निकाली गई प्रमुख बाइनरीज़ |
📬 02 Disclosure | मूल्यांकन प्रक्रिया के दौरान Howyar Technologies के साथ पूरा ईमेल पत्राचार |
🔬 03 Vulnerability Research | रिवर्स इंजीनियरिंग, बाइनरी विश्लेषण, Authenticode सत्यापन, ALRM प्रारूप विश्लेषण, स्क्रिप्ट, और तकनीकी निष्कर्ष |
तकनीकी कहानी - BOOTia32.efi की पूरी रिवर्स इंजीनियरिंग, ALRM पेलोड प्रारूप, XOR डिक्रिप्शन, RxPE कस्टम PE लोडर, रद्द की गई बाइनरी के विरुद्ध Authenticode हैश मिलान, और Howyar ने वास्तव में क्या बदला बनाम क्या अछूता छोड़ा, इसका विश्लेषण - सब यहाँ है:
यदि आप "पैच" के बाद के विश्लेषण में उतरने से पहले CVE के बारे में संदर्भ चाहते हैं, तो ESET सलाह एक अच्छा संदर्भ है। मैं CVE-2024-7344 को प्रलेखित करने वाली एक रिपॉज़िटरी और संबंधित UEFI कमज़ोरियों को अधिक विस्तार से भी बनाए रखता हूँ।
पढ़ना शुरू करें। आवरण अभी भी वहीं है।
