एक बार पेन्टेस्ट पर, या यूरोलॉजिस्ट और रोसकोम्नाडज़ोर की मदद से सब कुछ कैसे तोड़ें

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

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

इस लेख में ग्राहक के लिए, हमारी भावनाओं के अनुसार, सब कुछ आम तौर पर उत्कृष्ट था, कम से कम रूसी संघ के 95% बाजार से बेहतर था, लेकिन कई छोटी-छोटी बारीकियाँ थीं जिन्होंने घटनाओं की एक लंबी श्रृंखला बनाई, जो पहले काम पर एक लंबी रिपोर्ट और फिर इस लेख का नेतृत्व किया।

तो, आइए पॉपकॉर्न का स्टॉक करें और जासूसी कहानी में आपका स्वागत है। शब्द - पावेल सुप्रुन्युक, ग्रुप-आईबी के "ऑडिट और परामर्श" विभाग के तकनीकी प्रबंधक।

भाग 1. पोचकिन डॉक्टर

2018 एक ग्राहक है - एक हाई-टेक आईटी कंपनी, जो स्वयं कई ग्राहकों को सेवा प्रदान करती है। इस प्रश्न का उत्तर पाना चाहता है: क्या बिना किसी प्रारंभिक ज्ञान और पहुंच के, इंटरनेट के माध्यम से काम करते हुए, सक्रिय निर्देशिका डोमेन व्यवस्थापक अधिकार प्राप्त करना संभव है? मुझे किसी सोशल इंजीनियरिंग में कोई दिलचस्पी नहीं है (ओह, लेकिन व्यर्थ), उनका जानबूझकर काम में हस्तक्षेप करने का इरादा नहीं है, लेकिन वे गलती से - उदाहरण के लिए, एक अजीब तरह से काम करने वाले सर्वर को पुनः लोड कर सकते हैं। एक अतिरिक्त लक्ष्य बाहरी परिधि के विरुद्ध यथासंभव अन्य आक्रमण वैक्टरों की पहचान करना है। कंपनी नियमित रूप से ऐसे परीक्षण करती रहती है और अब नए परीक्षण की समय सीमा आ गई है। स्थितियाँ लगभग सामान्य, पर्याप्त, समझने योग्य हैं। आएँ शुरू करें।

ग्राहक का एक नाम है - इसे मुख्य वेबसाइट के साथ "कंपनी" होने दें www.company.ru. बेशक, ग्राहक को अलग तरह से कहा जाता है, लेकिन इस लेख में सब कुछ अवैयक्तिक होगा।
मैं नेटवर्क टोही का संचालन करता हूं - पता लगाता हूं कि ग्राहक के साथ कौन से पते और डोमेन पंजीकृत हैं, एक नेटवर्क आरेख बनाएं, इन पतों पर सेवाएं कैसे वितरित की जाती हैं। मुझे परिणाम मिला: 4000 से अधिक लाइव आईपी पते। मैं इन नेटवर्कों में डोमेन को देखता हूं: सौभाग्य से, अधिकांश नेटवर्क ग्राहक के ग्राहकों के लिए हैं, और हम औपचारिक रूप से उनमें रुचि नहीं रखते हैं। ग्राहक भी यही सोचता है.

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

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

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

वैसे, पहले लॉन्च किए गए स्कैनर्स को सामान्य तौर पर क्या मिला। मैं आपको याद दिला दूं: कुछ लोगों के लिए, "पेंटेस्ट" "स्वचालित स्कैन" के बराबर है। लेकिन इस प्रोजेक्ट पर स्कैनर्स ने कुछ नहीं कहा। खैर, अधिकतम मध्यम कमजोरियों (गंभीरता के संदर्भ में 3 में से 5) द्वारा दिखाया गया था: कुछ सेवा पर एक खराब टीएलएस प्रमाणपत्र या पुराना एन्क्रिप्शन एल्गोरिदम, और अधिकांश साइटों पर क्लिकजैकिंग। लेकिन यह आपको आपके लक्ष्य तक नहीं पहुंचाएगा. शायद स्कैनर यहां अधिक उपयोगी होंगे, लेकिन मैं आपको याद दिला दूं: ग्राहक स्वयं ऐसे प्रोग्राम खरीदने और उनके साथ खुद का परीक्षण करने में सक्षम है, और, निराशाजनक परिणामों को देखते हुए, वह पहले ही जांच कर चुका है।

आइए "विसंगतिपूर्ण" साइटों पर वापस जाएँ। पहला एक गैर-मानक पते पर स्थानीय विकी जैसा कुछ है, लेकिन इस लेख में इसे wiki.company[.]ru होने दें। उसने तुरंत लॉगिन और पासवर्ड भी मांगा, लेकिन ब्राउज़र में एनटीएलएम के माध्यम से। उपयोगकर्ता के लिए, यह एक तपस्वी विंडो की तरह दिखता है जो उपयोगकर्ता नाम और पासवर्ड दर्ज करने के लिए कहता है। और यह ख़राब प्रथा है.

एक छोटा सा नोट. परिधि वेबसाइटों में एनटीएलएम कई कारणों से खराब है। पहला कारण यह है कि सक्रिय निर्देशिका डोमेन नाम सामने आया है। हमारे उदाहरण में, यह भी "बाहरी" DNS नाम की तरह ही कंपनी.ru निकला। यह जानकर, आप सावधानी से कुछ दुर्भावनापूर्ण तैयार कर सकते हैं ताकि यह केवल संगठन की डोमेन मशीन पर निष्पादित हो, न कि किसी सैंडबॉक्स में। दूसरे, प्रमाणीकरण सीधे डोमेन नियंत्रक के माध्यम से एनटीएलएम (आश्चर्य, सही?) के माध्यम से जाता है, जिसमें "आंतरिक" नेटवर्क नीतियों की सभी विशेषताएं शामिल हैं, जिसमें खातों को पासवर्ड प्रविष्टि प्रयासों की संख्या से अधिक होने से रोकना भी शामिल है। यदि किसी हमलावर को लॉगिन का पता चल जाता है, तो वह उनके लिए पासवर्ड आज़माएगा। यदि आप खातों को गलत पासवर्ड दर्ज करने से रोकने के लिए कॉन्फ़िगर हैं, तो यह काम करेगा और खाता ब्लॉक कर दिया जाएगा। तीसरा, ऐसे प्रमाणीकरण में दूसरा कारक जोड़ना असंभव है। यदि कोई पाठक अभी भी जानता है कि कैसे, कृपया मुझे बताएं, यह वास्तव में दिलचस्प है। चौथा, पास-द-हैश हमलों के प्रति भेद्यता। इन सब से बचाव के लिए, अन्य चीज़ों के अलावा, ADFS का आविष्कार किया गया था।

Microsoft उत्पादों की एक ख़राब विशेषता है: भले ही आपने ऐसे NTLM को विशेष रूप से प्रकाशित नहीं किया हो, यह कम से कम OWA और Lync में डिफ़ॉल्ट रूप से स्थापित किया जाएगा।

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

दूसरी साइट का पता था "स्पष्ट रूप से किसी प्रकार का अंतिम नाम.company.ru।" यह गूगल के माध्यम से मिला, पेज 10 पर कुछ इस तरह। डिज़ाइन XNUMX के दशक के मध्य का था, और एक सम्मानित व्यक्ति इसे मुख्य पृष्ठ से देख रहा था, कुछ इस तरह:

यहां मैंने "हार्ट ऑफ ए डॉग" से एक चित्र लिया, लेकिन यकीन मानिए, यह थोड़ा-बहुत समान था, यहां तक ​​कि रंग डिजाइन भी समान टोन में था। साइट को बुलाया जाए preobrazhensky.company.ru.

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

कमजोरियों के संदर्भ में, वेबसाइट स्वयं सुरक्षित थी। आगे देखते हुए, मैं कहूंगा कि यह स्थिर जानकारी का एक सेट था - गुर्दे और मूत्राशय के रूप में सम्मिलित चित्रों के साथ सरल HTML पृष्ठ। ऐसी साइट को "ब्रेक" करना बेकार है।

लेकिन नीचे का वेब सर्वर अधिक दिलचस्प था। HTTP सर्वर हेडर को देखते हुए, इसमें IIS 6.0 था, जिसका अर्थ है कि इसमें ऑपरेटिंग सिस्टम के रूप में Windows 2003 का उपयोग किया गया था। स्कैनर ने पहले ही पहचान लिया था कि यह विशेष यूरोलॉजिस्ट वेबसाइट, उसी वेब सर्वर पर अन्य वर्चुअल होस्ट के विपरीत, PROPFIND कमांड का जवाब देती है, जिसका अर्थ है कि यह WebDAV चला रही थी। वैसे, स्कैनर ने इस जानकारी को इन्फो मार्क के साथ वापस कर दिया (स्कैनर रिपोर्ट की भाषा में, यह सबसे कम खतरा है) - ऐसी चीजें आमतौर पर छोड़ दी जाती हैं। संयोजन में, इसने एक दिलचस्प प्रभाव दिया, जो Google पर एक और खोज के बाद ही सामने आया: शैडो ब्रोकर्स सेट से जुड़ी एक दुर्लभ बफर ओवरफ़्लो भेद्यता, अर्थात् CVE-2017-7269, जिसमें पहले से ही एक तैयार शोषण था। दूसरे शब्दों में, यदि आपके पास Windows 2003 है और WebDAV IIS पर चल रहा है तो परेशानी होगी। हालाँकि 2003 में विंडोज़ 2018 को उत्पादन में चलाना अपने आप में एक समस्या है।

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

आमतौर पर इसके बाद "ग्राहक, जागो, हमने सब कुछ छोड़ दिया" की शैली में एक पत्र लिखा होता है। लेकिन हमें बताया गया कि साइट का व्यावसायिक प्रक्रियाओं से कोई लेना-देना नहीं है और यह पूरे सर्वर की तरह बिना किसी कारण के काम करती है, और हम इस संसाधन का उपयोग अपनी इच्छानुसार कर सकते हैं।
करीब एक दिन बाद साइट अचानक अपने आप काम करने लगी। IIS 6.0 पर WebDAV से एक बेंच बनाने के बाद, मैंने पाया कि डिफ़ॉल्ट सेटिंग हर 30 घंटे में IIS कार्यकर्ता प्रक्रियाओं को पुनरारंभ करना है। अर्थात्, जब नियंत्रण शेलकोड से बाहर निकल गया, तो IIS कार्यकर्ता प्रक्रिया समाप्त हो गई, फिर उसने स्वयं को कुछ बार पुनः आरंभ किया और फिर 30 घंटों के लिए आराम पर चला गया।

चूंकि टीसीपी का बैककनेक्ट पहली बार विफल रहा, इसलिए मैंने इस समस्या के लिए एक बंद पोर्ट को जिम्मेदार ठहराया। अर्थात्, उन्होंने किसी प्रकार के फ़ायरवॉल की उपस्थिति का अनुमान लगाया जो आउटगोइंग कनेक्शन को बाहर जाने की अनुमति नहीं देता था। मैंने शेलकोड चलाना शुरू किया जो कई टीसीपी और यूडीपी पोर्ट के माध्यम से खोजा गया, कोई प्रभाव नहीं पड़ा। मेटास्प्लोइट से http(s) के माध्यम से रिवर्स कनेक्शन लोड काम नहीं करता - मीटरप्रेटर/रिवर्स_http(s)। अचानक, उसी पोर्ट 80 से एक कनेक्शन स्थापित किया गया, लेकिन तुरंत हटा दिया गया। मैंने इसका श्रेय अभी भी काल्पनिक आईपीएस की कार्रवाई को दिया, जिसे मीटरप्रेटर ट्रैफिक पसंद नहीं आया। इस तथ्य के प्रकाश में कि पोर्ट 80 के लिए एक शुद्ध टीसीपी कनेक्शन नहीं हुआ, लेकिन एक http कनेक्शन हुआ, मैंने निष्कर्ष निकाला कि एक http प्रॉक्सी को किसी तरह सिस्टम में कॉन्फ़िगर किया गया था।

मैंने DNS के माध्यम से मीटरप्रेटर भी आज़माया (धन्यवाद)। d00kie आपके प्रयासों के लिए, कई परियोजनाओं को बचाया), पहली सफलता को याद करते हुए, लेकिन इसने स्टैंड पर भी काम नहीं किया - इस भेद्यता के लिए शेलकोड बहुत बड़ा था।

हकीकत में, यह इस तरह दिखता था: 3 मिनट के भीतर हमलों के 4-5 प्रयास, फिर 30 घंटे तक इंतजार करना। और इसी तरह लगातार तीन सप्ताह तक। मैंने समय बर्बाद न करने के लिए एक अनुस्मारक भी सेट कर दिया। इसके अतिरिक्त, परीक्षण और उत्पादन वातावरण के व्यवहार में अंतर था: इस भेद्यता के लिए दो समान कारनामे थे, एक मेटास्प्लोइट से, दूसरा इंटरनेट से, शैडो ब्रोकर्स संस्करण से परिवर्तित। इसलिए, युद्ध में केवल मेटास्प्लोइट का परीक्षण किया गया था, और केवल दूसरे का बेंच पर परीक्षण किया गया था, जिसने डिबगिंग को और भी कठिन बना दिया था और दिमाग खराब कर दिया था।

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

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

यह तुरंत स्पष्ट हो गया कि मेरे पास सबसे बुनियादी IIS वर्कफ़्लो अधिकार हैं, जो मुझे कुछ भी नहीं करने की अनुमति देते हैं। मेटास्प्लोइट कंसोल पर यह इस तरह दिखता था:

सभी पेंटेस्ट पद्धतियाँ दृढ़ता से सुझाव देती हैं कि पहुँच प्राप्त करते समय आपको अधिकार बढ़ाने की आवश्यकता है। मैं आमतौर पर इसे स्थानीय रूप से नहीं करता, क्योंकि पहली पहुंच को केवल एक नेटवर्क प्रवेश बिंदु के रूप में देखा जाता है, और उसी नेटवर्क पर किसी अन्य मशीन से समझौता करना आमतौर पर मौजूदा होस्ट पर विशेषाधिकार बढ़ाने की तुलना में आसान और तेज़ होता है। लेकिन यहाँ ऐसा नहीं है, क्योंकि DNS चैनल बहुत संकीर्ण है और यह ट्रैफ़िक को साफ़ नहीं होने देगा।

यह मानते हुए कि प्रसिद्ध MS2003-17 भेद्यता के लिए इस Windows 010 सर्वर की मरम्मत नहीं की गई है, मैं लोकलहोस्ट पर मीटरप्रेटर DNS टनल के माध्यम से पोर्ट 445/TCP पर ट्रैफ़िक टनल करता हूँ (हाँ, यह भी संभव है) और पहले से डाउनलोड किए गए exe को चलाने का प्रयास करता हूँ भेद्यता. हमला काम करता है, मुझे दूसरा कनेक्शन प्राप्त होता है, लेकिन सिस्टम अधिकारों के साथ।

यह दिलचस्प है कि उन्होंने अभी भी सर्वर को MS17-010 से बचाने की कोशिश की - इसमें बाहरी इंटरफ़ेस पर कमजोर नेटवर्क सेवाएँ अक्षम थीं। यह नेटवर्क पर हमलों से बचाता है, लेकिन लोकलहोस्ट पर भीतर से हमला काम करता है, क्योंकि आप लोकलहोस्ट पर एसएमबी को तुरंत बंद नहीं कर सकते।

आगे, नए दिलचस्प विवरण सामने आए हैं:

1. सिस्टम अधिकार होने पर, आप आसानी से टीसीपी के माध्यम से बैककनेक्शन स्थापित कर सकते हैं। जाहिर है, प्रत्यक्ष टीसीपी को अक्षम करना सीमित आईआईएस उपयोगकर्ता के लिए एक समस्या है। स्पॉइलर: IIS उपयोगकर्ता ट्रैफ़िक किसी तरह दोनों दिशाओं में स्थानीय ISA प्रॉक्सी में लपेटा गया था। यह वास्तव में कैसे काम करता है, मैंने इसका पुनरुत्पादन नहीं किया है।
2. मैं एक निश्चित "डीएमजेड" में हूं (और यह एक सक्रिय निर्देशिका डोमेन नहीं है, बल्कि एक कार्यसमूह है) - यह तर्कसंगत लगता है। लेकिन अपेक्षित निजी ("ग्रे") आईपी पते के बजाय, मेरे पास पूरी तरह से "सफेद" आईपी पता है, बिल्कुल वैसा ही जैसा कि मैंने पहले हमला किया था। इसका मतलब यह है कि कंपनी IPv4 एड्रेसिंग की दुनिया में इतनी पुरानी है कि वह योजना के अनुसार NAT के बिना 128 "व्हाइट" पतों के लिए DMZ ज़ोन बनाए रखने का जोखिम उठा सकती है, जैसा कि 2005 से सिस्को मैनुअल में दर्शाया गया है।

चूँकि सर्वर पुराना है, Mimikatz को सीधे मेमोरी से काम करने की गारंटी है:

मुझे स्थानीय व्यवस्थापक पासवर्ड मिलता है, टीसीपी पर आरडीपी ट्रैफ़िक टनल होता है और एक आरामदायक डेस्कटॉप में लॉग इन होता है। चूँकि मैं सर्वर के साथ जो चाहे कर सकता था, मैंने एंटीवायरस हटा दिया और पाया कि सर्वर केवल टीसीपी पोर्ट 80 और 443 के माध्यम से इंटरनेट से पहुंच योग्य था, और 443 व्यस्त नहीं था। मैंने 443 पर एक ओपनवीपीएन सर्वर स्थापित किया है, अपने वीपीएन ट्रैफिक के लिए एनएटी फ़ंक्शन जोड़ा है और अपने ओपनवीपीएन के माध्यम से असीमित रूप में डीएमजेड नेटवर्क तक सीधी पहुंच प्राप्त की है। यह उल्लेखनीय है कि ISA ने, कुछ गैर-अक्षम IPS फ़ंक्शंस के साथ, पोर्ट स्कैनिंग के साथ मेरे ट्रैफ़िक को अवरुद्ध कर दिया था, जिसके लिए इसे एक सरल और अधिक आज्ञाकारी RRAS से बदलना पड़ा। इसलिए कभी-कभी पेंटेस्टर्स को सभी प्रकार की चीजों का प्रबंधन करना पड़ता है।

एक चौकस पाठक पूछेगा: "दूसरी साइट के बारे में क्या - एनटीएलएम प्रमाणीकरण के साथ एक विकी, जिसके बारे में बहुत कुछ लिखा गया है?" इस पर बाद में और अधिक जानकारी।

भाग 2. अभी भी एन्क्रिप्ट नहीं हो रहा? तो हम पहले से ही यहां आपके पास आ रहे हैं

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

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

चूंकि इस समय मेरे पास अन्य प्रणालियों तक कोई पहुंच नहीं थी और कॉर्पोरेट सेवाओं के लिए एक भी खाता नहीं था, इसलिए एआरपी स्पूफिंग का उपयोग करके ट्रैफ़िक से कम से कम कुछ खाता निकालने का निर्णय लिया गया।

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

1. अच्छा: बहुत सारे प्रमाण पकड़े गए और समग्र रूप से हमला काम कर गया।
2. ख़राब: सभी क्रेडेंशियल ग्राहक के अपने ग्राहकों के थे। सहायता सेवाएँ प्रदान करते समय, ग्राहक विशेषज्ञ उन ग्राहकों की सेवाओं से जुड़े थे जिनके पास हमेशा ट्रैफ़िक एन्क्रिप्शन कॉन्फ़िगर नहीं था।

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

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

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

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

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

याद रखें, मैंने निर्दिष्ट किया था कि सक्रिय निर्देशिका डोमेन नाम "बाहरी" डोमेन के साथ मेल खाता है, अर्थात यह कंपनी.ru था? इसलिए, विंडोज़, अधिक सटीक रूप से इंटरनेट एक्सप्लोरर (और एज और क्रोम), उपयोगकर्ता को एनटीएलएम के माध्यम से HTTP में पारदर्शी रूप से प्रमाणित करने की अनुमति देता है यदि वे मानते हैं कि साइट कुछ "इंट्रानेट ज़ोन" में स्थित है। "इंट्रानेट" के संकेतों में से एक "ग्रे" आईपी पते या एक संक्षिप्त डीएनएस नाम तक पहुंच है, यानी बिना डॉट्स के। चूंकि उनके पास "सफ़ेद" आईपी और DNS नाम preobrazhensky.company.ru वाला एक सर्वर था, और डोमेन मशीनें आमतौर पर सरलीकृत नाम प्रविष्टि के लिए डीएचसीपी के माध्यम से सक्रिय निर्देशिका डोमेन प्रत्यय प्राप्त करती हैं, उन्हें केवल पता बार में यूआरएल लिखना पड़ता था प्रीओब्राज़ेंस्की, ताकि वे समझौता किए गए मूत्र रोग विशेषज्ञ के सर्वर तक सही रास्ता ढूंढ सकें, यह न भूलें कि इसे अब "इंट्रानेट" कहा जाता है। यानी, साथ ही मुझे उपयोगकर्ता की जानकारी के बिना उसका एनटीएलएम-हैंडशेक देना। जो कुछ बचा है वह क्लाइंट ब्राउज़रों को इस सर्वर से संपर्क करने की तत्काल आवश्यकता के बारे में सोचने के लिए मजबूर करना है।

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

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

जावास्क्रिप्ट तैयार किया गया था, जिसे इंटरसेप्टर-एनजी का उपयोग करके ब्लू कोट के लिए जेएस फाइलों के साथ प्रत्येक प्रतिक्रिया पर रात में एक घंटे के लिए लागू किया गया था। स्क्रिप्ट ने निम्नलिखित कार्य किया:

• उपयोगकर्ता-एजेंट द्वारा वर्तमान ब्राउज़र का निर्धारण किया गया। यदि यह इंटरनेट एक्सप्लोरर, एज या क्रोम होता, तो यह काम करता रहता।
• मैंने पृष्ठ का DOM बनने तक प्रतीक्षा की।
• प्रपत्र की स्रोत विशेषता के साथ DOM में एक अदृश्य छवि सम्मिलित की गई प्रीओब्राज़ेंस्की:8080/एनएनएनएनएनएन.पीएनजी, जहां एनएनएन मनमानी संख्याएं हैं ताकि ब्लूकोट इसे कैश न करे।
• यह इंगित करने के लिए एक वैश्विक ध्वज चर सेट करें कि इंजेक्शन पूरा हो गया था और अब छवियों को सम्मिलित करने की कोई आवश्यकता नहीं है।

ब्राउज़र ने इस छवि को लोड करने का प्रयास किया; समझौता किए गए सर्वर के पोर्ट 8080 पर, एक टीसीपी सुरंग मेरे लैपटॉप पर इसका इंतजार कर रही थी, जहां वही रिस्पॉन्डर चल रहा था, जिसके लिए ब्राउज़र को एनटीएलएम के माध्यम से लॉग इन करने की आवश्यकता थी।

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

उपयोगकर्ताओं द्वारा यूरोलॉजिस्ट सर्वर पर बड़े पैमाने पर गुप्त दौरे

आप शायद पहले ही देख चुके होंगे कि यह पूरी कहानी इस सिद्धांत पर बनी है कि "सब कुछ ठीक था, लेकिन फिर कुछ गड़बड़ हुई, फिर काबू पाया गया और फिर सब कुछ सफल हो गया।" तो, यहाँ एक हंगामा था। पचास अनोखे हैंडशेक में से एक भी सामने नहीं आया। और यह इस तथ्य को ध्यान में रखता है कि एक मृत प्रोसेसर वाले लैपटॉप पर भी, ये NTLMv2 हैंडशेक प्रति सेकंड कई सौ मिलियन प्रयासों की गति से संसाधित होते हैं।

मुझे खुद को पासवर्ड म्यूटेशन तकनीक, एक वीडियो कार्ड, एक मोटी डिक्शनरी से लैस करना पड़ा और इंतजार करना पड़ा। लंबे समय के बाद, "Q11111111....1111111q" फॉर्म के पासवर्ड वाले कई खाते सामने आए, जिससे पता चलता है कि सभी उपयोगकर्ताओं को एक बार अलग-अलग वर्णों के मामले के साथ एक बहुत लंबे पासवर्ड के साथ आने के लिए मजबूर किया गया था, जिसे माना भी गया था जटिल हो. लेकिन आप एक अनुभवी उपयोगकर्ता को मूर्ख नहीं बना सकते, और इस तरह उसने अपने लिए याद रखना आसान बना लिया। कुल मिलाकर, लगभग 5 खातों से समझौता किया गया था, और उनमें से केवल एक के पास सेवाओं का कोई मूल्यवान अधिकार था।

भाग 3. रोसकोम्नाडज़ोर ने पलटवार किया

तो, पहले डोमेन खाते प्राप्त हुए। यदि आप लंबे समय तक पढ़ने के बाद इस बिंदु तक सोए नहीं हैं, तो आपको शायद याद होगा कि मैंने एक ऐसी सेवा का उल्लेख किया था जिसके लिए प्रमाणीकरण के दूसरे कारक की आवश्यकता नहीं थी: यह एनटीएलएम प्रमाणीकरण के साथ एक विकी है। निःसंदेह, सबसे पहला काम वहां प्रवेश करना था। आंतरिक ज्ञान के आधार को खोदने से शीघ्र ही परिणाम प्राप्त हुए:

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

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

"दूसरा कारक" टूटने के साथ, मैं आउटलुक वेब एक्सेस मेल और सिट्रिक्स नेटस्केलर गेटवे में रिमोट एक्सेस तक पहुंचने में सक्षम था। आउटलुक में मेल में एक आश्चर्य था:

इस दुर्लभ शॉट में आप देख सकते हैं कि कैसे रोसकोम्नाडज़ोर पेंटेस्टर्स की मदद करता है

टेलीग्राम के प्रसिद्ध "फैन" ब्लॉकिंग के बाद ये पहले महीने थे, जब हजारों पतों वाले पूरे नेटवर्क पहुंच से गायब हो गए। यह स्पष्ट हो गया कि पुश ने तुरंत काम क्यों नहीं किया और मेरे "पीड़ित" ने अलार्म क्यों नहीं बजाया क्योंकि उन्होंने खुले घंटों के दौरान उसके खाते का उपयोग करना शुरू कर दिया था।

Citrix Netscaler से परिचित कोई भी व्यक्ति कल्पना करता है कि इसे आम तौर पर इस तरह से कार्यान्वित किया जाता है कि केवल एक चित्र इंटरफ़ेस ही उपयोगकर्ता तक पहुंचाया जा सकता है, उसे तृतीय-पक्ष एप्लिकेशन लॉन्च करने और डेटा स्थानांतरित करने के लिए उपकरण न देने की कोशिश की जाती है, जिससे हर संभव तरीके से कार्रवाई सीमित हो जाती है। मानक नियंत्रण गोले के माध्यम से। मेरे "पीड़ित" को, उसके व्यवसाय के कारण, केवल 1C मिला:

1C इंटरफ़ेस पर थोड़ा घूमने के बाद, मैंने पाया कि वहां बाहरी प्रोसेसिंग मॉड्यूल हैं। उन्हें इंटरफ़ेस से लोड किया जा सकता है, और अधिकारों और सेटिंग्स के आधार पर उन्हें क्लाइंट या सर्वर पर निष्पादित किया जाएगा।

मैंने अपने 1C प्रोग्रामर दोस्तों से एक ऐसी प्रोसेसिंग बनाने के लिए कहा जो एक स्ट्रिंग को स्वीकार करे और उसे निष्पादित करे। 1सी भाषा में, एक प्रक्रिया शुरू करना कुछ इस तरह दिखता है (इंटरनेट से लिया गया)। क्या आप इस बात से सहमत हैं कि 1C भाषा का वाक्य-विन्यास रूसी भाषी लोगों को अपनी सहजता से आश्चर्यचकित करता है?

प्रसंस्करण पूरी तरह से निष्पादित किया गया था; यह वही निकला जिसे पेंटेस्टर "शेल" कहते हैं - इसके माध्यम से इंटरनेट एक्सप्लोरर लॉन्च किया गया था।

पहले, उस सिस्टम का पता जो आपको क्षेत्र के लिए पास ऑर्डर करने की अनुमति देता था, मेल में पाया जाता था। यदि मुझे वाईफाई अटैक वेक्टर का उपयोग करना होता तो मैंने पास का आदेश दिया।

इंटरनेट पर चर्चा है कि ग्राहक के कार्यालय में अभी भी स्वादिष्ट मुफ्त खानपान था, लेकिन मैंने अभी भी दूर से हमले को विकसित करना पसंद किया, यह शांत है।

AppLocker Citrix चलाने वाले एप्लिकेशन सर्वर पर सक्रिय था, लेकिन इसे बायपास कर दिया गया था। उसी मीटरप्रेटर को DNS के माध्यम से लोड और लॉन्च किया गया था, क्योंकि http(s) संस्करण कनेक्ट नहीं होना चाहते थे, और मुझे उस समय आंतरिक प्रॉक्सी पता नहीं पता था। वैसे, इस क्षण से, बाहरी पेंटेस्ट अनिवार्य रूप से पूरी तरह से आंतरिक में बदल गया।

भाग 4. उपयोगकर्ताओं के लिए व्यवस्थापक अधिकार ख़राब हैं, ठीक है?

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

डोमेन व्यवस्थापक अधिकारों को जब्त करने की एक विशिष्ट तकनीक नीरस कार्यों के एक चक्र के रूप में सरलीकृत दिखती है:

• हम उन डोमेन कंप्यूटरों पर जाते हैं जहां पहले से कैप्चर किए गए डोमेन खातों के आधार पर स्थानीय व्यवस्थापक अधिकार होते हैं।
• हमने Mimikatz लॉन्च किया और हाल ही में इस सिस्टम में लॉग इन किए गए डोमेन खातों के कैश्ड पासवर्ड, केर्बरोस टिकट और NTLM हैश प्राप्त किए। या हम lsass.exe प्रक्रिया की मेमोरी इमेज को हटा देते हैं और अपनी तरफ से भी ऐसा ही करते हैं। यह डिफ़ॉल्ट सेटिंग्स के साथ 2012R2/Windows 8.1 से पुराने विंडोज़ के साथ अच्छी तरह से काम करता है।
• हम यह निर्धारित करते हैं कि समझौता किए गए खातों के पास स्थानीय व्यवस्थापक अधिकार कहां हैं। हम पहला बिंदु दोहराते हैं. किसी स्तर पर हम संपूर्ण डोमेन के लिए व्यवस्थापक अधिकार प्राप्त कर लेते हैं।

"चक्र का अंत;", जैसा कि 1सी प्रोग्रामर यहां लिखेंगे।

तो, हमारा उपयोगकर्ता विंडोज 7 के साथ सिर्फ एक होस्ट पर एक स्थानीय प्रशासक निकला, जिसके नाम में "VDI", या "वर्चुअल डेस्कटॉप इन्फ्रास्ट्रक्चर", व्यक्तिगत वर्चुअल मशीन शब्द शामिल था। संभवतः, VDI सेवा के डिज़ाइनर का मतलब यह था कि चूंकि VDI उपयोगकर्ता का निजी ऑपरेटिंग सिस्टम है, भले ही उपयोगकर्ता सॉफ़्टवेयर वातावरण को अपनी इच्छानुसार बदल दे, फिर भी होस्ट को "पुनः लोड" किया जा सकता है। मैंने भी सोचा कि सामान्य तौर पर यह विचार अच्छा था, मैं इस निजी वीडीआई होस्ट के पास गया और वहां एक घोंसला बनाया:

• मैंने वहां एक ओपनवीपीएन क्लाइंट स्थापित किया, जिसने इंटरनेट के माध्यम से मेरे सर्वर तक एक सुरंग बनाई। क्लाइंट को डोमेन प्रमाणीकरण के साथ उसी ब्लू कोट से गुजरने के लिए मजबूर होना पड़ा, लेकिन ओपनवीपीएन ने ऐसा किया, जैसा कि वे कहते हैं, "बॉक्स से बाहर।"
• वीडीआई पर ओपनएसएसएच स्थापित किया गया। खैर, वास्तव में, एसएसएच के बिना विंडोज 7 क्या है?

लाइव में ऐसा लग रहा था. मैं आपको याद दिला दूं कि यह सब Citrix और 1C के माध्यम से किया जाना है:

पड़ोसी कंप्यूटरों तक पहुंच को बढ़ावा देने की एक तकनीक मिलान के लिए स्थानीय व्यवस्थापक पासवर्ड की जांच करना है। यहां किस्मत ने तुरंत इंतजार किया: डिफ़ॉल्ट स्थानीय प्रशासक (जिसे अचानक प्रशासक कहा जाता था) के एनटीएलएम हैश को पास-द-हैश हमले के माध्यम से पड़ोसी वीडीआई मेजबानों तक पहुंचाया गया, जिनमें से कई सौ थे। बेशक, हमला तुरंत उन पर पड़ा।

यहीं पर VDI प्रशासकों ने दो बार अपने पैरों पर गोली मारी:

• पहली बार था जब VDI मशीनों को LAPS के अंतर्गत नहीं लाया गया था, अनिवार्य रूप से छवि से वही स्थानीय व्यवस्थापक पासवर्ड बरकरार रखा गया था जिसे VDI में बड़े पैमाने पर तैनात किया गया था।
• डिफ़ॉल्ट व्यवस्थापक एकमात्र स्थानीय खाता है जो पास-द-हैश हमलों के प्रति संवेदनशील है। एक ही पासवर्ड के साथ भी, एक जटिल यादृच्छिक पासवर्ड के साथ दूसरा स्थानीय व्यवस्थापक खाता बनाकर और डिफ़ॉल्ट को अवरुद्ध करके बड़े पैमाने पर समझौते से बचना संभव होगा।

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

यहां इंटरनेट से एक तस्वीर है जो इसी तरह की खोज दिखा रही है। कनेक्शन दिखाते हैं कि प्रशासक कौन है और कहां लॉग इन है।

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

शायद किसी के मन में यह सवाल होगा: अपनी सुरक्षा कैसे करें? यहां तक ​​कि यह आलेख कई तकनीकों का वर्णन करता है, जिनमें से कई के बारे में विंडोज़ प्रशासकों को भी पता नहीं है। हालाँकि, मैं उन्हें जटिल सिद्धांतों और सूचना सुरक्षा उपायों के परिप्रेक्ष्य से देखने का प्रस्ताव करता हूँ:

• पुराने सॉफ़्टवेयर का उपयोग न करें (शुरुआत में Windows 2003 याद है?)
• अनावश्यक सिस्टम चालू न रखें (यूरोलॉजिस्ट की वेबसाइट क्यों थी?)
• ताकत के लिए उपयोगकर्ता पासवर्ड स्वयं जांचें (अन्यथा सैनिक...पेंटेस्टर्स ऐसा करेंगे)
• विभिन्न खातों के लिए समान पासवर्ड नहीं होना (VDI समझौता)
• और दूसरा

बेशक, इसे लागू करना बहुत मुश्किल है, लेकिन अगले लेख में हम व्यवहार में दिखाएंगे कि यह काफी संभव है।

स्रोत: www.habr.com