युद्धक्षेत्र - हाइपरवाइजर

हैकर प्रतियोगिता के इंट्राम्यूरल राउंड के एक कार्य में निक्वेस्ट -2016 में, खोज के प्रतिभागियों को एक दुर्जेय प्रतिद्वंद्वी - एक हाइपरवाइजर द्वारा सामना किया गया था! जेल से भागने के लिए, उन्हें केवल प्रक्रिया की स्मृति से एक पंक्ति पढ़ने की आवश्यकता थी। लेकिन वहाँ कुछ BUT थे ... हाइपरविजर ने हमारे प्रतिद्वंद्वियों के लिए हर तरह से जीवन को कठिन बना दिया, अर्थात्:
• पते की जगह को नियंत्रित करते हुए, प्रक्रिया मेमोरी को पढ़ने से रोका गया
• एक विरोधी डिबगर के रूप में काम किया
• प्रक्रिया छवि की अखंडता की जाँच की, अपने खंड के हैश की गणना
• प्रोग्राम को कंप्यूटर आदि से बांधें।

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

यह सब कैसे शुरू हुआ

नियोक्वेस्ट -2016 के इन-पर्सन टूर के प्रतिभागियों - नियोक्वेस्ट के फरवरी ऑनलाइन टूर के विजेताओं के पास जीतने के लिए एक शक्तिशाली प्रोत्साहन था। जेल की ठंडी और नम दीवारों से बाहर निकलने के लिए उन्हें पूरी तरह से बिजली की कुर्सी पर ले जाने से बचने की ज़रूरत थी! जेल, बेशक, आभासी था, लेकिन कुर्सी असली थी!



प्रतियोगियों को "भागने" के लिए 8 घंटे दिए गए थे, और उम्मीद है कि प्रत्येक कार्य को पूरा करने में लगभग 2 घंटे लगेंगे, हमने 5 कार्य तैयार किए (एक आरक्षित है!), लेकिन यह पता चला कि हमने सोचा कि कोई भी पारित नहीं हुआ, इसलिए वह चार कार्य पर्याप्त थे)।
नियोक्वेस्ट 2013 के कार्यों में सूचना सुरक्षा के दोनों सामान्य क्षेत्रों - क्रिप्टोग्राफी, क्लाउड और वेब टेक्नोलॉजीज, बॉटनेट्स, और साथ ही साथ गैर-मानक उपकरणों और प्रौद्योगिकियों (हाइपरवाइज़र, स्मार्ट कार्ड, आदि) की सुरक्षा का संबंध था, जिन्हें प्रोग्रामिंग की भी आवश्यकता थी। "बेयर" लोहा, विशेष रूप से, अरुडिनो एसडीके नियंत्रक। खोज के विजेता - एविक्टर, जो हाल ही में आरएसए सम्मेलन से एम्स्टर्डम से लौटे थे, यात्रा जो कि नियोक्वेस्ट 2013 के इन-पर्सन टूर का मुख्य पुरस्कार थी, ने प्रत्येक कार्य के बारे में थोड़ा लिखा था ! दूसरा स्थान v0s (व्लाद रोसकोव ) के पास गया, जिसने कैटरपिलर से कैट संरक्षित बी 15 स्मार्टफोन को प्राप्त किया ।

और अब हाइपरविजर के बारे में!

केवल v0s हाइपरविजर को बायपास करने में कामयाब रहे। कार्य निम्नानुसार तैयार किया गया था: दो समान विंडोज कंप्यूटर उपलब्ध हैं, जिस पर KeyReader.exe निष्पादन योग्य फ़ाइल मौजूद है। इनपुट पर, वह प्रतिभागी की आईडी प्राप्त करता है, और फिर "कुंजी सफलतापूर्वक पढ़ी जाती है।" बाहर निकलने के लिए किसी भी कुंजी को दबाएं। ” डिफ़ॉल्ट रूप से, प्रतिभागी व्यवस्थापक अधिकारों वाले खाते के अंतर्गत काम करते हैं। एक कुंजी प्राप्त करना आवश्यक है।



इन दो को छोड़कर किसी भी अन्य मशीनों पर शुरू करते समय, KeyReader.exe एक त्रुटि की रिपोर्ट करता है:



प्रतिभागियों के स्थान पर खुद की कल्पना करें और सच्चाई को पाने की कोशिश करें! संदेश को देखते हुए, कुंजी प्रक्रिया मेमोरी में है, और हमें इसे वहां से पढ़ने की आवश्यकता है। यह आसान लगता है, इसे करने की कोशिश करें। विंडोज टास्क मैनेजर चलाएं, KeyReader.exe प्रक्रिया ढूंढें, इसे कीस्ट्रोके के इंतजार में डंप करें, और डंप को रोसिनोविच के तारों को खिलाएं। डंप का वजन 3.3MB है, और उपयोगिता 55,000 लाइनें ढूंढती है। यह बहुत स्पष्ट नहीं है कि उनके बीच एक कुंजी की खोज कैसे करें, लेकिन यदि आप शब्द कुंजी द्वारा खोजते हैं, तो आपको निम्नलिखित पंक्ति मिलेगी:



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



पृष्ठ-संरेखित मेमोरी आवंटित की जाती है, शून्य की जाती है, फिर प्रतिभागी की आईडी पढ़ी जाती है और AcquireKey फ़ंक्शन को कहा जाता है । AcquireKey फ़ंक्शन छोटा है, और इसमें निम्न कोड शामिल हैं, जो एक कोडांतरक सम्मिलित करता था:



इस कोड में vmcall निर्देश है, जो रजिस्टरों के माध्यम से पारित मापदंडों के साथ हाइपरवाइजर को कॉल करता है। EAX रजिस्टर में 'NeoQ' मान होता है, EDX रजिस्टर में 'strt' मान होता है, EBX रजिस्टर में पहले से आवंटित मेमोरी पेज का एक पॉइंटर होता है, ECX रजिस्टर में पेज का आकार होता है, और EDI रजिस्टर में प्रतिभागी आईडी होता है। कॉल का परिणाम ईएसआई रजिस्टर के माध्यम से लौटाया जाता है। सादगी के लिए, हम मान सकते हैं कि vmcall निर्देश हाइपरवाइजर पर नियंत्रण स्थानांतरित करता है यदि हाइपरवाइजर मौजूद है या ऐसा नहीं होने पर #UD को कॉल करता है।

निर्देश के ऑपरेशन एल्गोरिदम का पूरा विवरण इंटेल से 64-ia-32-आर्किटेक्चर-सॉफ्टवेयर-डेवलपर-वॉल्यूम -2 बी-मैनुअल में पाया जा सकता है। अब यह स्पष्ट है कि कुंजी हाइपरविजर में संग्रहीत है और प्रोग्राम मेमोरी में कॉपी की जाती है जब इसे कुछ मापदंडों के साथ vmcall निर्देश का उपयोग करके एक्सेस किया जाता है।

आइए कार्यक्रम के चरणों को डीबग करने का प्रयास करें और देखें कि हाइपरविजर तक पहुंचने के बाद मेमोरी में क्या होगा। हम OllyDbg 2.01 का उपयोग डिबगर के रूप में करेंगे। डिबगिंग के तहत KeyReader.exe चलाएँ, vmcall के बाद अगले स्टेटमेंट पर ब्रेकपॉइंट सेट करें। प्रतिभागी आईडी दर्ज करें, Enter दबाएं, और स्थापित ब्रेकपॉइंट में प्रवेश करें। EBX रजिस्टर में 0x1F5000 का पता होता है, लेकिन शून्य उस पर स्थित होता है। ईएसआई भी 0 है।



F9 दबाएं और देखें कि कोई त्रुटि हुई है।



तीन डिबगिंग तंत्र हैं:
• कोड टूलकिट int3 निर्देश
प्रत्येक निर्देश के बाद रुकावट int1 के साथ कदम दर कदम डिबगिंग
• डीबग डी0-डी 7 को पंजीकृत करता है, जो आपको मेमोरी एक्सेस को पकड़ने की अनुमति देता है
हमारे मामले में, निर्देश पर ब्रेकपॉइंट स्थापित करते समय, हम 0xcc (int 0x3) के साथ निर्देश के पहले बाइट को ओवरराइट करते हैं। जब प्रोग्राम इस स्थान पर पहुंचता है, तो int3 निष्पादित होता है, नियंत्रण डीबगर को पास करता है, यह भट्टी बाइट को पुनर्स्थापित करेगा, बहाल निर्देश को निष्पादित करेगा, और निर्देश के शीर्ष पर फिर से int3 लिखेगा। इस प्रकार, ब्रेकपॉइंट्स चल छवि को बदलते हैं, और हाइपरविज़र, जाहिर है, प्रोग्राम मेमोरी की कुंजी की प्रतिलिपि बनाने से पहले इसकी अखंडता की जांच करता है। त्रुटि संदेश भी इस पर संकेत देता है।

यह समस्या निम्नलिखित तरीके से आसानी से हल हो जाती है। हम vmcall से पहले कुछ निर्देश स्थापित करते हैं, ब्रेकप्वाइंट में आने के बाद हम इसे हटा देंगे और हम चरण दर चरण कोड निष्पादित करेंगे। Vmcall चल रहा है, हमें मिलता है:



EBX रजिस्टर में, पता 0x165000 है, जिस पर पहले से ही परिचित स्ट्रिंग "कुंजी: नीस ट्राय , यह एक कुंजी नहीं है" स्थित है । हाइपरवाइजर अभी भी कुंजी को पढ़ने से रोकता है।

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

आइए अगली विधि का प्रयास करें - हम अपने dll को KeyReader प्रक्रिया में इंजेक्ट करते हैं, और इसमें से हम उस मेमोरी को पढ़ते हैं जिसमें कुंजी स्थित है। सबसे पहले, प्रक्रिया शुरू करें, ओली डीबीजी का उपयोग करके इसे संलग्न करें और उस पते को देखें जहां कुंजी के साथ बफर स्थित है। बफ़र के लिए सूचक 0x40eb3c पर स्थित है।



हमारे मामले में, बफर के लिए मेमोरी को 0x600000 पर आवंटित किया गया था, डिबगर के रूप में, एप्लिकेशन काम करना जारी रखता है। हम एक dll लिखते हैं जो इस पते पर मेमोरी को पढ़ेगा और इसे a.txt फ़ाइल में डिस्क पर सेव करेगा। कोड इस तरह दिखेगा:



एक इंजेक्टर के रूप में, हमने C / C ++ के माध्यम से पुस्तक विंडोज से एक उदाहरण का उपयोग किया। Dll इंजेक्ट करें और निम्न पंक्ति वाली a.txt फ़ाइल प्राप्त करें:



यह कुंजी है।

KeyReader प्रक्रिया छवि में नहीं कोड इंजेक्शन के विषय पर कोई भी बदलाव एक समाधान होगा। उदाहरण के लिए, डीबगर में भाग लेने वालों में से एक ने कर्नेल 32.dll में ReadConsoleInputA फ़ंक्शन का कोड निर्धारित किया, जिसे गेटी फ़ंक्शन द्वारा कहा जाता है, और इसमें से मैं एक ज्ञात पते पर एक पंक्ति पढ़ता हूं। जैसा कि आप देख सकते हैं, कार्य सबसे मुश्किल नहीं है, लेकिन केवल एक व्यक्ति ने इसे अंत में प्रबंधित किया। सबसे अधिक संभावना है, यह समय की कमी के कारण था, और कार्य ही ऐसा है कि यह लगभग एक तार्किक श्रृंखला नहीं है जो एक उत्तर की ओर ले जाएगा। प्रतिभागियों को उन सभी तरीकों के माध्यम से क्रमबद्ध करना पड़ता था जो वे किसी बिंदु पर किसी कार्यशील संस्करण पर ठोकर खाने के लिए किसी और की प्रक्रिया की स्मृति को पढ़ना जानते थे।

सामान्य तौर पर, इस कार्य को तैयार करना संभवतः इसके माध्यम से जाने से भी अधिक दिलचस्प था :)। पृष्ठ तक पहुंच को नियंत्रित करने के लिए, आभासी पते से भौतिक एक तक से जुड़े सभी अनुवाद तालिकाओं में परिवर्तन को नियंत्रित करना आवश्यक था। मैपिंग विकल्पों की विविधता और इस तथ्य को देखते हुए कि भौतिक पृष्ठ का पता जिस तक हम पहुंच को नियंत्रित करते हैं, वह बदल सकता है, यह इतना तुच्छ नहीं है।

एक मामले में हाइपरवाइजर किस सिद्धांत से कुंजी को एक्सेस देता है, और दूसरे में नहीं? कुंजी के साथ पृष्ठ तक पहुँचने पर, उसने 3 शर्तें जाँची:
• पढ़ना उपयोगकर्ता मोड से होना चाहिए
• उस खंड का हैश। प्रक्रिया छवि से, जहाँ से कुंजी एक्सेस की जाती है, को कड़ाई से परिभाषित किया जाना चाहिए
• एक कुंजी केवल पता स्थान से पढ़ा जा सकता है जिसमें vmcall को कुंजी प्राप्त करने के लिए बुलाया गया था।

पहली शर्त ने कर्नेल से कुंजी को पढ़ने के सभी प्रयासों को अस्वीकार कर दिया। इनमें ReadProcessMemory फ़ंक्शन और अपना स्वयं का ड्राइवर लिखना शामिल है। दूसरी शर्त ने छवि कोड को बदलने और ब्रेक पॉइंट सेट करने की अनुमति नहीं दी। वैसे, केवल पाठ अनुभाग की जांच की गई थी, ताकि आप अपने स्वयं के अनुभाग को कोड के साथ जोड़ सकें, जिसे अलग-अलग कहा जाएगा और इसमें प्रवेश बिंदु को बदल दिया जाएगा। फिर अपने कोड से कुंजी प्राप्त करने के फ़ंक्शन को कॉल करें और इसे डिस्क पर सहेजें। तीसरी स्थिति ने अन्य प्रक्रियाओं की अनुमति नहीं दी, जिसमें कीरडर प्रक्रिया की मेमोरी कुंजी को पढ़ने के लिए जमा हुई थी। यह स्थिति कुछ हद तक दूर है, क्योंकि ऐसी स्थिति पाने के लिए आपको अपने ड्राइवर और अपने आवेदन को लिखना होगा जो इसके साथ संवाद करेगा, क्योंकि हमें विंडोज 7 पर इस तरह की कार्यक्षमता के साथ कोई तैयार उपयोगिताओं नहीं मिली। Windows XP के तहत, WinHex RAM Editor ने भौतिक मेमोरी को पढ़ते समय इसी तरह से काम किया। शर्तों का मुख्य लक्ष्य केवल तैयार उपयोगिताओं का उपयोग करके कार्य को पूरा करने में असमर्थता थी और कोड की एक भी पंक्ति लिखे बिना।

और निष्कर्ष में ...

हाइपरवाइजर के साथ एक कार्य तैयार करते समय, हम प्रतिभागियों को कार्य की असामान्य प्रकृति पर आश्चर्यचकित करना चाहते थे। सब के बाद, यह प्रतीत होता है, प्रक्रिया मेमोरी से एक पंक्ति को पढ़ने में क्या समस्याएं हो सकती हैं? और, इस तथ्य को देखते हुए कि केवल एक प्रतिभागी ने कार्य पूरा किया, हम सफल हुए! हम आशा करते हैं कि यह Habr के पाठकों के लिए दिलचस्प था! जल्द ही, सबसे "लोहा" कार्य NeoQUEST-2013 के विस्तृत विश्लेषण के साथ लेखों की अपेक्षा करें!