$query = "SELECT username FROM login WHERE username=?"; $stmt = $conn->prepare($query); $stmt->execute(array($username)); $username = $stmt->fetchColumn(); if($username == FALSE) { die(" !"); } 

1. बहुत लंबा सत्र जीवन। पूरा एक साल बहुत होता है। यदि कुकी को सफलतापूर्वक अपहरण कर लिया जाता है, तो हमलावर द्वारा उपयोगकर्ता खाते में लंबी पहुंच संभव है।
2. गुम httplly झंडा। यदि TRUE पर सेट किया जाता है, तो कुकीज़ केवल HTTP प्रोटोकॉल के माध्यम से सुलभ होगी। यही है, इस मामले में कुकीज़ जावास्क्रिप्ट जैसी स्क्रिप्टिंग भाषाओं के लिए उपलब्ध नहीं होंगी।
3. कोई कुकी हैशिंग नहीं है।
4. सुरक्षित ध्वज स्थापित करने का अभाव। सुरक्षित ध्वज इंगित करता है कि कुकी को क्लाइंट से सुरक्षित HTTPS कनेक्शन पर भेजा जाना चाहिए। यदि TRUE पर सेट किया जाता है, तो क्लाइंट से कुकी सर्वर पर तभी भेजी जाएगी जब सुरक्षित कनेक्शन स्थापित हो।

 $query = htmlentities($query, ENT_QUOTES, "UTF-8"); 

 header("Content-Type: text/html; charset=utf-8"); 

  $query = "SELECT sessions FROM login WHERE sessions=?"; $stmt = $conn->prepare($query); $stmt->execute(array($_COOKIE["user"])); $session = $stmt->fetchColumn(); if($session == TRUE) { do_login($_COOKIE["user"]); } 

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

यहां उन कमजोरियों की एक सूची दी गई है, जिन्हें इस सूची में उनकी पहचान की आवृत्ति के क्रम में पाया जा सकता है:

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

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

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



खैर, कम से कम, जाहिरा तौर पर, हमलावर को फ़िल्टरिंग को बायपास करने के लिए तथाकथित "स्क्रिप्टलेस हमलों" या परिष्कृत तकनीकों की ओर मुड़ना होगा (इस मामले में, JSFUCK करेगा), इसलिए सुरक्षा जोखिम का तथ्य इसे रद्द नहीं करेगा।

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

उम्मीदवारों की प्रतिक्रिया में इन 4 कमजोरियों का उल्लेख सीधे उनके स्कोर को प्रभावित करता है।

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

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

1. इस टोकन में एक हस्ताक्षर एल्गोरिथ्म नहीं है, इसलिए एक हमलावर टोकन के अंदर किसी भी फ़ील्ड को संशोधित करने में सक्षम है, जिसे जेडडब्ल्यूटी टोकन की अवधारणा द्वारा ग्रहण नहीं किया गया है।

2. टोकन के अंदर फ़ील्ड में स्पष्ट पाठ में उपयोगकर्ता का पासवर्ड होता है, टोकन में ऐसी जानकारी संग्रहीत करना, कम से कम, एक बुरा अभ्यास है। ज्यादातर मामलों में, आप इस तरह के फैसले से इनकार कर सकते हैं और इस तरह आपकी सुरक्षा का स्तर बढ़ सकता है।

3. एक हस्ताक्षर की कमी और टोकन के अंदर के क्षेत्रों को संशोधित करने की हमारी क्षमता को याद करते हुए, यह मानना ​​तर्कसंगत है कि isAdmin के मूल्य को बदलने से हमारे विशेषाधिकारों के विशेषाधिकार बढ़ सकते हैं।

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

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

 <ifmodule mod_headers.c> Header always set Access-Control-Allow-Origin: "https://whitelist.domain.ru" Header always set Access-Control-Allow-Methods "PUT" </ifmodule> 

 <?php header('Access-Control-Allow-Origin: “https://whitelist.domain.ru”); header('Access-Control-Allow-Methods: PUT'); ?> 

आइए, हम इस बात पर विचार करें कि दिए गए प्रश्नों में मुख्य समस्याएं क्या हैं:

1) दरअसल, उपयोगकर्ता के संख्यात्मक पहचानकर्ता "10012" अनुरोध में देखे जाने के बाद, पहला कदम यह जांचना है कि क्या किसी अन्य उपयोगकर्ता के लिए पासवर्ड बदलना संभव है? क्या यह किसी और की आईडी निर्दिष्ट करने के लिए पर्याप्त हो सकता है?
IDOR वर्ग की कमजोरियां शोषण के लिए काफी आसान हैं और अक्सर उच्च जीवन शक्ति होती है।

2) पासवर्ड बदलने का अनुरोध POST विधि से होता है, CSRF टोकन नहीं देखा जाता है, और सामग्री प्रकार "पाठ / सादा" है। ऐसा अनुरोध करने की संभावना है ।

नतीजतन, पीड़ित के पासवर्ड को बदलने के लिए, यह हमलावर के लिए उन्हें "दुर्भावनापूर्ण" लिंक पर जाने के लिए मनाने के लिए पर्याप्त है।

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

4) "वाक्य को JSON से XML में बदलने पर क्या होगा?"

तथ्य यह है कि आधुनिक रूपरेखा स्मार्ट, सर्वव्यापी हैं और विभिन्न स्वरूपों में डेटा को संसाधित कर सकते हैं। और XML को पार्स करते समय, एक खतरनाक XXE भेद्यता को अक्सर अनुमति दी जाती है। इसकी मदद से, घुसपैठिया आंतरिक नेटवर्क पर "जा सकता है", सर्वर से कॉन्फ़िगरेशन फ़ाइलों को पढ़ सकता है, और कभी-कभी आरसीई को निष्पादित कर सकता है।

५) मैं एक टिप्पणी भी देखना चाहता था कि "पासवर्ड बदलते समय पुराने के ज्ञान की जाँच क्यों नहीं की जाती है?"

"वेरिएंट नंबर 2" के लिए, इसमें एक "जाल" है - कॉर्स हेडर का उपयोग यहां किया जाता है, और अनुरोध का कंटेंट-प्रकार पहले से ही "एप्लिकेशन / जेनसन" पर सेट है।

जो गलती अभ्यर्थियों ने की, वह बहुसंख्यक फॉर्म का उत्तर है "-मूल-मूल में क्या-क्या है, इसका मतलब है कि आप किसी भी साइट से अनुरोध भेज सकते हैं!"

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

प्रश्न का उद्देश्य प्रशिक्षु की आधुनिकता के साथ परिचित (और ऐसा नहीं) तकनीक का निर्धारण करना था। आइए एक मौजूदा ट्रैफिक डंप पर आधारित संभावित परिदृश्यों को देखें:

1) एआरपी स्पूफिंग
एआरएम-स्पूफिंग, मितम हमलों को लागू करने का सबसे पुराना और आसान तरीका है। इसमें ए को होस्ट करने के लिए एक gratuitous ARP अनुरोध भेजने में शामिल है

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

अनुशंसित उपकरण: बेहतर, arpspoof

2) एलएलएमएनआर, एनबीएनएस स्पूफिंग
लिंक-स्थानीय मल्टीकास्ट नाम संकल्प और नेटबीआईओएस नाम सेवा स्थानीय नेटवर्क पर होस्टनामों को हल करने के लिए उपयोग किए जाने वाले प्रोटोकॉल हैं। DNS प्रोटोकॉल के विपरीत, कोई भी समर्पित सर्वर नहीं है जो सभी जानकारी संग्रहीत करता है; इसके बजाय, अनुरोध नेटवर्क पर सभी होस्ट पर प्रसारित किया जाता है, यदि अनुरोध में होस्टनाम डिवाइस के होस्टनाम से मेल खाता है, तो यह एक प्रतिक्रिया भेजेगा।

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

अनुशंसित उपकरण: उत्तरदाता

3) WPAD स्पूफिंग
WPAD स्पूफिंग को LLMNR और NBNS स्पूफिंग के एक विशेष मामले के लिए जिम्मेदार ठहराया जा सकता है। वेब प्रॉक्सी ऑटो डिस्कवरी प्रोटोकॉल का उपयोग HTTP प्रॉक्सी सर्वर को स्वचालित रूप से कॉन्फ़िगर करने के लिए किया जाता है।

डिवाइस wpad hostname के साथ LLMNR / NBNS अनुरोध भेजता है, संबंधित आईपी पता प्राप्त करता है, और HTTP के माध्यम से wpad.dat फ़ाइल तक पहुंचने का प्रयास करता है, जो प्रॉक्सी सेटिंग्स के बारे में जानकारी संग्रहीत करता है।

नतीजतन, एक हमलावर LLMNR / NBNS को खराब कर सकता है और पीड़ित को अपनी wpad.dat फ़ाइल प्रदान कर सकता है, परिणामस्वरूप, सभी HTTP और HTTPS ट्रैफ़िक हमलावर के माध्यम से जाएंगे।

अनुशंसित उपकरण: प्रत्युत्तर, mitm6

4) राउटर विज्ञापन
जैसा कि आप डंप से देख सकते हैं, आईपीवी 6 के साथ डिवाइस हैं जो नेटवर्क पर सक्षम हैं। नेटवर्क पर रहते हुए, आप डिफ़ॉल्ट गेटवे या DNS सर्वर को बदलने के लिए पीड़ित IPv6 रूटर विज्ञापन को संदेश भेजने का प्रयास कर सकते हैं।

राउटर विज्ञापन (आरए) संदेश SLAAC (स्टेटलेस एड्रेस ऑटोकैन्फिगरेशन) तंत्र का हिस्सा हैं, जो एक डीएचसीपीवी 6 सर्वर का उपयोग किए बिना या इसके साथ संयोजन के बिना, नेटवर्क पर स्वचालित रूप से आईपीवी 6 पते प्राप्त करने के लिए आवश्यक है। यह समय-समय पर राउटर को मल्टीकास्ट आरए संदेश भेजकर प्राप्त किया जाता है, जिसमें डिफ़ॉल्ट गेटवे पता, नेटवर्क उपसर्ग, डीएनएस सर्वर पता, डोमेन उपसर्ग होता है।

अनुशंसित उपकरण: कच्चा-पैकेट

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

अनुशंसित उपकरण: यर्सिनिया

6) HSRP स्पूफिंग
इसके अलावा, डंप में एचएसआरपी के पैकेट देखे जा सकते हैं। हॉट स्टैंडबाय राउटर प्रोटोकॉल उन राउटर की उपलब्धता को बढ़ा सकता है जो डिफ़ॉल्ट गेटवे के रूप में कार्य करते हैं। IP-, -. Hello - , . HSRP, , , HSRP .

: Yersinia

7) STP-
Spanning Tree Protocol L2- . BPDU-, , . BPDU-, , , , , , , , STP, , .

: Yersinia

, . nginx , web-, nginx web- /. nginx , , , .

, , , . , . , , .

gixy .

Gixy 4 :

1) Alias travesal:

80 :

 location /static { alias /prod_static/; } 

- , . : //host/static../etc/passwd. - alias: , /static, /prod_static/, : /prod_static/../etc/passwd, /etc/passwd. alias traversal

2) Http Splitting (CRLF injection)
nginx , , . HTTP-.
: github.com/yandex/gixy/blob/master/docs/ru/plugins/httpsplitting.md

3) -
75 «rigin» . , - , , production.host.evil.com .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/origins.md

4) add_header
nginx : add_header, , , , . CSP .
: github.com/yandex/gixy/blob/master/docs/ru/plugins/addheaderredefinition.md

---

, gixy, . :

1) 17 default_type text/html. : , , nginx Content-Type, default_type. , Content-Type: text/html. HTML- , , , XSS- .

2) POST-
29-30 , . , “” POST-. . ! SSRF , , , , .

3) php-fpm
48 , FastCGI- unix , 9000. , , . , PHP-.

4) “” CSP
production.host Content-Security-Policy, Javascript, .

5) “” CORS
76-77 CORS, , cookie .

6) , 86 . secured /managed.

7) , , , -. , , , /user/{userid} IDOR.

, , , .

, :

• ACL
• capabilities

, , :
“ , root” .

, Linux/Unix .
, “ ” — .
, , funky_test.txt

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

, Linux/Unix :

• - — “rwx” alice
• — “rw” interns
• — “rx” others

read, write, execute .

, — , :

• , read
• , read
• read

, read . , execute .

, .

, , . :

1. , ls.

2. — POSIX Access Control Lists .

c .

1

, alice interns . funny_test.txt :

 $ whoami alice $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied $ 

2

— funky_test.txt 604. bob , interns :

 $ whoami bob $ id uid=1002(bob) gid=1003(bob) groups=1003(bob),1002(interns) $ ls -la funky_test.txt -rw----r-- 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt cat: funky_test.txt: Permission denied 

alice , . , permission_denied :

 $ id uid=1001(alice) gid=1001(alice) groups=1001(alice),1002(interns) $ ls -la ----rwx--- 1 alice interns 12  4 13:00 funky_test.txt $ chmod 777 funky_test.txt $ ls -la funky_test.txt -rwxrwxrwx 1 alice interns 12  4 13:00 funky_test.txt $ cat funky_test.txt secret_pass 

bob .

, « », :

• ID effective UID —
• GID effective GID —
• others.

, — , “” , , , :

• , , others
• , , others

.

POSIX Access Control Lists

— /. , ACL, , “ + ”

POSIX ACLs, — , . ACL, .

उदाहरण

. alice funky_test.txt ,

 -rwxrw-rx 1 alice interns 12  4 13:00 funky_test.txt 

ACL. getfacl , , ACL, , ls .

 $ getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx group::rw- other::rx 

, ACL . , bob :

 setfacl -mu:bob:rwx funky_test.txt 

“ + ”

 ls -l funky_test.txt -rwxrwxr-x+ 1 alice interns 12  4 13:00 funky_test.txt 

:

 getfacl funky_test.txt # file: funky_test.txt # owner: alice # group: interns user::rwx user:bob:rwx group::rw- mask::rwx other::rx 

ACL . :

1. . effective UID effective GID — . , ACL, . , , , , , .
2. ACL mask , ACL owner, group, others

, , , — .

, ACL, , :

• ACL, ;
• , ACL, .

 1)User - 1 Account: IEUser Domain: WIN7 Host: WIN7 hex dump session key - 49 0c 38 3e f8 eb 63 88 79 0f 62 84 09 84 d2 dc 2) User - 2 Account: winwin Domain: WIN7 Host: WIN7 hex dump session key - 8d f6 1b 35 79 a3 78 d3 2e 81 09 f1 95 4f 71 0a 3) User - 3 Account: 192.192.192.29 Domain: WIN7 Host: WIN7 hex dump session key - c3 19 e0 21 1b e2 63 c6 03 9e e7 38 1b 56 f0 d1 

, , :

1. ( )
2. — /
3. ,

, :

Wireshark, Protocol Hierarchy Statistics Conversations .

Protocol Hierarchy Statistics — .



Conversations — , .





:

1. (60%) — TCP, , , SMB. Protocol hierarchy SMB 40%, TCP, , 20% SMB.
2. 192.192.192.128 192.192.192.129. SMB .

.

— SMB.

, — wireshark — ExportObject .
tcp stream . , , tcp stream , . , .

, , , , . , .

.
SMB .

NTLM- “ntlmssp”. info , 3 :



, .







Net-NTLMv2-, :

• challenge
• response

Net-NTLMv2 hashcat .

, WIN7\winwin WIN7\192.192.192.129 — , . WIN7\IEUser — , , , , , SMB.

Net-NTLM , , Wireshark. , PCredz (https://github.com/lgandx/PCredz)



IEUser ( ) hashcat.



, .

6, , SMB/NTLM , DNS .

, , NT LM NTLMv1 (Net-NTLMv1) , NTLMv2 (Net-NTLMv2) ( ).

- NT LM NTLM , NTLM NTLMv1 NTLMv2 . , . .

, NTLMv1/NTLMv2 — challenge-response . , .

NT LM — “ ” — .

:

• PassTheHash — , , . लेकिन। , NT . PassTheHash NTLMv2 — . , “” , , .
• NTLM Relay — , , NTLM. , .
• Spoofing, Windows: LLMNR, NetBios
• : MS17-010, / , .

:

• ( )
• ,
• eternalBlue
• NTLM relay
• NTLM relay — SMB
• , (ARP-spoofing, DNS )

, , , Pivoting. , , , , , .

, ping , ARP- (arp -a), (route). , netcat (nc -h), , (nc -vnz 10.0.20.3 0-1000). , , , , , , - bash, python .

— SSH-, SOCKS- SSH, .
ssh -D 1337 user@10.0.20.5 -f -N

. nmap SOCKS- proxychains .

proxychains nmap 10.0.20.0/24
nmap 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

nmap - SOCKS-. SYN- ( nmap ) SOCKS-, SOCKS- TCP- , SYN- , SYN, SYN ACK. CONNECT- (-sT), nmap SOCKS-.

nmap -sT 10.0.20.0/24 --proxy socks4://10.0.20.5:1337

, - , , . , Linux-, nmap -sT , , , , , , .

, MITM HTTPS .

, Proxy WiFi. ProxyDroid, iptables .

, Root , , ?

SSL-Pinning, , , “Frida+Objection”. , :)