Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

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

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

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

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

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
Recreate-cve-2023-21768 — cve-2023-21768 के लिए एक्सप्लॉइट का पुनर्निर्माण करना। | Kitploit
उपकरण/GitHubGitHub/rosayxy/recreate-cve-2023-21768
भेद्यता विश्लेषणशोषणलर्निंग और शिक्षाबाइनरी शोषण
GitHubrosayxy/recreate-cve-2023-21768

Recreate-cve-2023-21768

cve-2023-21768 के लिए एक्सप्लॉइट का पुनर्निर्माण करना।

रिपॉजिटरी देखें
12 साल पहलेअभी तक समीक्षित नहीं

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

सभी देखें →

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

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

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

सभी उपकरण देखें →
साझा करें

कारण: AFD.sys के 202209 और 202307 संस्करणों की तुलना करने पर, फ़ंक्शन AfdNotifyRemoveIOCompletion में, Windows 202209 और Windows 202307 दोनों में ProbeForWrite फ़ंक्शन का उपयोग करके यह जाँचने का एक चरण है कि मेमोरी क्षेत्र उपयोगकर्ता मोड में है या नहीं, लेकिन जाँच किए गए बफ़र पते में 0x8 बाइट्स का अंतर है। इस भेद्यता के पैच से पहले, यह जाँच मौजूद नहीं थी, इसलिए अनुमान लगाया जा सकता है कि 202209 संस्करण का बफ़र जाँच पता गलत हो सकता है और अप्रभावी हो सकता है। यह जाँच बफ़र मध्यवर्ती चरण में एक असाइनमेंट से संबंधित है: **(_DWORD **)(a3 + 24) = v20; जहाँ जाँचा जाने वाला बफ़र a3+24 होना चाहिए, और v20 का मान v8 = IoRemoveIoCompletion(v25, Pool2, v4, (unsigned int)v6, &v20, a1, v13, 0) से संबंधित है। इसमें कम से कम Pool2, v4, v13 ऐसे दिखते हैं जो उपयोगकर्ता मोड से पारित उस अज्ञात स्ट्रक्ट द्वारा निर्धारित होते हैं, इसलिए अनुमान है कि v20 का मान भी उपयोगकर्ता मोड से पारित उस स्ट्रक्ट से संबंधित है~ (writeup देखने पर पता चला कि यह IoRemoveIoCompletion द्वारा KeRemoveQueueEx को कॉल करने का रिटर्न वैल्यू है)
और यदि a3+24 एक कर्नेल-मोड पता संग्रहीत करता है, तो यह एक kernel_arbitrary_write प्रिमिटिव का कारण बन सकता है, और फिर IORING का उपयोग करके शोषण किया जा सकता है~ (शोषण विधि: https://windows-internals.com/one-i-o-ring-to-rule-them-all-a-full-read-write-exploit-primitive-on-windows-11/)

पुनरुत्पादन वातावरण: Visual Studio 2022 में स्रोत कोड संकलित करना + Windows 11 202209 (Hyper-V पर चल रहा है) संकलन विकल्प x64 रिलीज़ है। चूँकि HyperV पर vcruntime140.dll गायब होने की समस्या है, इसलिए स्टैटिक लिंकिंग का उपयोग किया गया है।

AFD.sys में फ़ंक्शन श्रृंखला: AfdFastIOdeviceControl -> AfdNotifySock -> AfdNotifyRemoveIOCompletion, एक अज्ञात स्ट्रक्ट के एक फ़ील्ड को एक उपयोगकर्ता मोड-निर्धारित पते पर असाइन करता है, जिससे एक मनमाना कर्नेल Write-Where प्रिमिटिव बनता है और फिर IORing द्वारा शोषित किया जाता है।

एक्सप्लॉइट कार्यान्वयन: ArbitraryKernelWrite0x1 फ़ंक्शन के माध्यम से मनमाना लेखन कार्यान्वित किया जाता है। exp में इस फ़ंक्शन का मुख्य भाग x86matthew गुरु के एक पहिये का पुन: उपयोग करके Winsock को बायपास करके सीधे AFD.sys के साथ इंटरैक्ट करना है (पहिये का मूल उद्देश्य सीधे TCP सॉकेट बनाना था)(https://www.x86matthew.com/view_post?id=ntsockets)
उपरोक्त पाठ में मनमाना पता लिखने के लिए उपयोग किया जाने वाला स्ट्रक्ट structAFD_NOTIFYSOCK_DATA है, जो ऊपर वर्णित अज्ञात स्ट्रक्ट है। इसके विभिन्न घटक मुख्य रूप से फ़ंक्शन कॉल श्रृंखला में विभिन्न जाँचों को बायपास करने के लिए हैं।
पहला पैरामीटर, हैंडल का निर्माण अप्रलेखित NT फ़ंक्शन NtCreateIoCompletion के माध्यम से किया जाता है (https://securityintelligence.com/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock/)

डीबगिंग अनुभव पर अपडेट: ऐसा लगता है कि समान दिखने वाला कोड डीबग करते समय अजीब जगहों पर फंस जाता है।
उदाहरण के लिए, शुरू में जब _NtCreateFile को कॉल किया गया तो पहला पैरामीटर hSocket के रूप में पारित किया गया, और मूल फ़ंक्शन में __imp_ObReferenceObjectByHandle लगातार नकारात्मक मान लौटाता रहा। देखने के बाद, _NtCreateFile और _NtDeviceIoControlFile (ये दो फ़ंक्शन मुख्य रूप से afd.sys के साथ इंटरैक्ट करने के लिए हैं, x86matthew के लेख का संदर्भ लें) के मापदंडों के लिए एक नया हैंडल परिभाषित किया गया।
साथ ही, शुरू में NtSetIOCompletion को कॉल नहीं किया गया था, जिसके कारण IORemoveIOCompletion की जाँच विफल हो गई.. इसलिए फिर से https://securityintelligence.com/x-force/patch-tuesday-exploit-wednesday-pwning-windows-ancillary-function-driver-winsock/ की विधि का संदर्भ लिया गया..
फिर शैडो समूह में प्रतीक तालिका लोड न होने की समस्या पर सहायता माँगी गई, और पता चला कि इसका कारण यह था कि Windbg चलाने वाले कंप्यूटर पर प्रॉक्सी चालू नहीं था, जिससे ऑनलाइन प्रतीक तालिका से कनेक्ट नहीं हो पाया।
अंत में, Windbg का उपयोग Hyper-V पर प्रोग्राम को डीबग करने के लिए किया गया, जो Microsoft Learn में वर्णित विधि जितना जटिल नहीं था~ मोटे तौर पर, Hyper-V कमांड लाइन में bcdedit /debug on; bcdedit /dbgsettings net hostip: (होस्ट पर ईथरनेट डिफ़ॉल्ट स्विच का IPv4 पता) port:50001 key:1.2.3.4 दर्ज करें।
उस zip फ़ाइल में पुनरुत्पादन के लिए Visual Studio का पूरा प्रोजेक्ट है।

अंत में, टिंगटिंग दीदी और Windbg की समस्या निवारण में मदद करने वाले मिमी सीनियर का विशेष धन्यवाद~

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