CVE-2025-4275 (Hydr0ph0bia) का विश्लेषण और शोषण, एक Secure Boot ट्रस्ट-चेन कमजोरी जहाँ फर्मवेयर वेरिएबल्स का उपयोग आक्रमणकारी-नियंत्रित प्रमाणपत्रों को पेश करने के लिए किया जाता है जिन पर बाद के बूट घटक भरोसा करते हैं।
यह रिपॉज़िटरी CVE-2025-4275 से संबंधित शोध सामग्री को समाहित करती है, जो Insyde H2O पर आधारित UEFI-संगत फर्मवेयर को प्रभावित करने वाली एक Secure Boot बायपास भेद्यता है। यह भेद्यता के तकनीकी विश्लेषण, इस मुद्दे में शामिल बाइनरीज़, तथा शोधकर्ताओं को वास्तविक दुनिया और शैक्षिक दोनों संदर्भों में इस भेद्यता को बेहतर ढंग से समझने, अध्ययन करने और प्रयोग करने में सहायता करने के उद्देश्य से प्रलेखन और टूलिंग को केंद्रीकृत करती है।
CVE-2025-4275 की मूल खोज और जिम्मेदारीपूर्वक प्रकटीकरण Nikolaj Schlej द्वारा किया गया था, जिसका समन्वय CERT/CC के माध्यम से किया गया। आधिकारिक और सामुदायिक संदर्भ:
CVE-2025-4275, जिसे Hydroph0bia (Insyde H2O पर एक श्लेष) कहा जाता है, Insyde H2O प्लेटफ़ॉर्म पर निर्मित UEFI-संगत फर्मवेयर को प्रभावित करने वाली एक Secure Boot बायपास भेद्यता है। यह भेद्यता फर्मवेयर अपडेट सबसिस्टम में एक डिज़ाइन दोष से उत्पन्न होती है: एक विश्वसनीय ड्राइवर द्वारा वोलेटाइल NVRAM वेरिएबल में लोड किए जाने वाले साइनिंग प्रमाणपत्र को इसके बजाय एक हमलावर द्वारा नॉन-वोलेटाइल वेरिएबल के रूप में पहले से भरा जा सकता है, जिससे फर्मवेयर किसी भी मनमाने बाहरी कोड पर इस तरह भरोसा करता है जैसे उसे स्वयं Insyde द्वारा हस्ताक्षरित किया गया हो।
इस भेद्यता को विशेष रूप से प्रभावशाली बनाने वाली बात इसकी सरलता और इसकी पहुँच का संयोजन है। शोषण के लिए केवल स्थानीय व्यवस्थापक विशेषाधिकार की आवश्यकता होती है, जो EFI System Partition में फ़ाइलें लिखने और NVRAM वेरिएबल बनाने के लिए पर्याप्त है, और यह 10 जून, 2025 से पहले निर्मित Insyde H2O फर्मवेयर चलाने वाले किसी भी सिस्टम को प्रभावित करता है। यह हमला OEM-अज्ञेयवादी है, जिसका अर्थ है कि यह Acer, Dell, Framework, Fujitsu, HP, Huawei, Lenovo, और Insyde-आधारित फर्मवेयर वितरित करने वाले किसी भी अन्य विक्रेता पर व्यापक रूप से लागू होता है।
UEFI नॉन-वोलेटाइल वेरिएबल स्टोरेज के लिए एक अमूर्त इंटरफ़ेस प्रदान करता है जिसे NVRAM कहा जाता है। इस इंटरफ़ेस की एक पुरानी विशेषता यह है कि किसी दिए गए नाम और GUID वाला एक नॉन-वोलेटाइल वेरिएबल समान पहचान वाले वोलेटाइल वेरिएबल के साथ सह-अस्तित्व में रह सकता है और उसे शैडो कर सकता है। यदि कोड एक वोलेटाइल वेरिएबल की अपेक्षा करता है (जो रनटाइम पर एक विश्वसनीय ड्राइवर द्वारा बनाया गया हो) लेकिन उसी नाम का एक नॉन-वोलेटाइल वेरिएबल पहले से मौजूद है, तो नॉन-वोलेटाइल संस्करण को इसके बजाय उपभोग किया जा सकता है। यह व्यवहार, जिसे कभी-कभी NVRAM वेरिएबल शैडोइंग कहा जाता है, इस भेद्यता का आधार है।
Insyde H2O का फर्मवेयर अपडेट सबसिस्टम ड्राइवरों के बीच एक साइनिंग प्रमाणपत्र संप्रेषित करने के लिए दो NVRAM वेरिएबल पर निर्भर करता है:
अपेक्षित प्रवाह में, दोनों वेरिएबल फर्मवेयर अपडेट प्रक्रिया के दौरान BdsDxe द्वारा वोलेटाइल के रूप में बनाए जाते हैं। SecurityStubDxe फिर इनका उपभोग यह सत्यापित करने के लिए करता है कि isflash.bin पर Insyde के प्रमाणपत्र द्वारा हस्ताक्षरित है, इससे पहले कि उसे निष्पादित करने की अनुमति दी जाए। महत्वपूर्ण दोष यह है कि SecurityStubDxe इन वेरिएबल की सामग्री पर भरोसा करने से पहले यह सत्यापित नहीं करता कि ये वोलेटाइल हैं या नॉन-वोलेटाइल।
CVE-2025-4275 का मूल कारण यह है कि SecurityStubDxe, SecureFlashSetupMode और SecureFlashCertData को पढ़ने के लिए GetVariable रनटाइम सेवा को सीधे कॉल करने के बजाय एक सामान्य लाइब्रेरी फ़ंक्शन का उपयोग करता है। इसका अर्थ है कि यह एक विश्वसनीय BdsDxe द्वारा सेट किए गए वोलेटाइल वेरिएबल और एक हमलावर द्वारा पहले से भरे गए नॉन-वोलेटाइल वेरिएबल के बीच अंतर नहीं कर सकता (इस विशिष्ट तकनीक की विस्तृत व्याख्या के लिए, निम्नलिखित रिपॉज़िटरी देखें "TheMalwareGuardian: Exploitation Technique NVRAM Variable Shadowing")।
परिणामस्वरूप, स्थानीय व्यवस्थापक विशेषाधिकार वाला एक हमलावर यह कर सकता है:
अगले बूट पर, SecurityStubDxe दोनों वेरिएबल पाएगा, उन्हें वैध मानेगा, और हमलावर के प्रमाणपत्र से हस्ताक्षरित किसी भी UEFI निष्पादन योग्य पर भरोसा करेगा, जिससे Secure Boot पूरी तरह से बायपास हो जाएगा। किसी फर्मवेयर-स्तरीय इंटरैक्शन, हार्डवेयर एक्सेस, या मेमोरी करप्शन प्रिमिटिव के शोषण की आवश्यकता नहीं है। हमला सतह केवल UEFI NVRAM राइट इंटरफ़ेस है, जो एक विशेषाधिकार प्राप्त OS सत्र से सुलभ है।
यह भेद्यता HUAWEI MateBook 14 2023 की सुरक्षा समीक्षा के दौरान खोजी गई थी, जो Secure Boot, फर्मवेयर पासवर्ड, और अन्य आधुनिक सुरक्षा सुविधाओं के साथ सक्षम Insyde H2O-आधारित फर्मवेयर चला रहा था। इन सुरक्षाओं के बावजूद, पूर्ण शोषण केवल OS-स्तरीय व्यवस्थापक विशेषाधिकारों का उपयोग करके प्राप्त किया गया था।
प्रारंभिक शोषण चरण के लिए एक छोटे Windows टूल (SFCD) की आवश्यकता होती है जो:
रिबूट के बाद, SecurityStubDxe दोनों वेरिएबल पढ़ता है और हमलावर के प्रमाणपत्र से हस्ताक्षरित किसी भी चीज़ पर भरोसा करना शुरू कर देता है। इस पहले चरण का एक व्यावहारिक प्रदर्शन एक कस्टम-प्रमाणपत्र-हस्ताक्षरित CrScreenshotDxe UEFI ड्राइवर को लोड करना है, जो फर्मवेयर वातावरण में मनमाने कोड निष्पादन के प्रमाण के रूप में, Secure Boot सक्षम होने पर, BIOS Setup स्क्रीन का स्क्रीनशॉट सफलतापूर्वक कैप्चर करता है।
एक महत्वपूर्ण बारीकी: CVE-2025-3052 में मौजूद IhisiParamBuffer वेरिएबल अक्सर Insyde-आधारित प्लेटफ़ॉर्म पर लॉक होता है, जिससे वहाँ सीधा शोषण कठिन हो जाता है। CVE-2025-4275 के लिए ऐसे किसी वेरिएबल के लिखने योग्य होने की आवश्यकता नहीं है और यह किसी भी मेमोरी करप्शन प्रिमिटिव पर निर्भर नहीं करता। यह हमला किसी भी Insyde H2O सिस्टम पर काम करता है जहाँ हमलावर NVRAM में लिख सकता है, जो अनपैच्ड फर्मवेयर पर डिफ़ॉल्ट व्यवहार है।
निम्नलिखित प्रारंभिक Secure Boot बायपास चरण के लिए एंड-टू-एंड हमले का वर्णन करता है, OS-स्तरीय एक्सेस वाले एक विशेषाधिकार प्राप्त हमलावर को मानते हुए:
भाग 1 में प्राप्त Secure Boot बायपास एक कहीं अधिक प्रभावशाली दूसरे चरण का द्वार खोलता है: DXE वॉल्यूम का पूर्ण टेकओवर, जो स्वयं Insyde फर्मवेयर अपडेट प्रक्रिया को हाईजैक करके प्राप्त किया जाता है।
Insyde H2O में फर्मवेयर अपडेट सबसिस्टम निम्नानुसार काम करता है: OS अपडेटर एक फर्मवेयर कैप्सूल और हस्ताक्षरित अपडेटर एप्लिकेशन (isflash.bin) को EFI System Partition पर रखता है, फिर SecureFlashInfo NVRAM वेरिएबल के अंदर एक SecureFlashTrigger=1 फ़्लैग सेट करता है। अगले बूट पर, फर्मवेयर ट्रिगर का पता लगाता है, PEI के दौरान फ्लैश राइट सुरक्षा को अक्षम करता है, और अंततः Insyde प्रमाणपत्र के विरुद्ध सत्यापन के बाद isflash.bin पर LoadImage को कॉल करता है, वही प्रमाणपत्र तंत्र जिसे CVE-2025-4275 एक हमलावर को बदलने की अनुमति देता है।
Secure Boot बायपास से DXE टेकओवर तक एस्केलेट करने के लिए तीन अतिरिक्त तकनीकी चरणों की आवश्यकता होती है:
एक बार सभी तीन शर्तें पूरी हो जाने पर, फर्मवेयर अपडेट मोड में रिबूट होता है, हमलावर के कस्टम isflash.bin को लोड करता है (हमलावर के प्रमाणपत्र से हस्ताक्षरित, जो अब शैडो किए गए SecureFlashCertData के कारण विश्वसनीय है), और इसे SPI फ्लैश असुरक्षित होने पर निष्पादित करता है। इस स्थिति से, हमलावर DXE वॉल्यूम में मनमानी सामग्री लिख सकता है, स्थायी ड्राइवर स्थापित कर सकता है या फर्मवेयर घटकों को इस तरह संशोधित कर सकता है जो OS पुनर्स्थापन और अधिकांश सुरक्षा नियंत्रणों से बच जाते हैं।
Insyde ने 10 जून, 2025 पैच चक्र के हिस्से के रूप में एक फिक्स जारी किया। फिक्स का विश्लेषण UEFITool-जनित रिपोर्ट और Diaphora के माध्यम से बाइनरी डिफिंग का उपयोग करके दो क्रमिक Dell BIOS अपडेट (एक पैच-पूर्व, एक पैच-पश्चात) की तुलना करके किया गया।
परिवर्तन तीन ड्राइवरों में केंद्रित थे:
यह फिक्स इस धारणा के तहत प्रभावी है कि एक हमलावर VariablePolicy या LibSetSecureVariable को बायपास नहीं कर सकता। हालाँकि, VariablePolicy का डिफ़ॉल्ट EDK2 कार्यान्वयन आंतरिक रूप से एक वैश्विक फ़्लैग का उपयोग करता है, जो भाग 2 में पराजित InsydeVariableLock के संरचनात्मक रूप से समान है। SPI प्रोग्रामिंग हार्डवेयर के माध्यम से भौतिक NVRAM संपादन भी फिक्स को पूरी तरह से बायपास कर देगा, हालाँकि भौतिक हमले पारंपरिक रूप से Secure Boot खतरा मॉडल के दायरे से बाहर हैं।
शोधकर्ता की अनुशंसित उपचार, BdsDxe और SecurityStubDxe के बीच प्रमाणपत्र रिले तंत्र से NVRAM को पूरी तरह से हटाना, Insyde द्वारा प्रयास किया गया था लेकिन इससे रिग्रेशन हुए और इसे भविष्य के इंजीनियरिंग चक्र तक स्थगित कर दिया गया।
10 जून, 2025 से पहले निर्मित Insyde H2O-आधारित फर्मवेयर वितरित करने वाला कोई भी विक्रेता संभावित रूप से प्रभावित है। प्रकटीकरण के समय पुष्ट स्थिति:
| विक्रेता | स्थिति |
|---|---|
| Dell | फिक्स्ड - प्रतिबंध समाप्ति के कुछ समय बाद BIOS अपडेट जारी |
| Lenovo | भेद्य - फिक्स की घोषणा, 2025-07-30 से डिलीवरी |
| Framework | भेद्य - प्रकटीकरण के समय कोई डिलीवरी अनुमान प्रदान नहीं किया गया |
| Acer | प्रकटीकरण के समय कोई सलाहकार या फिक्स प्रकाशित नहीं |
| Fujitsu | प्रकटीकरण के समय कोई सलाहकार या फिक्स प्रकाशित नहीं |
| HP | प्रकटीकरण के समय कोई सलाहकार या फिक्स प्रकाशित नहीं |
| Huawei | मूल परीक्षण डिवाइस विक्रेता - फिक्स स्थिति अज्ञात |
कुछ समान पर काम कर रहे हैं? UEFI, Kernel सुरक्षा, शोषण, या किसी अन्य रोचक सुरक्षा विषय पर शोध कर रहे हैं? यदि आपको एक एक्सप्लॉइट विकसित करने, किसी तकनीक का पता लगाने, या बस विचारों का आदान-प्रदान करने में सहायता चाहिए, तो संपर्क करने में संकोच न करें। मैं हमेशा शोध पर चर्चा करने, जहाँ मैं कर सकता हूँ सहायता करने, और रोचक परियोजनाओं पर सहयोग करने के लिए तैयार हूँ। बेझिझक मुझसे LinkedIn पर संपर्क करें।
