एक पटक पेन्टेस्टमा, वा युरोलोजिस्ट र रोस्कोमनाडजोरको सहयोगमा सबै कुरा कसरी तोड्ने

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

संसारमा नम्रताको सन्तुलन पुनर्स्थापना गर्न, केहि समय पछि हामी एक पेन्टेस्टको बारेमा लेख्नेछौं जुन राम्रो भएन। हामी देखाउनेछौं कि कम्पनीमा कसरी राम्ररी डिजाइन गरिएका प्रक्रियाहरूले आक्रमणहरूको सम्पूर्ण दायराबाट जोगाउन सक्छ, राम्ररी तयार भएकाहरू पनि, केवल किनभने यी प्रक्रियाहरू अवस्थित छन् र वास्तवमा काम गर्छन्।

यस लेखमा ग्राहकहरूको लागि, सबै कुरा सामान्यतया उत्कृष्ट थियो, कम्तिमा पनि रूसी संघको बजारको 95% भन्दा राम्रो, हाम्रो भावना अनुसार, तर त्यहाँ धेरै साना नक्साहरू थिए जसले घटनाहरूको लामो श्रृंखला बनायो, जुन पहिले। काम मा एक लामो रिपोर्ट को नेतृत्व गर्यो, र त्यसपछि यो लेख।

त्यसोभए, पपकर्नमा भण्डारण गरौं, र जासूसी कथामा स्वागत छ। शब्द - पावेल सुप्रुन्युक, समूह-आईबीको "लेखापरीक्षण र परामर्श" विभागको प्राविधिक प्रबन्धक।

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

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

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

त्यहाँ 256 ठेगानाहरूसँग एउटा नेटवर्क बाँकी छ, जसको लागि यस क्षणमा आईपी ठेगानाहरूद्वारा डोमेनहरू र सबडोमेनहरूको वितरणको बुझाइ छ, त्यहाँ स्क्यान गरिएका पोर्टहरूको बारेमा जानकारी छ, जसको मतलब तपाईंले चाखलाग्दो व्यक्तिहरूको लागि सेवाहरू हेर्न सक्नुहुन्छ। समानान्तरमा, सबै प्रकारका स्क्यानरहरू उपलब्ध आईपी ठेगानाहरूमा र वेबसाइटहरूमा छुट्टै लन्च गरिएका छन्।

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

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

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

"असामान्य" साइटहरूमा फर्कौं। पहिलो भनेको गैर-मानक ठेगानामा स्थानीय विकी जस्तै हो, तर यस लेखमा यसलाई wiki.company [.]ru हुन दिनुहोस्। उनले तुरुन्तै लगइन र पासवर्ड पनि मागे, तर ब्राउजरमा NTLM मार्फत। प्रयोगकर्ताको लागि, यो प्रयोगकर्ता नाम र पासवर्ड प्रविष्ट गर्न सोध्ने तपस्वी विन्डो जस्तो देखिन्छ। र यो खराब अभ्यास हो।

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

माइक्रोसफ्ट उत्पादनहरूको एउटा खराब गुण छ: तपाईंले विशेष रूपमा त्यस्तो NTLM प्रकाशित नगरे पनि, यो कम्तिमा OWA र Lync मा पूर्वनिर्धारित रूपमा स्थापित हुनेछ।

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

दोस्रो साइटमा ठेगाना थियो "स्पष्ट रूपमा अन्तिम नामको कुनै प्रकारको.company.ru।" यो गुगल मार्फत फेला पर्यो, पृष्ठ 10 मा यस्तो केहि। डिजाइन प्रारम्भिक-मध्य XNUMX को थियो, र एक सम्मानित व्यक्तिले यसलाई मुख्य पृष्ठबाट हेर्दै थिए, केहि यो जस्तै:

यहाँ मैले "कुकुरको मुटु" बाट स्टिल लिएँ, तर मलाई विश्वास गर्नुहोस्, यो अस्पष्ट रूपमा समान थियो, रङ डिजाइन पनि समान टोनमा थियो। साइट बोलाउन दिनुहोस् preobrazhensky.company.ru.

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

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

तर तलको वेब सर्भर अझ रोचक थियो। HTTP सर्भर हेडर द्वारा न्याय गर्दै, यसमा IIS 6.0 थियो, जसको मतलब यसले Windows 2003 लाई अपरेटिङ सिस्टमको रूपमा प्रयोग गर्यो। स्क्यानरले पहिले नै पहिचान गरेको थियो कि यो विशेष यूरोलोजिस्ट वेबसाइट, उही वेब सर्भरमा अन्य भर्चुअल होस्टहरूको विपरीत, PROPFIND आदेशलाई प्रतिक्रिया दियो, यसको मतलब यो WebDAV चलिरहेको थियो। वैसे, स्क्यानरले मार्क जानकारीको साथ यो जानकारी फिर्ता गर्‍यो (स्क्यानर रिपोर्टहरूको भाषामा, यो सबैभन्दा कम खतरा हो) - त्यस्ता चीजहरू सामान्यतया छोडिन्छन्। संयोजनमा, यसले चाखलाग्दो प्रभाव दियो, जुन गुगलमा अर्को खोज पछि मात्र प्रकट भएको थियो: छाया ब्रोकर सेटसँग सम्बन्धित दुर्लभ बफर ओभरफ्लो जोखिम, अर्थात् CVE-2017-7269, जसमा पहिले नै तयार शोषण थियो। अर्को शब्दमा, यदि तपाइँसँग Windows 2003 छ र WebDAV IIS मा चलिरहेको छ भने त्यहाँ समस्या हुनेछ। सन् २०१८ मा उत्पादनमा विन्डोज २००३ चलाउँदा आफैमा समस्या छ।

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

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

tcp मा ब्याककनेक्ट पहिलो पटक असफल भएकोले, मैले यो समस्यालाई बन्द पोर्टमा श्रेय दिएँ। त्यो हो, उसले कुनै प्रकारको फायरवालको उपस्थितिलाई ग्रहण गर्यो जसले बाहिर जाने जडानहरूलाई बाहिर जान अनुमति दिँदैन। मैले धेरै tcp र udp पोर्टहरू मार्फत खोजी गर्ने शेलकोडहरू चलाउन थाले, त्यहाँ कुनै प्रभाव थिएन। Metasploit बाट http(हरू) मार्फत रिभर्स जडान लोडले काम गरेन - meterpreter/reverse_http(s)। अचानक, एउटै पोर्ट 80 मा जडान स्थापित भएको थियो, तर तुरुन्तै छोडियो। मैले यसको श्रेय अझै काल्पनिक IPS को कार्यलाई दिएँ, जसले मिटरप्रिटर ट्राफिकलाई मन पराउँदैन। तथ्यको प्रकाशमा कि पोर्ट 80 मा शुद्ध tcp जडान मार्फत गएन, तर एक http जडान भयो, मैले निष्कर्ष निकालें कि HTTP प्रोक्सी कुनै न कुनै रूपमा प्रणालीमा कन्फिगर गरिएको थियो।

मैले DNS मार्फत मिटरप्रिटर पनि प्रयास गरें (धन्यवाद d00kie तपाईको प्रयासको लागि, धेरै परियोजनाहरू बचत गरियो), पहिलो सफलतालाई सम्झाउँदै, तर यसले स्ट्यान्डमा पनि काम गरेन - शेलकोड यस जोखिमको लागि धेरै ठूलो थियो।

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

अन्तमा, शेलकोड जसले HTTP मार्फत दिइएको सर्भरबाट exe फाइल डाउनलोड गर्‍यो र यसलाई लक्षित प्रणालीमा सुरू गर्यो प्रभावकारी साबित भयो। शेलकोड फिट गर्न पर्याप्त सानो थियो, तर कम्तिमा यसले काम गर्यो। सर्भरले TCP ट्राफिकलाई मन पराउँदैन र मिटरप्रिटरको उपस्थितिको लागि http(हरू) निरीक्षण गरिएको थियो, मैले यो शेलकोड मार्फत DNS-meterpreter समावेश गर्ने exe फाइल डाउनलोड गर्ने निर्णय गरें।

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

यो तुरुन्तै स्पष्ट भयो कि मसँग सबैभन्दा आधारभूत IIS कार्यप्रवाह अधिकारहरू छन्, जसले मलाई केहि गर्न अनुमति दिँदैन। यो मेटास्प्लोइट कन्सोलमा जस्तो देखिन्छ:

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

यो Windows 2003 सर्भर प्रसिद्ध MS17-010 जोखिमको लागि मर्मत गरिएको छैन भनी मान्दै, म लोकलहोस्ट (हो, यो पनि सम्भव छ) मार्फत पोर्ट 445/TCP मा ट्राफिक टनेल गर्छु (हो, यो पनि सम्भव छ) र पहिले डाउनलोड गरिएको exe चलाउन प्रयास गर्नुहोस्। जोखिम। आक्रमणले काम गर्छ, मैले दोस्रो जडान प्राप्त गर्छु, तर प्रणाली अधिकारहरूसँग।

यो चाखलाग्दो छ कि तिनीहरूले अझै पनि MS17-010 बाट सर्भर सुरक्षित गर्ने प्रयास गरे - यसले बाह्य इन्टरफेसमा कमजोर नेटवर्क सेवाहरू असक्षम पारेको थियो। यसले नेटवर्कमा आक्रमणहरूबाट सुरक्षा गर्छ, तर लोकलहोस्टमा भित्रबाट भएको आक्रमणले काम गर्‍यो, किनकि तपाईंले लोकलहोस्टमा SMB चाँडै बन्द गर्न सक्नुहुन्न।

अर्को, नयाँ रोचक विवरणहरू प्रकट हुन्छन्:

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

सर्भर पुरानो भएकोले, Mimikatz लाई सिधै मेमोरीबाट काम गर्ने ग्यारेन्टी गरिएको छ:

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

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

भाग २. अझै पनि गुप्तिकरण गरिरहनुभएको छैन? त्यसोभए हामी तपाईलाई पहिले नै यहाँ आउँदैछौं

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

म OpenVPN टनेल मार्फत DMZ मार्फत स्क्यानरहरू चार्ज गर्छु र पर्खन्छु। म रिपोर्ट खोल्छु - फेरि केहि गम्भीर छैन, स्पष्ट रूपमा कसैले मेरो अगाडि उही विधि मार्फत गयो। अर्को चरण DMZ नेटवर्क भित्रका होस्टहरूले कसरी संचार गर्छन् भनेर जाँच्नु हो। यो गर्नका लागि, पहिले सामान्य Wireshark सुरु गर्नुहोस् र प्रसारण अनुरोधहरू सुन्नुहोस्, मुख्य रूपमा ARP। दिनभर एआरपी प्याकेट संकलन गरिएको थियो। यो बाहिर जान्छ कि धेरै गेटवेहरू यस खण्डमा प्रयोग गरिन्छ। यो पछि काममा आउनेछ। ARP अनुरोधहरू र प्रतिक्रियाहरू र पोर्ट स्क्यानिङ डेटामा डेटा संयोजन गरेर, मैले वेब र मेल जस्ता पहिले ज्ञात सेवाहरू बाहेक स्थानीय नेटवर्क भित्रबाट प्रयोगकर्ता ट्राफिकको निकास बिन्दुहरू फेला पारें।

यस क्षणमा मसँग अन्य प्रणालीहरूमा पहुँच छैन र कर्पोरेट सेवाहरूको लागि एउटै खाता छैन, यो ARP स्पूफिंग प्रयोग गरेर ट्राफिकबाट कम्तिमा केही खाता बाहिर निकाल्ने निर्णय गरियो।

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

1. राम्रो: धेरै प्रमाणहरू समातिए र समग्र रूपमा आक्रमणले काम गर्यो।
2. खराब: सबै प्रमाणहरू ग्राहकको आफ्नै ग्राहकहरूबाट थिए। समर्थन सेवाहरू प्रदान गर्दा, ग्राहक विशेषज्ञहरू ग्राहकहरूको सेवाहरूमा जडान भएका छन् जसले सधैं ट्राफिक एन्क्रिप्शन कन्फिगर नगरेका छन्।

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

मैले ट्राफिकबाट पत्रहरू सङ्कलन गर्ने एउटा रमाइलो अवसर पनि फेला पारेको छु, यो जस्तै। यो हाम्रो ग्राहकबाट उसको ग्राहकको SMTP पोर्टमा फेरि, बिना ईन्क्रिप्शन गएको तयार पत्रको उदाहरण हो। एक निश्चित एन्ड्रीले कागजातहरू पुन: पठाउनको लागि आफ्नो नाम सोध्छन्, र यसलाई क्लाउड डिस्कमा लगइन, पासवर्ड र एउटा प्रतिक्रिया पत्रमा लिङ्कको साथ अपलोड गरिएको छ:

यो सबै सेवाहरू इन्क्रिप्ट गर्न अर्को रिमाइन्डर हो। यो अज्ञात छ कि कसले र कहिले तपाइँको डाटा विशेष गरी पढ्छ र प्रयोग गर्दछ - प्रदायक, अर्को कम्पनीको प्रणाली प्रशासक, वा यस्तो पेन्टेस्टर। म यस तथ्यको बारेमा मौन छु कि धेरै व्यक्तिहरूले अनइन्क्रिप्टेड ट्राफिकलाई रोक्न सक्छन्।

स्पष्ट सफलताको बावजुद, यसले हामीलाई लक्ष्यको नजिक ल्याउन सकेन। यो सम्भव थियो, निस्सन्देह, लामो समय सम्म बस्न र बहुमूल्य जानकारी माछा माछा, तर यो त्यहाँ देखा पर्नेछ भन्ने तथ्य छैन, र आक्रमण आफै नेटवर्क को अखण्डता को मामला मा धेरै जोखिमपूर्ण छ।

सेवाहरूमा अर्को खन्ने पछि, एक रोचक विचार दिमागमा आयो। त्यहाँ एउटा यस्तो उपयोगिता छ जसलाई रेस्पोन्डर भनिन्छ (यस नामबाट प्रयोगको उदाहरणहरू फेला पार्न सजिलो छ), जसले "विषाक्त" प्रसारण अनुरोधहरू, SMB, HTTP, LDAP, आदि जस्ता विभिन्न प्रोटोकलहरू मार्फत जडानहरू भड्काउँछ। विभिन्न तरिकामा, त्यसपछि प्रमाणीकरण गर्न जडान गर्ने सबैलाई सोध्छ र यसलाई सेट अप गर्दछ ताकि प्रमाणीकरण NTLM मार्फत हुन्छ र पीडितलाई पारदर्शी मोडमा हुन्छ। प्रायः, एक आक्रमणकारीले यस तरिकाले NetNTLMv2 ह्यान्डशेकहरू सङ्कलन गर्दछ र तिनीहरूबाट, शब्दकोश प्रयोग गरेर, प्रयोगकर्ता डोमेन पासवर्डहरू छिटो पुनःप्राप्त गर्दछ। यहाँ म केहि समान चाहन्थे, तर प्रयोगकर्ताहरू "पर्खाल पछाडि" बसेका थिए, वा बरु, तिनीहरू फायरवालद्वारा अलग थिए, र ब्लू कोट प्रोक्सी क्लस्टर मार्फत WEB पहुँच गरे।

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

अद्भुत इन्टरसेप्टर-एनजी उपयोगिता उद्धारमा आयो (धन्यवाद इन्टरसेप्टर)। यसले तपाईंलाई उडानमा ट्राफिक परिवर्तन गर्न अनुमति दियो र Windows 2003 मा राम्रो काम गर्‍यो। यसले ट्राफिक प्रवाहमा JavaScript फाइलहरू मात्र परिमार्जन गर्नको लागि छुट्टै प्रकार्यता पनि थियो। एक प्रकारको विशाल क्रस-साइट स्क्रिप्टिङ योजना गरिएको थियो।

ब्लू कोट प्रोक्सीहरू, जसको माध्यमबाट प्रयोगकर्ताहरूले विश्वव्यापी WEB पहुँच गरे, आवधिक रूपमा स्थिर सामग्री क्यास गर्नुहोस्। ट्राफिक अवरोध गरेर, यो स्पष्ट थियो कि तिनीहरू चौबीसै घण्टा काम गरिरहेका थिए, अनन्त रूपमा पीक घण्टामा सामग्रीको प्रदर्शनलाई गति दिन बारम्बार प्रयोग गरिएको स्थिर अनुरोध गर्दै। थप रूपमा, BlueCoat को एक विशिष्ट प्रयोगकर्ता-एजेन्ट थियो, जसले यसलाई वास्तविक प्रयोगकर्ताबाट स्पष्ट रूपमा छुट्यायो।

जाभास्क्रिप्ट तयार गरिएको थियो, जुन, इन्टरसेप्टर-एनजी प्रयोग गरेर, ब्लु कोटका लागि JS फाइलहरूसँग प्रत्येक प्रतिक्रियाको लागि रातमा एक घण्टाको लागि लागू गरिएको थियो। स्क्रिप्टले निम्न गर्यो:

• प्रयोगकर्ता-एजेन्ट द्वारा हालको ब्राउजर निर्धारण। यदि यो इन्टरनेट एक्सप्लोरर, एज वा क्रोम थियो भने, यसले काम गर्न जारी राख्यो।
• मैले पृष्ठको DOM गठन नभएसम्म पर्खें।
• फारमको src विशेषताको साथ DOM मा अदृश्य छवि सम्मिलित गरियो preobrazhensky:8080/NNNNNN.png, जहाँ NNN मनमानी संख्याहरू हुन् ताकि BlueCoat ले यसलाई क्यास गर्दैन।
• इंजेक्शन पूरा भयो र अब छविहरू सम्मिलित गर्न आवश्यक छैन भनेर संकेत गर्न ग्लोबल फ्ल्याग चर सेट गर्नुहोस्।

ब्राउजरले यो छवि लोड गर्ने प्रयास गर्‍यो; सम्झौता गरिएको सर्भरको पोर्ट 8080 मा, एउटा TCP टनेल मेरो ल्यापटपमा यसको लागि पर्खिरहेको थियो, जहाँ उही रिस्पोन्डर चलिरहेको थियो, ब्राउजरलाई NTLM मार्फत लग इन गर्न आवश्यक छ।

रिस्पोन्डर लगहरू द्वारा न्याय गर्दै, मानिसहरू बिहान काममा आए, तिनीहरूको वर्कस्टेशनहरू खोले, त्यसपछि सामूहिक र अनावस्यक यूरोलोजिस्टको सर्भरमा जान थाले, NTLM ह्यान्डशेकहरू "नाली" गर्न नबिर्सन। दिनभर ह्यान्डशेकको वर्षा भयो र पासवर्डहरू रिकभर गर्नको लागि स्पष्ट रूपमा सफल आक्रमणको लागि स्पष्ट रूपमा सामग्री जम्मा भयो। यो के हो प्रतिक्रियाकर्ता लगहरू जस्तो देखिन्थ्यो:

प्रयोगकर्ताहरूद्वारा युरोलोजिस्ट सर्भरमा सामूहिक गोप्य भ्रमणहरू

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

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

भाग 3. Roskomnadzor पछाडि प्रहार गर्दछ

त्यसोभए, पहिलो डोमेन खाताहरू प्राप्त भयो। यदि तपाईं लामो पढेर यस बिन्दुमा सुत्नु भएको छैन भने, तपाईंले सायद याद गर्नुहुनेछ कि मैले एउटा सेवा उल्लेख गरेको छु जसलाई प्रमाणीकरणको दोस्रो कारक आवश्यक पर्दैन: यो NTLM प्रमाणीकरण भएको विकी हो। निस्सन्देह, त्यहाँ प्रवेश गर्न पहिलो कुरा थियो। आन्तरिक ज्ञानको आधारमा उत्खननले चाँडै नतिजाहरू ल्यायो:

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

अवश्य पनि, एक "दोस्रो कारक" तुरुन्तै मेरो फोनमा एक अनुप्रयोगको रूपमा सम्झौता खातामा थपियो। त्यहाँ एउटा कार्यक्रम थियो जसले या त चर्को स्वरमा फोनमा "अनुमोदन"/"अस्वीकृति" बटनहरू प्रयोग गरी पुश अनुरोध पठाउन सक्छ, वा चुपचाप थप स्वतन्त्र प्रविष्टिको लागि स्क्रिनमा OTP कोड देखाउन सक्छ। यसबाहेक, निर्देशनहरू द्वारा पहिलो विधि मात्र सही भएको मानिएको थियो, तर OTP विधिको विपरीत यसले काम गरेन।

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

यस दुर्लभ शटमा तपाईले देख्न सक्नुहुन्छ कि कसरी Roskomnadzor penesters लाई मद्दत गर्दछ

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

Citrix Netscaler सँग परिचित जो कोहीले कल्पना गर्दछ कि यो सामान्यतया यस्तो तरिकाले कार्यान्वयन गरिन्छ कि प्रयोगकर्तालाई केवल एक तस्वीर इन्टरफेस बताउन सकिन्छ, उसलाई तेस्रो-पक्ष अनुप्रयोगहरू सुरु गर्न र डेटा स्थानान्तरण गर्न उपकरणहरू नदिने प्रयास गर्दै, हरेक सम्भावित तरिकामा कार्यहरू सीमित गर्दै। मानक नियन्त्रण गोलाहरू मार्फत। मेरो "पीडित", उसको पेशाको कारणले, केवल 1C प्राप्त भयो:

1C इन्टरफेसको वरिपरि अलिकति हिँडेपछि, मैले त्यहाँ बाह्य प्रशोधन मोड्युलहरू छन् भनेर फेला पारे। तिनीहरू इन्टरफेसबाट लोड गर्न सकिन्छ, र तिनीहरू अधिकार र सेटिङहरूमा निर्भर गर्दछ, ग्राहक वा सर्भरमा कार्यान्वयन गरिनेछ।

मैले मेरा 1C प्रोग्रामर साथीहरूलाई स्ट्रिङ स्वीकार गर्ने र कार्यान्वयन गर्ने प्रक्रिया सिर्जना गर्न सोधें। 1C भाषामा, प्रक्रिया सुरु गर्दा यस्तो देखिन्छ (इन्टरनेटबाट लिइएको)। के तपाईं सहमत हुनुहुन्छ कि 1C भाषाको सिन्ट्याक्सले रूसी भाषा बोल्ने मानिसहरूलाई यसको सहजताको साथ छक्क पार्छ?

प्रशोधन पूर्ण रूपमा निष्पादित गरिएको थियो; यो पेन्टेस्टरहरूले "शेल" लाई बोलाउने कुरा हो - इन्टरनेट एक्सप्लोरर यसको माध्यमबाट सुरु गरिएको थियो।

पहिले, प्रणालीको ठेगाना जसले तपाईंलाई इलाकामा पासहरू अर्डर गर्न अनुमति दिन्छ मेलमा फेला पर्यो। मैले WiFi आक्रमण भेक्टर प्रयोग गर्नुपर्‍यो भने मैले पास अर्डर गरें।

इन्टरनेटमा कुराकानी छ कि त्यहाँ अझै पनि ग्राहकको कार्यालयमा स्वादिष्ट नि: शुल्क खानपान थियो, तर मैले अझै पनि टाढाबाट आक्रमण विकास गर्न रुचाउँछु, यो शान्त छ।

AppLocker Citrix चलिरहेको अनुप्रयोग सर्भरमा सक्रिय गरिएको थियो, तर यसलाई बाइपास गरिएको थियो। उही Meterpreter लोड गरिएको थियो र DNS मार्फत सुरु गरिएको थियो, किनकि http(हरू) संस्करणहरू जडान गर्न चाहँदैनन्, र मलाई त्यस समयमा आन्तरिक प्रोक्सी ठेगाना थाहा थिएन। वैसे, यस क्षण देखि, बाह्य pentest अनिवार्य रूपमा एक आन्तरिक एक मा परिणत भयो।

भाग 4. प्रयोगकर्ताहरूको लागि प्रशासक अधिकारहरू खराब छन्, ठीक छ?

डोमेन प्रयोगकर्ता सत्रको नियन्त्रण प्राप्त गर्दा पेन्टेस्टरको पहिलो कार्य डोमेनमा अधिकारहरूको बारेमा सबै जानकारी सङ्कलन गर्नु हो। त्यहाँ एक ब्लडहाउन्ड उपयोगिता छ जसले तपाईंलाई स्वचालित रूपमा डोमेन नियन्त्रकबाट LDAP प्रोटोकल मार्फत प्रयोगकर्ताहरू, कम्प्युटरहरू, सुरक्षा समूहहरू र SMB मार्फत जानकारी डाउनलोड गर्न अनुमति दिन्छ - कुन प्रयोगकर्ताले हालसालै कहाँ र को स्थानीय प्रशासक हो भन्ने बारे जानकारी।

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

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

"चक्रको अन्त्य;", जसरी 1C प्रोग्रामरहरूले यहाँ लेख्छन्।

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

• मैले त्यहाँ एउटा OpenVPN क्लाइन्ट स्थापना गरें, जसले इन्टरनेट मार्फत मेरो सर्भरमा टनेल बनायो। ग्राहकलाई डोमेन प्रमाणीकरणको साथ एउटै निलो कोट मार्फत जान बाध्य हुनुपर्‍यो, तर OpenVPN ले यो गर्‍यो, तिनीहरू भन्छन्, "बक्सबाट बाहिर।"
• VDI मा OpenSSH स्थापना गरियो। खैर, साँच्चै, SSH बिना Windows 7 के हो?

यो लाइभ जस्तो देखिन्थ्यो। मलाई तपाईलाई सम्झाउन दिनुहोस् कि यो सबै Citrix र 1C मार्फत गरिनु पर्छ:

छिमेकी कम्प्यूटरहरूमा पहुँच प्रवर्द्धन गर्ने एउटा प्रविधी भनेको मेलको लागि स्थानीय प्रशासक पासवर्डहरू जाँच गर्नु हो। यहाँ भाग्यले तुरुन्तै प्रतिक्षा गर्यो: पूर्वनिर्धारित स्थानीय प्रशासकको NTLM ह्यास (जसलाई अचानक प्रशासक भनियो) छिमेकी VDI होस्टहरूमा पास-द-ह्यास आक्रमणको माध्यमबाट सम्पर्क गरिएको थियो, जसमध्ये त्यहाँ धेरै सय थिए। निस्सन्देह, आक्रमणले तुरुन्तै उनीहरूलाई मार्यो।

यो हो जहाँ VDI प्रशासकहरूले आफैलाई खुट्टामा दुई पटक गोली हाने:

• पहिलो पटक जब VDI मेशिनहरू LAPS अन्तर्गत ल्याइएनन्, अनिवार्य रूपमा छविबाट उही स्थानीय प्रशासक पासवर्ड राख्दै जुन VDI मा व्यापक रूपमा तैनात गरिएको थियो।
• पूर्वनिर्धारित प्रशासक मात्र स्थानीय खाता हो जुन पास-द-ह्यास आक्रमणहरूको लागि कमजोर छ। एउटै पासवर्डको साथमा पनि, जटिल अनियमित पासवर्डको साथ दोस्रो स्थानीय प्रशासक खाता सिर्जना गरेर र पूर्वनिर्धारितलाई ब्लक गरेर सामूहिक सम्झौताबाट बच्न सम्भव हुनेछ।

किन त्यो Windows मा SSH सेवा? धेरै सरल: अब OpenSSH सर्भरले प्रयोगकर्ताको काममा हस्तक्षेप नगरी सुविधाजनक अन्तरक्रियात्मक कमाण्ड शेल मात्र प्रदान गर्दैन, तर VDI मा socks5 प्रोक्सी पनि। यस मोजाहरू मार्फत, मैले SMB मार्फत जडान गरें र यी सबै सयौं VDI मेसिनहरूबाट क्यास खाताहरू सङ्कलन गरें, त्यसपछि तिनीहरूलाई BloodHound ग्राफहरूमा प्रयोग गरेर डोमेन प्रशासकको बाटो खोजे। मेरो अधिकारमा सयौं होस्टहरूको साथ, मैले यो बाटो चाँडै फेला पारें। डोमेन प्रशासक अधिकार प्राप्त भएको छ।

यहाँ एक समान खोज देखाउँदै इन्टरनेटबाट एक तस्वीर छ। जडानहरूले देखाउँदछ कि प्रशासक को छ र कहाँ लग इन छ।

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

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

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

निस्सन्देह, यो लागू गर्न धेरै गाह्रो छ, तर अर्को लेखमा हामी व्यवहारमा देखाउनेछौं कि यो एकदम सम्भव छ।

स्रोत: www.habr.com