हाईजैक dll ऑपरेशन चेक के लिए एक प्रॉक्सी dll बनाना

जब मैं सॉफ्टवेयर सुरक्षा की जांच करता हूं, तो जांचने के लिए बिंदुओं में से एक गतिशील पुस्तकालयों के साथ काम कर रहा है। हाईजैक DLL ("dll स्पूफिंग" या "dll इंटरसेप्शन") जैसे अटैक बहुत दुर्लभ हैं। सबसे अधिक संभावना है, यह इस तथ्य के कारण है कि विंडोज डेवलपर्स हमलों को रोकने के लिए सुरक्षा तंत्र जोड़ते हैं, और सॉफ्टवेयर डेवलपर्स सुरक्षा के बारे में अधिक सावधान हैं। लेकिन सभी अधिक दिलचस्प स्थिति है जब लक्ष्य सॉफ़्टवेयर असुरक्षित है।

संक्षेप में हमले का वर्णन करते हुए, हाइजैक डीएलएल एक ऐसी स्थिति पैदा कर रहा है जिसमें कुछ निष्पादन योग्य dll को लोड करने की कोशिश करता है, लेकिन हमलावर इस प्रक्रिया में हस्तक्षेप करता है, और अपेक्षित पुस्तकालय के बजाय, विशेष रूप से तैयार किए गए dll को हमलावर से पेलोड के साथ लोड किया जाता है। नतीजतन, dll से कोड लॉन्च किए गए एप्लिकेशन के अधिकारों के साथ निष्पादित किया जाएगा, इसलिए आमतौर पर उच्च अधिकारों वाले एप्लिकेशन को लक्ष्य के रूप में चुना जाता है।

लाइब्रेरी को सही तरीके से लोड करने के लिए, कई शर्तों को पूरा करना चाहिए: निष्पादन योग्य फ़ाइल का थोड़ा आकार और लाइब्रेरी से मेल खाना चाहिए, और यदि आवेदन शुरू होने पर लाइब्रेरी लोड होती है, तो dll को उन सभी कार्यों को निर्यात करना होगा जो इस एप्लिकेशन को आयात करने की उम्मीद है। अक्सर, एक आयात पर्याप्त नहीं है - यह बहुत ही वांछनीय है कि आवेदन dll को लोड करने के बाद अपना काम जारी रखे। इसके लिए यह आवश्यक है कि तैयार पुस्तकालय के कार्य मूल के समान हों। ऐसा करने का सबसे आसान तरीका यह है कि फ़ंक्शन को केवल एक लाइब्रेरी से दूसरी लाइब्रेरी में भेजा जाए। ये dll हैं जिन्हें प्रॉक्सी dll कहा जाता है।



कटौती के तहत इस तरह के पुस्तकालयों के निर्माण के लिए कई विकल्प होंगे - दोनों कोड और उपयोगिताओं के रूप में।

एक छोटी सैद्धांतिक समीक्षा

लाइब्रेरीज़ को लोड लोड फ़ंक्शन का उपयोग करके अधिक बार लोड किया जाता है, जिसमें लाइब्रेरी का नाम पारित होता है। यदि नाम के बजाय आप पूरा रास्ता पास करते हैं, तो आवेदन निर्दिष्ट पुस्तकालय को लोड करने का प्रयास करेगा। उदाहरण के लिए, LoadLibrary ("C: \ Windows \ system32 \ version.dll") को कॉल करने से निर्दिष्ट dll लोड हो जाएगा। या, यदि लायब्रेरी मौजूद नहीं है, तो उसे लोड नहीं किया जाएगा।


यदि आप LoadLibrary ("version.dll") लिखते हैं तो यह काफी दूसरी बात है। एक सामान्य स्थिति में, परिणाम पिछले मामले की तरह ही होगा - C: \ Windows \ system32 \ version.dll लोड होगा, लेकिन इतना सरल नहीं।

सबसे पहले, एक पुस्तकालय खोजा जाएगा, जो निम्नलिखित क्रम में जाएगा :

1. निष्पादन योग्य फ़ोल्डर
2. फ़ोल्डर C: \ Windows \ System32
3. फ़ोल्डर C: \ Windows \ System
4. फ़ोल्डर C: \ Windows
5. फ़ोल्डर अनुप्रयोग के लिए वर्तमान के रूप में सेट है
6. पथ पर्यावरण चर से फ़ोल्डर

जब आप exe फ़ाइल चलाते हैं, तो OS फ़ाइल आयात अनुभाग से सभी पुस्तकालयों को लोड करता है। एक सामान्य अर्थ में, हम यह मान सकते हैं कि OS सभी लाइब्रेरी नामों को लोड करने के लिए फाइल को मजबूर करता है, जो कि आयात अनुभाग में लिखे गए सभी पुस्तकालय नामों को पारित करते हैं। चूंकि 99.9% मामलों में नाम और पथ नहीं हैं, जब आवेदन शुरू होता है, तो सिस्टम में सभी लोड किए गए पुस्तकालयों की खोज की जाएगी।

Dll खोज स्थानों की सूची से, दो बिंदु वास्तव में हमारे लिए महत्वपूर्ण हैं - 1 और 6. यदि हम उसी फ़ोल्डर में version.dll डालते हैं जहां से फ़ाइल लॉन्च की गई है, तो सिस्टम के बजाय एक लोडेड लोड किया जाएगा। यह स्थिति लगभग कभी भी सामना नहीं की गई है, क्योंकि यदि कोई पुस्तकालय लगाने का अवसर है, तो, सबसे अधिक संभावना है, निष्पादन फ़ाइल को बदलना संभव है। लेकिन फिर भी, ऐसी परिस्थितियां संभव हैं। उदाहरण के लिए, यदि निष्पादन योग्य फ़ाइल एक लिखने योग्य फ़ोल्डर में स्थित है और एक ऑटो स्टार्ट के साथ एक सेवा है, तो इसे तब नहीं बदला जा सकता है जब सेवा स्वयं चल रही हो। या लॉन्च की गई फ़ाइल शुरू होने से पहले चेकसम द्वारा बाहरी रूप से जाँच की जाती है, फिर फ़ाइल को बदलना अभी भी एक विकल्प नहीं है। लेकिन लाइब्रेरी को बगल में रखना काफी वास्तविक होगा।

आप निष्पादन योग्य फ़ाइलों के बगल में फ़ाइलों को बनाने में सक्षम नहीं हो सकते हैं, लेकिन आप फ़ोल्डर्स बना सकते हैं। इस स्थिति में, WinSxS पुनर्निर्देशित तंत्र (उर्फ "DotLocal") काम कर सकता है।


लेकिन यह नियम से अधिक अपवाद है। लेकिन जब डीएल खोज सूची में 6 वें नंबर पर पहुंचती है तो परिस्थितियां काफी वास्तविक होती हैं। यदि एप्लिकेशन एक dll को लोड करने की कोशिश करता है जो सिस्टम पर या फ़ाइल के बगल में नहीं है, तो सभी खोजें 6 अंक तक जाएंगी, जो संभावित रूप से लिखने योग्य फ़ोल्डर हो सकती हैं।

उदाहरण के लिए, एक सामान्य पायथन इंस्टॉलेशन सबसे अधिक बार C: \ Python (या नज़दीकी) फ़ोल्डर में होता है। अजगर इंस्टॉलर खुद ही अपने फ़ोल्डर्स को PATH सिस्टम वैरिएबल में जोड़ने का सुझाव देता है। नतीजतन, हमारे पास एक हमले शुरू करने के लिए एक अच्छा स्प्रिंगबोर्ड है - फ़ोल्डर सभी उपयोगकर्ताओं द्वारा लिखने योग्य है और एक नीरव पुस्तकालय को लोड करने का कोई भी प्रयास पीएटीएच से पथ खोज पर जाएगा।

अब जब सिद्धांत पूरा हो गया है, तो पेलोड के निर्माण पर विचार करें - प्रॉक्सी लाइब्रेरी खुद।

पहला विकल्प। ईमानदार प्रॉक्सी पुस्तकालय

आइए अपेक्षाकृत सरल से शुरू करें - हम एक ईमानदार प्रॉक्सी लाइब्रेरी बनाएंगे। इस मामले में ईमानदारी का अर्थ है कि dll में सभी फ़ंक्शन स्पष्ट रूप से पंजीकृत होंगे, और प्रत्येक फ़ंक्शन के लिए मूल लाइब्रेरी से एक ही नाम वाला फ़ंक्शन कॉल लिखा जाएगा। इस तरह के पुस्तकालय के साथ काम करना पूरी तरह से तथाकथित कोड के लिए पारदर्शी होगा: यदि यह किसी फ़ंक्शन को कॉल करता है, तो उसे सही उत्तर, परिणाम, और सब कुछ होगा जो कंधे से कंधा मिलाकर होना चाहिए।

यहाँ version.dll लाइब्रेरी के तैयार उदाहरण ( github ) का लिंक दिया गया है।

कोड हाइलाइट्स:

• मूल पुस्तकालय के निर्यात तालिका से सभी फ़ंक्शन प्रोटोटाइप का ईमानदारी से वर्णन किया गया है।
• मूल पुस्तकालय लोड किया गया है और हमारे कार्यों के लिए सभी कॉल इसमें फेंक दिए गए हैं।

आसानी से , एप्लिकेशन किसी भी "विशेष प्रभाव" का अनुभव किए बिना, सही ढंग से काम करना जारी रखता है। यह असुविधाजनक है कि मुझे प्रत्येक फ़ंक्शन के लिए समान कोड का एक गुच्छा लिखना था, और प्रोटोटाइप के संयोग की सावधानीपूर्वक जांच करना था।

दूसरा विकल्प। कोड लेखन को सरल बनाएं

जब एक पुस्तकालय के साथ व्यवहार किया जाता है जैसे कि version.dll, जहां आयात तालिका छोटी है, केवल 17 फ़ंक्शन हैं, और प्रोटोटाइप सरल हैं, तो एक ईमानदार प्रॉक्सी लाइब्रेरी एक अच्छा विकल्प है।



लेकिन अगर लाइब्रेरी के लिए प्रॉक्सी, उदाहरण के लिए, bcrypt, तो सब कुछ अधिक जटिल है। यहाँ उसकी आयात तालिका है:



57 सुविधाएँ! और यहाँ प्रोटोटाइप के कुछ उदाहरण हैं:




आइए बस यह कहें कि कुछ भी असंभव नहीं है, लेकिन इस तरह के पुस्तकालय के लिए एक ईमानदार प्रॉक्सी बनाना बहुत सुखद नहीं है।

यदि आप कार्यों के साथ थोड़ा धोखा देते हैं तो आप कोड को सरल बना सकते हैं। हम पुस्तकालय में सभी कार्यों को __declspec (नग्न) के रूप में घोषित करेंगे, और शरीर में हम कोडांतरक कोड का उपयोग करेंगे जो मूल पुस्तकालय से केवल फ़ंक्शन पर jmp बनाता है। यह हमें लंबे प्रोटोटाइप का उपयोग करने की अनुमति नहीं देगा, लेकिन बिना मापदंडों के हर जगह सरल घोषणाएं करने के लिए:

शून्य फू ()

जब एप्लिकेशन हमारे फ़ंक्शन को कॉल करता है, तो प्रॉक्सी लाइब्रेरी रजिस्टर और स्टैक के साथ कोई हेरफेर नहीं करेगी, जिससे मूल फ़ंक्शन को सभी काम करने की अनुमति मिल सके।

इस दृष्टिकोण के साथ version.dll लाइब्रेरी का एक उदाहरण ( github )।

मुख्य विशेषताएं:

• मूल लाइब्रेरी भरी हुई है, और हमारे कार्यों के लिए सभी कॉल इसमें फेंक दिए गए हैं। फंक्शन बॉडी और लोडिंग मैक्रोज़ में लिपटे हुए हैं।

आवेदन के सुविधाजनक और सही संचालन और इस तथ्य को भी कि बड़ी संख्या में फ़ंक्शन आसानी से वर्णित हैं, मैक्रोज़ के लिए धन्यवाद। यह असुविधाजनक है कि x64 में बल्कि अप्रत्याशित रेक है। दृश्य स्टूडियो (2012 के बाद से, अगर मुझे सही ढंग से याद है तो) 64-बिट कोड में नग्न और एएसएम आवेषण का उपयोग करने से मना करते हैं। स्क्रैच से एक प्रॉक्सी लिखते समय, प्रत्येक फ़ंक्शन को यह सत्यापित करने के लिए आवश्यक है कि यह डीफ़-फ़ाइल में वर्णित है, कि मूल लोड किया गया है, और फ़ंक्शन का शरीर वर्णित है।

तीसरा विकल्प। हम शरीर को सामान्य रूप से बाहर निकालते हैं

नग्न का उपयोग करना एक और विकल्प बताता है। आप एक आयात तालिका बना सकते हैं, जो सभी कार्यों के लिए कोड की एक वास्तविक पंक्ति को संदर्भित करेगी:

शून्य शून्य () {}

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

जीथुब पर एक उदाहरण, फिर से version.dll के लिए।

कोड हाइलाइट्स:

• डिफ फ़ाइल से सभी फ़ंक्शन एक एनओपी फ़ंक्शन को संदर्भित करते हैं।

आसानी से इस तरह के एक प्रॉक्सी पुस्तकालय सिर्फ कुछ मिनट के लिए लिखा है। यह असुविधाजनक है कि बुलाया अनुप्रयोग काम करना बंद कर देता है।

चौथा विकल्प। तैयार उपयोगिताओं ले लो

एक dll लिखना अच्छा है, लेकिन हमेशा सुविधाजनक नहीं है और बहुत तेज़ नहीं है, इसलिए आपको स्वचालित विकल्पों पर विचार करना चाहिए।

आप पुराने वायरस के पथ का अनुसरण कर सकते हैं - उस लाइब्रेरी को लें, जिसकी समीपता हम बनाना चाहते हैं, उसमें एक निष्पादन योग्य अनुभाग बनाएं, वहां पेलोड लिखें और इस खंड में प्रवेश बिंदु बदलें। सबसे आसान तरीका नहीं है, क्योंकि आप गलती से कुछ तोड़ सकते हैं, आपको कोडांतरक में लिखना होगा, पीई फ़ाइल के उपकरण को याद रखना होगा। यह हमारा तरीका नहीं है।

Dll hijack को संचालित करने के लिए हम एक और dll hijack जोड़ेंगे।



यह करना अपेक्षाकृत आसान है। हम उस लाइब्रेरी की प्रतिलिपि बनाते हैं जिसका प्रॉक्सी हम बनाना चाहते हैं और इस प्रतिलिपि के आयात तालिका में एक मनमानी फ़ंक्शन के साथ कुछ dll जोड़ना चाहते हैं। अब डाउनलोड श्रृंखला के साथ जाएगा - निष्पादन योग्य फ़ाइल की शुरुआत में प्रॉक्सी डीएल लोड किया जाएगा, जो कि निर्दिष्ट लाइब्रेरी को स्वयं लोड करेगा।

“अरे, आपने एक पुस्तकालय को दूसरे के साथ लोड करने की जगह ले ली है। क्या कहना है? सभी एक ही यह dll कोड करने के लिए आवश्यक होगा! "। सब कुछ सही है, लेकिन अभी भी एक समझ है। पेलोड वाले पुस्तकालय के लिए अब कम आवश्यकताएं होंगी। आप किसी भी नाम को निर्दिष्ट कर सकते हैं, मुख्य बात केवल एक फ़ंक्शन को निर्यात करना है, जिसमें कोई भी प्रोटोटाइप हो सकता है। लाइब्रेरी का मुख्य नाम और आयात तालिका में कार्य करें।

एक पेलोड के साथ एक पुस्तकालय सभी अवसरों के लिए एक हो सकता है।

आप कई पीई संपादकों के साथ आयात तालिका को संशोधित कर सकते हैं, उदाहरण के लिए सीएफएफ एक्सप्लोरर या पे-भालू। अपने लिए, मैंने C # में एक छोटी सी उपयोगिता लिखी जो अनावश्यक इशारों के बिना एक तालिका को सही करती है। रिलीज सेक्शन में जीथब, बिनार पर सूत्र।

निष्कर्ष

लेख में, मैंने प्रॉक्सी डीएल बनाने के लिए बुनियादी तरीकों का खुलासा करने की कोशिश की, जिसका मैंने खुद इस्तेमाल किया। यह केवल बचाव करने के लिए बताने के लिए बनी हुई है।

कई सार्वभौमिक सिफारिशें नहीं हैं:

• निष्पादन योग्य फ़ाइलों को संग्रहीत न करें, विशेष रूप से उन उपयोगकर्ताओं के लिए उपयुक्त फ़ोल्डर में उच्च अनुमतियों के साथ चलते हैं।
• LoadLibrary करने से पहले लाइब्रेरी के अस्तित्व को पहले खोजना और सत्यापित करना बेहतर है।
• ओएस में उपलब्ध मौजूदा सुरक्षा विधियों को देखें। उदाहरण के लिए, विंडोज 10 में, आप PreferSystem32 ध्वज सेट कर सकते हैं ताकि dll खोज निष्पादन योग्य फ़ाइल फ़ोल्डर से शुरू न हो, लेकिन सिस्टम 32 के साथ।

आपका ध्यान देने के लिए धन्यवाद, मुझे सवाल, सुझाव, सुझाव और टिप्पणी सुनने में खुशी होगी।

UPD: टिप्पणीकारों की सलाह पर, मैं आपको याद दिलाता हूं कि आपको सावधानीपूर्वक और सावधानीपूर्वक एक पुस्तकालय चुनने की आवश्यकता है। यदि लाइब्रेरी को KnownDlls सूची में शामिल किया गया है या नाम MinWin (ApiSetSchema, api-ms-win-core-कंसोल-l1-1-0.dll - यह सब है) के समान है, तो प्रसंस्करण सुविधाओं के कारण इसे इंटरसेप्ट करना संभव नहीं होगा। ओएस में इस तरह के dlls।