Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
CVE-2025-47827 — CVE-2025-47827 के लिए PoC और भेद्यता रिपोर्ट | Kitploit
उपकरण/GitHubGitHub/zedeldi/cve-2025-47827
विशेषाधिकार वृद्धिस्थायित्व तंत्रभेद्यता विश्लेषणशोषणआईडीएस/आईपीएस से बचनापोस्ट-शोषणहार्डवेयर सुरक्षापेपर और शोधलर्निंग और शिक्षाफर्मवेयर विश्लेषणबाइनरी शोषण
421410 महीने पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें
GitHub
zedeldi/cve-2025-47827

CVE-2025-47827

CVE-2025-47827 के लिए PoC और भेद्यता रिपोर्ट

रिपॉजिटरी देखेंवेबसाइट

CVE-2025-47827

GitHub license GitHub last commit CVSS-8.4 CWE-347 CVE-2025-47827 ISN-2025-22 GHSA-pww7-j9v6-xc6j

Proof-of-concept और CVE-2025-47827 के लिए भेद्यता रिपोर्ट।

सामग्री

  • विवरण
  • प्रकटीकरण
  • प्रभाव
  • पहचान
  • शमन
  • बाइनरीज़
  • अवधारणा का प्रमाण
  • संसाधन

विवरण

IGEL OS v11 से पहले, Secure Boot को बायपास किया जा सकता है क्योंकि igel-flash-driver मॉड्यूल क्रिप्टोग्राफ़िक हस्ताक्षर की गलत तरीके से पुष्टि करता है। अंततः, एक नकली रूट फ़ाइलसिस्टम को एक असत्यापित SquashFS इमेज से माउंट किया जा सकता है।

IGEL OS 10 में igel-flash-driver Linux कर्नेल मॉड्यूल में क्रिप्टोग्राफ़िक हस्ताक्षर की गलत पुष्टि, एक दुर्भावनापूर्ण अभिकर्ता को Secure Boot को बायपास करने की अनुमति देती है। यह Microsoft 3rd Party UEFI CA द्वारा हस्ताक्षरित shim को बूट करके किया जाता है, जो फिर GRUB और कमजोर कर्नेल को लोड करता है, दोनों IGEL Secure Boot Signing CA द्वारा हस्ताक्षरित होते हैं। एक बार जब कमजोर कर्नेल और एम्बेडेड initramfs लोड हो जाता है, तो डिस्क पर मौजूद असत्यापित SquashFS इमेज से एक दुर्भावनापूर्ण रूट फ़ाइलसिस्टम माउंट किया जा सकता है।

चूँकि कमजोर कर्नेल में kexec_load सिस्टम कॉल उपलब्ध है, वर्तमान में बूट किए गए कर्नेल को पूरी तरह से अविश्वसनीय से बदला जा सकता है, जिससे व्यावहारिक रूप से विश्वास की पूरी श्रृंखला का पालन करते हुए कोई भी ऑपरेटिंग सिस्टम बूट हो सकता है।

IGEL OS के बाद के संस्करणों में, मॉड्यूल रूट फ़ाइलसिस्टम SquashFS इमेज के हस्ताक्षर की सही ढंग से पुष्टि करता है। हालाँकि, कमजोर कर्नेल और पैच किए गए संस्करण दोनों एक ही प्रमाणपत्र से हस्ताक्षरित होते हैं, जिससे एक ही shim कमजोर और पैच किए गए दोनों संस्करणों को बूट कर सकता है।

प्रक्रिया

बूट प्रक्रिया आरेख

वर्गीकरण

CVE-2025-47827 के लिए प्रारंभिक वेक्टर स्ट्रिंग AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H थी, जिससे CVSS स्कोर 8.4 (उच्च) प्राप्त हुआ।

14 अक्टूबर 2025 को, इसे बदलकर AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H कर दिया गया, जिससे स्कोर घटकर 4.6 (मध्यम) हो गया।

इसके अतिरिक्त, मूल कमज़ोरी को CWE-347: क्रिप्टोग्राफ़िक हस्ताक्षर की गलत पुष्टि के रूप में परिभाषित किया गया था, लेकिन MSRC ने इसे CWE-324: समाप्ति तिथि के बाद कुंजी का उपयोग के रूप में निर्दिष्ट किया है।

प्रकटीकरण

IGEL और Microsoft दोनों से संपर्क किया गया और उन्हें इस भेद्यता के बारे में सूचित किया गया, क्रमशः 6 दिसंबर 2024 और 31 मार्च 2025 को, इससे पहले कि विवरण 29 मई 2025 को सार्वजनिक किए गए।

चूँकि IGEL OS 10 असमर्थित है और भेद्यता सीधे shim में मौजूद नहीं है, किसी भी पक्ष ने कोई समाधान नहीं सुझाया है। Microsoft ने निम्नलिखित उत्तर दिया:

जाँच करने पर, हमने निर्धारित किया है कि यह सबमिशन सेवारत हेतु सुरक्षा भेद्यता की परिभाषा को पूरा नहीं करता है, क्योंकि IGEL OS v10 अब समर्थित नहीं है और समस्या कर्नेल मॉड्यूल में है, shim में नहीं। केवल shim पर MSFT प्रमाणपत्र द्वारा हस्ताक्षर किए गए हैं।

IGEL ने 2 जून 2025 को CVE-2025-47827 के लिए एक सुरक्षा सूचना प्रकाशित की।

13 जून 2025 को, मैंने इसकी रिपोर्ट Microsoft को फिर से की, और निम्नलिखित प्रतिक्रिया प्राप्त की:

यद्यपि आपकी रिपोर्ट में कुछ अच्छी जानकारी शामिल थी, यह Microsoft की सेवारत हेतु सुरक्षा भेद्यता की आवश्यकता को पूरा नहीं करती है। रिपोर्ट की गई समस्या कर्नेल मॉड्यूल में है, shim में नहीं, और केवल shim पर MSFT प्रमाणपत्र द्वारा हस्ताक्षर किए गए हैं। kexec पहले से ही डिज़ाइन के अनुसार सिक्योर बूट को बायपास करने की अनुमति देता है (संदर्भ: kexec कमांड लाइन इन लिनक्स - लिनक्स एक्सपर्ट बेटर 2025)।

यदि समस्या किसी बूट ड्राइवर/घटक में होती, तो यह MSRC की सेवारत मानदंडों को पूरा करती। यह Linux वितरण के कर्नेल ड्राइवर में एक भेद्यता है। यह UEFI "ExitBootServices" के बाद आता है, जिसका अर्थ है कि यह Secure Boot बायपास नहीं है। उपयोगकर्ता के पास केवल OS स्तर पर कोड निष्पादन है, बूट नहीं।

इस भेद्यता के बारे में विभिन्न समाचार लेखों के प्रकाशन के बाद, shim अनुरक्षकों ने Microsoft और IGEL के साथ समाधान पर चर्चा करने के लिए समन्वय किया।

समाधान पर पहुँचने के बाद, मैंने 20 अक्टूबर 2025 को MSRC पर एक और मामला बनाया, जिसमें इन shims को रद्द करने में देरी के पीछे का कारण, CVSS वेक्टर स्ट्रिंग और CWE में संशोधन, और उनकी अपडेट गाइड में यह क्यों बताया गया कि भेद्यता सार्वजनिक रूप से प्रकट नहीं हुई थी, इसके बारे में पूछा। मुझे निम्नलिखित प्रतिक्रिया मिली:

IGEL भेद्यता जो ठीक की गई थी, वह Secure Boot बायपास नहीं है। यह एक Linux-विशिष्ट कर्नेल अखंडता बायपास है और Windows को प्रभावित नहीं करता है। IGEL shims पुराने हैं और नए SBAT-आधारित रद्दीकरण का समर्थन नहीं करते हैं। इसलिए, Microsoft ने अन्य भेद्यताओं से संभावित शोषण से बचाने के लिए रद्दीकरण जारी किए, जो SBAT द्वारा संरक्षित किए गए हैं।

Jeffrey Sutherland, प्रिंसिपल लीड प्रोग्राम मैनेजर, ने PR पर उत्तर दिया यह समझाने के लिए कि, SBAT की कमी के कारण, shims को DBX द्वारा रद्द करना पड़ा, और IGEL ने किसी भी अनपेक्षित परिणाम से बचने के लिए अतिरिक्त समय का अनुरोध किया। उन्होंने समन्वित भेद्यता प्रकटीकरण के अनुसार, शोधकर्ता और शामिल पक्षों के बीच संचार बनाए रखने में विफलता के लिए भी माफी माँगी।

प्रभाव

Secure Boot बायपास शोषण से एक अज्ञात बूटकिट/कर्नेल-स्तरीय रूटकिट का विकास हो सकता है, जिसके बदले में कई निहितार्थ हो सकते हैं, जैसे:

  • कोड निष्पादन
  • विशेषाधिकार वृद्धि
  • सेवा अस्वीकार
  • सूचना लीक

रद्दीकरण या मैन्युअल हस्तक्षेप के बिना, Secure Boot उन सभी मशीनों पर बेकार हो गया है जो Microsoft 3rd Party UEFI CA पर भरोसा करती हैं, जो लेखन के समय अधिकांश उपकरणों के लिए डिफ़ॉल्ट है।

Kexec

यदि kexec के लिए उपयोग किया जाता है, तो इस भेद्यता का उपयोग किसी वैध सिस्टम को चुपचाप और दुर्भावनापूर्ण रूप से संशोधित करने के लिए किया जा सकता है, बिना Secure Boot को प्रभावित किए।

कर्नेल

कर्नेल को पूरी तरह से बदला जा सकता है, जिससे कर्नेल-स्तर पर दुर्भावनापूर्ण कोड चल सके, जिससे सिस्टम के सभी संसाधनों, जिसमें मेमोरी, CPU और कनेक्टेड डिवाइस शामिल हैं, तक अप्रतिबंधित पहुँच प्राप्त हो सके।

यह मेमोरी से एन्क्रिप्शन कुंजियाँ डंप करने, दुर्भावनापूर्ण प्रक्रियाओं को बिना किसी प्रतिबंध के निष्पादित करने और मैलवेयर को पता लगाने से बचने की अनुमति देगा।

पैरामीटर

टूल डाउनलोड करें