SandboxEscaper / PoC-LPE: अंदर क्या है?

एक हब पर पहले से ही इस भेद्यता के बारे में खबर है , लेकिन, दुर्भाग्य से, तकनीकी विवरण के बिना। मेरा सुझाव है कि आप प्रकाशित संग्रह के अंदर देखें (लेखक - SandboxEscaper )।

कटर के तहत संग्रह में विवरण दस्तावेज़ का अनुवाद है।

भेद्यता विवरण

टास्क शेड्यूलर सेवा में आरपीसी इंटरफ़ेस (एएलपीसी परिवहन के माध्यम से पहुंच योग्य) है जो SchRpcSetSecurity विधि का समर्थन करता है।

यह इस पद्धति का प्रोटोटाइप है:

long _SchRpcSetSecurity( [in][string] wchar_t* arg_1, //Task name [in][string] wchar_t* arg_2, //Security Descriptor string [in]long arg_3); 

कार्य शेड्यूलर द्वारा बनाए गए कार्य c: \ windows \ system32 \ कार्यों में संबंधित निर्देशिका / फ़ाइल बनाते हैं। संभवतः, यह विधि वहां स्थित DACL'a कार्यों को रिकॉर्ड करने के लिए है। लेकिन रिकॉर्डिंग प्रतिरूपण के बाद होगी। हालाँकि, किसी कारण के लिए, विधि का कार्यान्वयन c .job फ़ाइल में c: \ windows \ कार्यों की उपस्थिति के लिए भी जाँच करता है और प्रतिरूपण के बिना इसे DACL लिखता है। चूंकि उपयोगकर्ता (यहां तक ​​कि अतिथि समूह में उपयोगकर्ता) इस निर्देशिका में फ़ाइलें बना सकते हैं, हम बस किसी भी अन्य फ़ाइल को हार्डलिंक बना सकते हैं जिसे हम पढ़ सकते हैं। इस तरह के हार्डलिंक का उपयोग करके, हम शेड्यूलर सेवा (सिस्टम विशेषाधिकारों के साथ निष्पादित) को अपनी पसंद की फ़ाइल में एक मनमाना DACL (दूसरा SchRpcSetSecurity पैरामीटर देखें) लिखने के लिए बाध्य कर सकते हैं।

इस प्रकार: किसी भी फ़ाइल के लिए जिसे पढ़ा जा सकता है, आप डीएसीएल को बदल सकते हैं, जो आपको इसे पूरी तरह से अधिलेखित करने की अनुमति देता है।

भेद्यता का शोषण

यह भेद्यता हमें एक बहुत मजबूत आदिम देता है! मुख्य समस्या यह है कि स्थापना के बाद (डिफ़ॉल्ट रूप से), कई महत्वपूर्ण फाइलें केवल TrustedInstaller उपयोगकर्ता (लेकिन सिस्टम उपयोगकर्ता द्वारा नहीं) द्वारा संशोधित की जा सकती हैं।

संग्रह में फ़ाइलों को सूचीबद्ध करने के लिए एक पॉवरशेल स्क्रिप्ट होती है जिसे आप नियंत्रित कर सकते हैं। बस चलाएं:
./enumerate.ps1 >output.txt

सिस्टम के कई लक्ष्य हैं। आप प्रोग्राम फ़ाइलों को नियंत्रित कर सकते हैं, और यदि आपकी लक्ष्य फ़ाइल का उपयोग किसी व्यवस्थापक / अन्य उपयोगकर्ता द्वारा किया जाता है, तो आपके द्वारा अधिलेखित की गई फाइलें आवश्यक विशेषाधिकारों के साथ लॉन्च की जा सकती हैं।

दूसरी समस्या यह है कि यद्यपि हम कई फाइलों पर नियंत्रण प्राप्त कर सकते हैं, उनके लिए लिखना अक्सर असंभव होता है, क्योंकि ये DLL निष्पादन के लिए पहले से ही लोड होते हैं। निष्पादन के लिए अपलोड की गई फ़ाइल के लिए DACL लिखने का प्रयास करने से साझा पहुंच में त्रुटि होगी। लेकिन भेद्यता का उपयोग अन्य प्रकार की फ़ाइलों के लिए किया जा सकता है, जो एक DLL से बेहतर लक्ष्य हो सकता है।

ऑपरेशन के लिए, फ़ाइल C: \ Windows \ System32 \ DriverStore \ FileRepository \ prnms003.inf_amd64_4592475aca2acf83 \ Amd64 \ printconfig.dll चुना गया था (निर्देशिका नाम भिन्न हो सकता है, यह PoC में ध्यान में रखा गया है)। ऐसा लगता है कि यह फ़ाइल XPS प्रिंटर से संबंधित है और इसे डिफ़ॉल्ट रूप से प्रिंट सेवा में लोड नहीं किया गया है (ऐसा हो सकता है कि फ़ाइल पहले से लोड है ... लेकिन अधिक बार यह नहीं है)।

और जब हम एक्सपीएस प्रिंटर का उपयोग करके प्रिंट कार्य शुरू करते हैं, तो सेवा इस डीएलएल को लोड करेगी, जिसे हम पहले से फिर से लिख सकते हैं। इस तरह के एक हमले वेक्टर (अपहरण) को कुछ बेहतर के लिए आसानी से लागू किया जा सकता है। मैं सबसे अच्छा विकल्प खोजने की कोशिश कर सकता हूं ... बस मुझे बताएं।

नोट : एक पुराने लैपटॉप पर, जहां विंडोज 10 कई वर्षों से चल रहा है, दो निर्देशिकाएं हैं prnms003.inf_amd64_ *। नया संस्करण पुराने को हटाता नहीं है, जिसका अर्थ है कि कोई गारंटी नहीं है कि FindFirstFile (PoC में उपयोग किया गया) वर्तमान निर्देशिका को खोज लेगा। इसलिए, आप सभी पाए गए प्रिंटकॉन्फ़ीडेल को अधिलेखित करके कोड का विस्तार कर सकते हैं या फ़ाइल में पिछले रिकॉर्ड की विशेषता की जांच कर सकते हैं और एक नया चयन कर सकते हैं।

डेमो

आप संग्रह में एक प्रदर्शन के साथ एक वीडियो भी पा सकते हैं: