hahaleyile/my-cve-2021-1675Windows PrintNightmare (CVE-2021-1675/34527) के लिए विस्तृत विश्लेषण और एक्सप्लॉइट कार्यान्वयन, जिसमें दुर्भावनापूर्ण प्रिंटर ड्राइवर स्थापना के माध्यम से RPC-आधारित विशेषाधिकार वृद्धि और दूरस्थ कोड निष्पादन शामिल है।
= Print Nightmare विश्लेषण रिपोर्ट :imagesdir: Figures :toc: :icons: font :figure-caption: चित्र :xrefstyle: short :pdf-theme: basic-theme.yml
29 जून 2021 को, एक अत्यंत गंभीर Windows प्रिंट सेवा भेद्यता को 0day के रूप में उजागर किया गया, भेद्यता का मूल स्कोर 8.8 था, और इसे GitHub पर प्रकाशित किया गया (अब हटा दिया गया)। यह भेद्यता प्रसिद्ध PrintNightmare है: CVE-2021-34527, जो EternalBlue से भी अधिक खतरनाक है।
== भेद्यता की मूल जानकारी
34527 भेद्यता Windows 7, Windows Server 2008 के बाद के लगभग सभी संस्करणों को प्रभावित करती है, विस्तृत जानकारी के लिए <> देखें।
हानि के दृष्टिकोण से, एक हमलावर सामान्य उपयोगकर्ता प्रमाणीकरण का उपयोग करके, प्रशासक अधिकारों के साथ दूरस्थ रूप से मनमाना कोड निष्पादित कर सकता है। शोषण की कठिनाई के संदर्भ में, इस भेद्यता का शोषण करना बहुत आसान है, इसलिए इससे बहुत अधिक नुकसान होता है।
भेद्यता की विशेषताओं से, 34527 भेद्यता CVE-2021-1675 भेद्यता पर आधारित है। जबकि 1675 भेद्यता एक स्थानीय विशेषाधिकार वृद्धि और दूरस्थ कोड निष्पादन भेद्यता है, और इसमें 34527 भेद्यता के साथ बहुत समानताएं हैं।
भेद्यता के कार्य सिद्धांत को समझने से पहले, हमें Windows प्रिंट बैकग्राउंड प्रोसेसर की वास्तुकला की सामान्य समझ होनी चाहिए, ताकि हम भेद्यता में शामिल विभिन्न मॉड्यूल के बीच संबंधों को आसानी से समझ सकें।
== CVE-2021-1675 कॉल प्रक्रिया
=== Windows प्रिंट बैकग्राउंड प्रोसेसर वास्तुकला
spooler वास्तुकला को <<spooler_arch>> द्वारा दर्शाया जा सकता है:
[[spooler_arch]] .Print Spooler Architecture image::Print Spooler Architecture.png[]
विशेष रूप से, बैकग्राउंड प्रिंटर प्रिंट कार्यों का प्रबंधन करता है, और इसमें निम्नलिखित घटक शामिल हैं:
winspool.drv:: उपयोगकर्ता को प्रदान की गई डायनामिक लिंक लाइब्रेरी फ़ाइल। यह फ़ाइल spooler से संबंधित Win32 API को परिभाषित करती है जिसे उपयोगकर्ता कॉल कर सकता है। इसके अंदर के सभी API रिमोट प्रोसीजर कॉल के रूप में सेवा प्राप्त करते हैं।
spoolsv.exe:: spoolsv.exe सिस्टम में सर्वर की भूमिका निभाता है, API कॉल को संसाधित करने वाला पहला प्रोग्राम है। यह डिज़ाइन इसलिए है ताकि print spooler स्थानीय प्रिंट कार्यों के साथ-साथ रिमोट प्रिंट कार्यों को भी समान रूप से संसाधित कर सके।
spoolsv.dll:: रूटिंग प्रोग्राम। यह spoolsv.exe द्वारा प्राप्त प्रिंट अनुरोधों को विभिन्न प्रिंट प्रदाताओं को भेजता है, और यह तय करता है कि कौन सा प्रिंट प्रदाता अंततः अनुरोध को संसाधित करेगा। इसका कार्य प्रिंट कार्य को दूरस्थ या स्थानीय के रूप में अलग करना है। दूरस्थ मशीन पर यह कार्य को स्थानीय प्रिंट प्रदाता को निर्दिष्ट करता है।
localspl.dll:: स्थानीय प्रिंट प्रदाता। प्रिंट प्रदाता का मुख्य कार्य प्रिंट कार्य प्रबंधन की आवश्यकता को हल करना है, और अधिकांश API इस मॉड्यूल के अंदर कार्यान्वित होते हैं।
उपरोक्त सिद्धांत के आधार पर अध्ययन जारी रखते हुए, उदाहरण के लिए, जब मैं AddPrinterDriverEx फ़ंक्शन (CVE-2021-1675) को कॉल करता हूं, तो यह निम्नलिखित प्रक्रिया से गुज़रता है:
=== फ़ंक्शन संस्करण चयन
सबसे पहले, यह फ़ंक्शन वास्तव में एक मैक्रो है, जो स्थानीय संकलन वातावरण के आधार पर Unicode संस्करण (W) या Ansi संस्करण (A) का चयन करता है, जैसा कि <> में दिखाया गया है:
[[AddPrinterDriverEx]] .AddPrinterDriverEx image::AddPrinterDriverEx.png[]
लेकिन चाहे वाइड कैरेक्टर या नैरो कैरेक्टर संस्करण हो, वास्तव में परिणाम में कोई अंतर नहीं है, क्योंकि Windows कर्नेल स्ट्रिंग्स Unicode एन्कोडिंग का उपयोग करती हैं, इसलिए अंततः Ansi संस्करण का कॉल Unicode संस्करण में परिवर्तित हो जाता है, जैसा कि <> में दिखाया गया है:
[[AnsiToUnicode]] .AnsiToUnicode image::AnsiToUnicode.png[]
जब Ansi फ़ंक्शन के पैरामीटर सभी Unicode संस्करण में परिवर्तित हो जाते हैं, तो एक फ़ंक्शन कॉल किया जाता है (<>):
[[AnsiCallUnicode]] .AnsiCallUnicode image::AnsiCallUnicode.png[]
और यह फ़ंक्शन वास्तव में AddPrinterDriverEx का Unicode संस्करण है (<>):
[[GetUnicodeProcAddress]] .GetUnicodeProcAddress image::GetUnicodeProcAddress.png[]
=== API फ़ंक्शन spooler सर्वर पर RPC अनुरोध भेजता है
Unicode संस्करण के फ़ंक्शन के अंदर प्रवेश करने के बाद, सबसे पहले Level के मान के अनुसार फ़ंक्शन पैरामीटर प्रकार का चयन किया जाता है:
image::pDriverInfo.png[]
इस भेद्यता में हम Level को 2 पर सेट करेंगे, अर्थात pDriverInfo पैरामीटर का प्रकार DRIVER_INFO_2 संरचना चुनेंगे। फिर Windows फ़ंक्शन पैरामीटर को संसाधित करेगा, और प्रसंस्करण पूरा होने के बाद, रिमोट प्रोसीजर कॉल के माध्यम से API को संसाधित करना जारी रखेगा:
image::set arguments.png[]
image::NdrClientCall3.png[]
=== MSRPC तंत्र
Microsoft का रिमोट प्रोसीजर कॉल तंत्र DCE मानक पर आधारित है। सरल शब्दों में समझाएं तो, रिमोट प्रोसीजर कॉल रिमोट सिस्टम पर प्रक्रियाएं चलाना है, जो प्रोग्रामर या सिस्टम द्वारा पूर्वनिर्धारित होती हैं।
RPC का विशिष्ट तरीका यह है कि रिमोट से कॉल करने वाले फ़ंक्शन को क्रमबद्ध किया जाता है, नेटवर्क के माध्यम से रिमोट सिस्टम पर प्रेषित किया जाता है, रिमोट सिस्टम इसे विपरीत क्रमबद्ध करता है, और इसे निष्पादित करता है। Microsoft द्वारा बनाई गई प्रणाली में, TCP/IP और SMB को आमतौर पर RPC कॉल को प्रसारित करने के लिए चुने गए प्रोटोकॉल हैं।
MSRPC का उपयोग करने के लिए, पहले कॉल किए जाने वाले फ़ंक्शन का IDL इंटरफ़ेस विवरण परिभाषित करना होगा, और फिर MIDL टूल का उपयोग करके क्लाइंट और सर्वर के लिए संबंधित क्रमबद्धता प्रोग्राम stub उत्पन्न करना होगा। कुछ Win32 API के लिए, उनमें पहले से ही सर्वर stub परिभाषित होता है, इसलिए हम केवल क्लाइंट stub उत्पन्न और उपयोग कर सकते हैं।
MSRPC एक विशिष्ट प्रकार के प्रोटोकॉल की पहचान करने के लिए UUID का उपयोग करता है, जैसे MS-RPRN रिमोट प्रिंट प्रोटोकॉल का वर्णन करता है, और सभी रिमोट प्रिंट से संबंधित फ़ंक्शन इस प्रोटोकॉल का हिस्सा हैं। MSPRC UUID 12345678-1234-ABCD-EF00-0123456789AB का उपयोग करके इस प्रोटोकॉल की पहचान करता है (<<rprn_uuid>>):
[[rprn_uuid]] .MS-RPRN UUID image::spoolss uuid.png[]
इसके बाद, इस कनेक्शन के आधार पर, प्रोटोकॉल के अंदर फ़ंक्शन की पहचान करने के लिए operator number का उपयोग किया जा सकता है, ताकि दूरस्थ रूप से कॉल किया जा सके, उदाहरण के लिए AddPrinterDriverEx स्वयं को 89 से पहचानता है (<<addPrinterDriverEx_opnum>>):
[[addPrinterDriverEx_opnum]] .AddPrinterDriverEx Opnum image::AddPrinterDriverEx Opnum.png[]
MSRPC का उपयोग करते समय, दो बातों पर ध्यान देने योग्य है:
"As you can see in your output, the scripts are trying to connect to port 135 (endpoint mapper) in order to get the TCP/IP port where the DCOM endpoint is listening (that is a dynamic port)." -- SecureAuthCorp/impacket issue #412
=== spoolsv.exe API अनुरोध को संसाधित करता है
[[call_flow]] .RpcAddPrinterDriverEx Call Flow image::Function Calls.png[]
<<call_flow>> से देखा जा सकता है कि spoolsv.exe इन फ़ंक्शनों को कॉल करता है, और फ़ंक्शन के अंदरूनी विश्लेषण से, इस मॉड्यूल में आरंभीकरण के अलावा कोई अन्य कार्य पूरा नहीं होता है। अंत में, यह मॉड्यूल pLocalProvidor द्वारा इंगित फ़ंक्शन को कॉल करता है, अर्थात localspl.dll मॉड्यूल के अंदर फ़ंक्शन LocalAddPrinterDriverEx। localspl एक स्थानीय प्रिंट प्रदाता के रूप में, वास्तव में API कार्यक्षमता को लागू करने वाला मॉड्यूल है।
=== स्थानीय प्रिंट प्रदाता का फ़ंक्शन कार्यान्वयन तर्क
[[LocalAddPrinterDriverEx]] .LocalAddPrinterDriverEx image::LocalAddPrinterDriverEx.png[]
सबसे पहले <> बताता है कि यह मॉड्यूल spooler के सामान्य संचालन को सत्यापित करता है, फिर फ़ंक्शन SplAddPrinterDriverEx पर कूदता है।
[[SplAddPrinterDriverEx]] .SplAddPrinterDriverEx image::SplAddPrinterDriverEx.png[]
<> फ़ंक्शन के अंदर वह महत्वपूर्ण स्थान है जहाँ AddPrinterDriverEx फ़ंक्शन के सफल निष्पादन का निर्णय होता है। पहले भाग को देखने की आवश्यकता नहीं है, क्योंकि WPP एक लॉगिंग से संबंधित तकनीक है, इसे अभी छोड़ दें।
बाद के भाग में, Microsoft ने एक चर v12 परिभाषित किया है, जो एक फ्लैग है जो यह निर्धारित करता है कि फ़ंक्शन निष्पादन जारी रखना है या सीधे बाहर निकलना है।
[[bittest]] .bittest dwFileCopyFlags image::bittest in spl.png[]
<> से देखा जा सकता है कि निरंतर निष्पादन के लिए दो शर्तें हैं: एक है v12 का 0 होना, जो bittest की सफलता को दर्शाता है, और दूसरी है Validate का सफल होना। Validate अनुमतियों की जांच है, और इसे आसानी से बायपास नहीं किया जा सकता है। इसके अंदर एक API OpenProcessToken है, जो इंगित करता है कि अगली प्रक्रिया में विशेषाधिकार बढ़ाने की आवश्यकता है, और यदि आप प्रशासक नहीं हैं तो ऐसा नहीं किया जा सकता है।
इसलिए निरंतर निष्पादन के लिए केवल bittest जांच को बायपास करना होगा, और जिस संख्या की जांच की जा रही है वह a4 है - फ़ंक्शन का चौथा पैरामीटर, जो आधिकारिक वेबसाइट पर वर्णित पैरामीटर <> है:
|=== |नाम/मान |विवरण
|APD_STRICT_UPGRADE
0x00000001
|प्रतिस्थापन प्रिंटर ड्राइवर को केवल तभी जोड़ें जब प्रतिस्थापन ड्राइवर की कोई भी फ़ाइल वर्तमान में स्थापित ड्राइवर की संबंधित फ़ाइलों से पुरानी न हो।
|APD_STRICT_DOWNGRADE
0x00000002
|प्रतिस्थापन प्रिंटर ड्राइवर को केवल तभी जोड़ें जब वर्तमान में स्थापित ड्राइवर की कोई भी फ़ाइल प्रतिस्थापन ड्राइवर की संबंधित फ़ाइलों से पुरानी न हो।
|APD_COPY_ALL_FILES
0x00000004
|प्रिंटर ड्राइवर जोड़ें और ड्राइवर निर्देशिका में सभी फ़ाइलों को कॉपी करें। फ़ाइल टाइमस्टैम्प को अनदेखा किया जाना चाहिए।
|APD_COPY_NEW_FILES
0x00000008
|प्रिंटर ड्राइवर जोड़ें और ड्राइवर निर्देशिका में उन फ़ाइलों को कॉपी करें जो वर्तमान में उपयोग में आने वाली संबंधित फ़ाइलों से नई हैं।
|APD_COPY_FROM_DIRECTORY
0x00000010
|प्रिंटर ड्राइवर को _DRIVER_INFO_6 संरचना में निर्दिष्ट पूर्ण योग्य फ़ाइल नामों का उपयोग करके जोड़ें। यदि यह फ्लैग निर्दिष्ट है, तो इस बिट फील्ड में एक अन्य कॉपी फ्लैग निर्दिष्ट होना चाहिए।
|APD_DONT_COPY_FILES_TO_CLUSTER
0x00001000
|प्रिंट सर्वर क्लस्टर में प्रिंटर ड्राइवर जोड़ते समय, ड्राइवर फ़ाइलों को साझा क्लस्टर डिस्क पर कॉपी न करें।
|APD_COPY_TO_ALL_SPOOLERS
0x00002000
|प्रिंटर ड्राइवर को क्लस्टर spooler सर्वरों पर जोड़ें।
|APD_INSTALL_WARNED_DRIVER
0x00008000
|प्रिंटर ड्राइवर जोड़ें, भले ही वह सर्वर की चेतावनी प्रिंटर ड्राइवर सूची में हो।
|APD_RETURN_BLOCKING_STATUS_CODE
0x00010000
|सर्वर नीति द्वारा प्रिंटर ड्राइवर को स्थापना से अवरुद्ध किए जाने पर वापस करने के लिए कार्यान्वयन-विशिष्ट त्रुटि कोड निर्दिष्ट करता है।
|===
bittest 16 यह सत्यापित करता है कि चर का 16वाँ बिट 1 है या नहीं, संबंधित पैरामीटर मान 0x8000 (APD_INSTALL_WARNED_DRIVER) है। इसकी परिभाषा से भी देखा जा सकता है कि इस पैरामीटर का अर्थ है बिना सत्यापन के प्रिंटर ड्राइवर को सर्वर पर जोड़ना।
कहा जाता है कि 1675 को ठीक करने से पहले, यह पैरामीटर आधिकारिक दस्तावेज़ में मौजूद नहीं था, इससे भेद्यता के स्थान का पता लगाना कठिन नहीं है।
=== भेद्यता का शोषण विधि
जब प्रिंटर ड्राइवर जोड़ने की यह विधि वास्तव में निष्पादित होती है, यदि DRIVER_INFO_2 संरचना चुनी जाती है, तो निम्नलिखित घटनाएँ घटित होंगी:
. क्रमशः DriverFile, ConfigFile और DataFile खोलें, और पुष्टि करें कि ये तीन फ़ाइलें मौजूद हैं। इनमें से केवल DataFile को UNC पथ की अनुमति है।
. यदि तीनों फ़ाइलें मौजूद हैं, तो उन्हें निर्देशिका C:\Windows\System32\spool\drivers\x64\3\New पर कॉपी करें, जैसा कि <<cp_conf_file>> और <<cp_data_file>> में दिखाया गया है: + [[cp_conf_file]] .कॉन्फ़िग फ़ाइल कॉपी करें image::copy config file.png[] + [[cp_data_file]] .डेटा फ़ाइल कॉपी करें image::copy data file.png[]
ifdef::backend-pdf[] दुर्भावनापूर्ण प्रोग्राम के संचालन परिणाम के लिए https://github.com/hahaleyile/my-CVE-2021-1675[मेरा रिपॉजिटरी] देखें, डेमो GIF फाइल Figures निर्देशिका में है। endif::[]
== Microsoft द्वारा 1675 भेद्यता का पैच
8 जून 2021 को, Microsoft ने CVE-2021-1675 भेद्यता के लिए पैच जारी किया, विशिष्ट संशोधन निम्नलिखित हैं:
[[path_1675]] .CVE-2021-1675 पैच image::IsElevated.png[]
[[YIsElevationRequired]] .YIsElevationRequired image::YIsElevationRequired.png[]
[[YIsElevated]] .YIsElevated image::YIsElevated.png[]
[[unset_1675]] .APD_INSTALL_WARNED_DRIVER अनसेट करें image::JudgeIsElevated.png[]
Microsoft ने RpcAddPrinterDriverEx फ़ंक्शन में उपयोगकर्ता विशेषाधिकार वृद्धि की जांच जोड़ दी, और उपयोगकर्ता रजिस्ट्री में इस प्रतिबंध को हटा सकता है (<<path_1675>>)। उपयोगकर्ता को केवल रजिस्ट्री के निर्दिष्ट स्थान पर NoWaringNoElevationOnInstall नामक एक कुंजी बनानी होगी (<>), या RPC खाता TOKEN_QUERY प्रक्रिया टोकन प्राप्त कर सकता है (<>), ताकि इस पैच को बायपास किया जा सके। यदि पैच प्रभावी होता है, तो dwFileCopyFlags पैरामीटर का 16वाँ बिट AND ऑपरेशन द्वारा 0 पर सेट हो जाएगा, अर्थात APD_INSTALL_WARNED_DRIVER पैरामीटर मान अमान्य हो जाएगा (<<unset_1675>>)।
== 1675 पैच का बायपास
हालाँकि Microsoft ने RpcAddPrinterDriverEx फ़ंक्शन पर पैच लगाया, फिर भी हम RpcAsyncAddPrinterDriver के माध्यम से दूरस्थ कॉल करके बायपास कर सकते हैं। जैसा कि <<async_send>> में दिखाया गया है, क्लाइंट का यह फ़ंक्शन सीधे सर्वर को दूरस्थ कॉल करता है:
[[async_send]] .RpcAsyncAddPrinterDriver भेजें image::RpcAsyncAddPrinterDriver Send.png[]
सर्वर पहले थ्रेड के लिए स्थान आवंटित करता है, फिर कॉल करना जारी रखता है, जैसा कि <<async_receive>> में दिखाया गया है:
[[async_receive]] .RpcAsyncAddPrinterDriver प्राप्त करें image::RpcAsyncAddPrinterDriver Receive.png[]
जारी किए गए फ़ंक्शन में सभी पैरामीटर स्टैक पर धकेल दिए जाते हैं, और YAddPrinterDriverEx को थ्रेड के रूप में चलाया जाता है (<<async_yadd>>):
[[async_yadd]] .थ्रेड प्रारंभ YAddPrinterDriverEx image::thread start YAddPrinterDriverEx.png[]
इस प्रकार Microsoft के RpcAddPrinterDriverEx पैच को सफलतापूर्वक बायपास किया जाता है।
अर्थात, RpcAsyncAddPrinterDriver फ़ंक्शन को दूरस्थ रूप से कॉल करके, प्रशासक के रूप में मनमाना कोड निष्पादित करना जारी रखा जा सकता है।
इसके अलावा, <> के अनुसार, इस पैच में टोकन जाँच में अभी भी समस्या है, और जिन मशीनों पर UAC पूरी तरह से अक्षम है, वहां यह पैच अप्रभावी होगा। हालाँकि, मैं स्वयं इस तंत्र के बारे में अधिक नहीं जानता, इसलिए अधिक टिप्पणी नहीं करूंगा।
== Microsoft द्वारा 34527 भेद्यता का सुधार
6 जुलाई 2021 को, Microsoft ने एक नए पैच के माध्यम से इस प्रिंट बैकग्राउंड भेद्यता को अस्थायी रूप से हल किया।
आधिकारिक बयान के अनुसार, यह पैच प्रिंट सर्वर पर प्रिंटर ड्राइवर स्थापित करने की अनुमति केवल प्रशासकों को देगा। इसके अलावा, Microsoft ने उपयोगकर्ताओं को इस नीति को अनुकूलित करने के लिए एक समूह नीति और दो रजिस्ट्री कुंजियाँ जोड़ीं।
. इस निर्देशिका में कॉपी करने का कारण संबंधित फ़ाइलों को निष्पादित करना है, 3 इंगित करता है कि यह प्रिंटर ड्राइवर v3 प्रकार का है। पहले नई फ़ाइलों को New निर्देशिका में कॉपी करें, ताकि 3 निर्देशिका के अंतर्गत फ़ाइलों को अधिलेखित होने से रोका जा सके। यदि 3 के अंतर्गत समान नाम वाली फ़ाइलें हैं, तो उन्हें Old निर्देशिका में बैकअप के रूप में रखें, और फिर New निर्देशिका के अंतर्गत फ़ाइलों को 3 में कॉपी करके अधिलेखित करें। इसे हम RpcAddPrinterDriverEx विधि के दूसरे निष्पादन के समय देख सकते हैं: + .दूसरी बार RPC कॉल image::second time call.png[] + .बैकअप फ़ाइलें पुरानी निर्देशिका में image::backup file.png[] + .नई फ़ाइलों को गंतव्य पर कॉपी करें image::copy file.png[] + इस तंत्र के अनुसार, हम दूरस्थ पथ की फ़ाइल को स्थानीय पथ की फ़ाइल के रूप में सहेज सकते हैं, क्योंकि फ़ंक्शन पैरामीटर में ड्राइवर फ़ाइल और कॉन्फ़िगरेशन फ़ाइल पैरामीटर केवल स्थानीय पथ हो सकते हैं, केवल डेटा फ़ाइल पैरामीटर दूरस्थ पथ हो सकता है।
. <> के अनुसार, pConfigFile उपकरण ड्राइवर का कॉन्फ़िगरेशन डायनेमिक लिंक लाइब्रेरी है, इसलिए इसे आरंभ करने के लिए एक बार लोड करना होता है। यह वास्तविक संचालन से भी सिद्ध हो गया है। + .pConfigFile लोड करें image::Load Image.png[] + इस प्रकार, जब तक एक दुर्भावनापूर्ण dll लिखा जाता है, और दुर्भावनापूर्ण कोड को dll प्रवेश बिंदु पर निष्पादित किया जाता है, तब तक मनमाना कोड निष्पादित किया जा सकता है, और वह भी प्रशासक अधिकारों के साथ। + .spoolsv.exe प्रशासक अधिकारों के अंतर्गत है image::spoolsv user.png[]
. CreateInternalDriverFileArray() फ़ंक्शन फ़ाइल ऑपरेशन फ्लैग के आधार पर यह तय करता है कि spool ड्राइवर निर्देशिका की जाँच करनी है या नहीं। यदि a5 फ्लैग को False सेट किया गया है, तो ड्राइवर लोडिंग फ़ंक्शन केवल उपयोगकर्ता निर्देशिका में जाँच करेगा कि क्या कॉपी की जाने वाली ड्राइवर फ़ाइलें मौजूद हैं। अन्यथा, फ़ंक्शन spool ड्राइवर निर्देशिका में लक्ष्य ड्राइवर की खोज करने का प्रयास करेगा। इसके लिए आवश्यक है कि dwFileCopyFlags में APD_COPY_FROM_DIRECTORY पैरामीटर भी सेट हो। + image::APD.png[] + image::APD_1.png[]
== शोषण प्रोग्राम का उपयोग करने की विधि
यह प्रोग्राम Docker पर आधारित है, जो पर्यावरण निर्भरता समस्याओं को प्रभावी ढंग से हल कर सकता है।
सबसे पहले, उपयोगकर्ता compose फ़ाइल को अपनी निर्देशिका में डाउनलोड करता है, फिर उस निर्देशिका में एक share नामक फ़ोल्डर बनाता है जो माउंट निर्देशिका के रूप में काम करेगा। उपयोगकर्ता दुर्भावनापूर्ण प्रोग्राम को share फ़ोल्डर में रख सकता है, और यह फ़ोल्डर samba पथ smb के रूप में साझा किया जाएगा।
फिर, उपयोगकर्ता टर्मिनल में कमांड दर्ज करता है:
इससे क्लस्टर (एक कंटेनर) शुरू हो जाएगा। उपयोगकर्ता स्वयं कंटेनर में प्रवेश कर सकता है और कार्य कर सकता है, कंटेनर में सभी वातावरण पहले से कॉन्फ़िगर किए गए हैं।
या सीधे टर्मिनल में कमांड दर्ज करें:
कमांड निष्पादित करने के लिए।
== शोषण प्रोग्राम का संचालन परिणाम
<> द्वारा ओपन-सोर्स कोड के लिए धन्यवाद, जिसका मैंने संदर्भ लिया!
ifndef::backend-pdf[] .प्रोग्राम संचालन परिणाम image::exploit.gif[] endif::[]
<<restrict_async>> के ida डीकंपाइलेशन के माध्यम से हम देख सकते हैं कि Microsoft ने Async फ़ंक्शन में टोकन और रजिस्ट्री आइटम का सत्यापन जोड़ा है।
[[restrict_async]] .async फ़ंक्शन में प्रतिबंध image::restrict in async.png[]
<<restrict_rpcadd>> से हम देख सकते हैं कि Microsoft ने RpcAddPrinterDriverEx फ़ंक्शन में उपयोगकर्ता समूह और इसकी रजिस्ट्री कुंजियों का सत्यापन जोड़ा है।
[[restrict_rpcadd]] .RpcAddPrinterDriverEx फ़ंक्शन में प्रतिबंध image::restrict in rpcadd.png[]
इसलिए, संभवतः 1675 भेद्यता के सुधार में वास्तव में टोकन सत्यापन की समस्या थी।
== परियोजना योजना
. RpcAsyncAddPrinterDriver दूरस्थ कॉल के लिए समर्थन जोड़ना, ताकि Microsoft के 8 जून के पैच को बायपास करके CVE-2021-34527 exp प्राप्त किया जा सके।
. UAC तंत्र को समझना, और इस भेद्यता विश्लेषण को पूर्ण करना।
[bibliography] == संदर्भ
[[[a,आधिकारिक वेबसाइट]]] विंडोज प्रिंट स्पूलर रिमोट कोड एग्ज़ीक्यूशन भेद्यता https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-34527
[[[b,dwFileCopyFlags]]] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-rprn/b96cc497-59e5-4510-ab04-5484993b259b
[[[c,विंडोज प्रिंट नाइटमेयर भेद्यता (CVE-2021-34527) और पैच विश्लेषण]]] https://www.freebuf.com/vuls/279876.html
[[[d,gentilkiwi/mimikatz]]] https://github.com/gentilkiwi/mimikatz
[[[e,आधिकारिक दस्तावेज़]]] DRIVER_INFO_2 संरचना https://docs.microsoft.com/en-us/windows/win32/printdocs/driver-info-2
[[[f,cube0x0]]] https://github.com/cube0x0
[[[g,James Forshaw]]] https://twitter.com/tiraniddo/status/1410726790994169857
[[[h,आधिकारिक बयान]]] KB5005010: 6 जुलाई, 2021 अपडेट लागू करने के बाद नए प्रिंटर ड्राइवरों की स्थापना को प्रतिबंधित करना https://support.microsoft.com/en-us/topic/kb5005010-restricting-installation-of-new-printer-drivers-after-applying-the-july-6-2021-updates-31b91c02-05bc-4ada-a7ea-183b129578a7
