AD CS Domain Escalation
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
यह पदों के उत्थान तकनीक अनुभागों का सारांश है:
Misconfigured Certificate Templates - ESC1
Explanation
Misconfigured Certificate Templates - ESC1 Explained
Enterprise CA द्वारा निम्न-विशिष्ट उपयोगकर्ताओं को नामांकन अधिकार दिए जाते हैं।
प्रबंधक की स्वीकृति की आवश्यकता नहीं है।
अधिकृत व्यक्तियों से कोई हस्ताक्षर आवश्यक नहीं हैं।
प्रमाणपत्र टेम्पलेट्स पर सुरक्षा विवरण अत्यधिक अनुमति देने वाले हैं, जो निम्न-विशिष्ट उपयोगकर्ताओं को नामांकन अधिकार प्राप्त करने की अनुमति देते हैं।
प्रमाणपत्र टेम्पलेट्स को EKUs को परिभाषित करने के लिए कॉन्फ़िगर किया गया है जो प्रमाणीकरण को सुविधाजनक बनाते हैं:
Extended Key Usage (EKU) पहचानकर्ता जैसे Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), या कोई EKU (SubCA) शामिल हैं।
प्रमाणपत्र हस्ताक्षर अनुरोध (CSR) में subjectAltName शामिल करने की क्षमता टेम्पलेट द्वारा अनुमति दी गई है:
Active Directory (AD) पहचान सत्यापन के लिए प्रमाणपत्र में subjectAltName (SAN) को प्राथमिकता देता है यदि यह मौजूद है। इसका मतलब है कि CSR में SAN निर्दिष्ट करके, किसी भी उपयोगकर्ता (जैसे, एक डोमेन प्रशासक) का अनुकरण करने के लिए एक प्रमाणपत्र अनुरोध किया जा सकता है। यह संकेत दिया गया है कि क्या अनुरोधकर्ता द्वारा SAN निर्दिष्ट किया जा सकता है प्रमाणपत्र टेम्पलेट के AD ऑब्जेक्ट में
mspki-certificate-name-flagप्रॉपर्टी के माध्यम से। यह प्रॉपर्टी एक बिटमास्क है, औरCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTध्वज की उपस्थिति अनुरोधकर्ता द्वारा SAN के निर्दिष्ट करने की अनुमति देती है।
यह कॉन्फ़िगरेशन निम्न-विशिष्ट उपयोगकर्ताओं को किसी भी पसंद के SAN के साथ प्रमाणपत्र अनुरोध करने की अनुमति देता है, जो Kerberos या SChannel के माध्यम से किसी भी डोमेन प्रिंसिपल के रूप में प्रमाणीकरण सक्षम करता है।
यह सुविधा कभी-कभी HTTPS या होस्ट प्रमाणपत्रों के तात्कालिक निर्माण का समर्थन करने के लिए उत्पादों या तैनाती सेवाओं द्वारा सक्षम की जाती है, या समझ की कमी के कारण।
यह नोट किया गया है कि इस विकल्प के साथ प्रमाणपत्र बनाने पर एक चेतावनी उत्पन्न होती है, जो तब नहीं होती जब एक मौजूदा प्रमाणपत्र टेम्पलेट (जैसे WebServer टेम्पलेट, जिसमें CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT सक्षम है) को डुप्लिकेट किया जाता है और फिर प्रमाणीकरण OID शामिल करने के लिए संशोधित किया जाता है।
Abuse
कमजोर प्रमाणपत्र टेम्पलेट्स खोजने के लिए आप चला सकते हैं:
इस कमजोरी का दुरुपयोग करके एक प्रशासक की नकल करने के लिए कोई निम्नलिखित चला सकता है:
फिर आप उत्पन्न प्रमाणपत्र को .pfx प्रारूप में परिवर्तित कर सकते हैं और इसे Rubeus या certipy का उपयोग करके फिर से प्रमाणित करने के लिए उपयोग कर सकते हैं:
The Windows binaries "Certreq.exe" & "Certutil.exe" can be used to generate the PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
AD Forest के कॉन्फ़िगरेशन स्कीमा के भीतर प्रमाणपत्र टेम्पलेट्स की गणना, विशेष रूप से वे जो अनुमोदन या हस्ताक्षरों की आवश्यकता नहीं रखते हैं, जिनमें Client Authentication या Smart Card Logon EKU है, और जिनमें CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT ध्वज सक्षम है, निम्नलिखित LDAP क्वेरी चलाकर की जा सकती है:
Misconfigured Certificate Templates - ESC2
Explanation
दूसरा दुरुपयोग परिदृश्य पहले वाले का एक रूपांतर है:
Enterprise CA द्वारा निम्न-विशिष्ट उपयोगकर्ताओं को नामांकन अधिकार दिए जाते हैं।
प्रबंधक की स्वीकृति की आवश्यकता को अक्षम किया गया है।
अधिकृत हस्ताक्षरों की आवश्यकता को छोड़ दिया गया है।
प्रमाणपत्र टेम्पलेट पर एक अत्यधिक अनुमति देने वाला सुरक्षा वर्णनकर्ता निम्न-विशिष्ट उपयोगकर्ताओं को प्रमाणपत्र नामांकन अधिकार प्रदान करता है।
प्रमाणपत्र टेम्पलेट को Any Purpose EKU या कोई EKU शामिल करने के लिए परिभाषित किया गया है।
Any Purpose EKU एक हमलावर को किसी भी उद्देश्य के लिए प्रमाणपत्र प्राप्त करने की अनुमति देता है, जिसमें क्लाइंट प्रमाणीकरण, सर्वर प्रमाणीकरण, कोड साइनिंग, आदि शामिल हैं। ESC3 के लिए उपयोग की गई तकनीक का उपयोग इस परिदृश्य का लाभ उठाने के लिए किया जा सकता है।
कोई EKUs नहीं होने वाले प्रमाणपत्र, जो अधीनस्थ CA प्रमाणपत्र के रूप में कार्य करते हैं, को किसी भी उद्देश्य के लिए दुरुपयोग किया जा सकता है और नए प्रमाणपत्रों पर हस्ताक्षर करने के लिए भी उपयोग किया जा सकता है। इसलिए, एक हमलावर एक अधीनस्थ CA प्रमाणपत्र का उपयोग करके नए प्रमाणपत्रों में मनमाने EKUs या फ़ील्ड निर्दिष्ट कर सकता है।
हालांकि, डोमेन प्रमाणीकरण के लिए बनाए गए नए प्रमाणपत्र कार्य नहीं करेंगे यदि अधीनस्थ CA NTAuthCertificates ऑब्जेक्ट द्वारा विश्वसनीय नहीं है, जो डिफ़ॉल्ट सेटिंग है। फिर भी, एक हमलावर किसी भी EKU और मनमाने प्रमाणपत्र मानों के साथ नए प्रमाणपत्र बना सकता है। इन्हें संभावित रूप से कई उद्देश्यों (जैसे, कोड साइनिंग, सर्वर प्रमाणीकरण, आदि) के लिए दुरुपयोग किया जा सकता है और नेटवर्क में अन्य अनुप्रयोगों जैसे SAML, AD FS, या IPSec के लिए महत्वपूर्ण प्रभाव हो सकते हैं।
AD Forest के कॉन्फ़िगरेशन स्कीमा के भीतर इस परिदृश्य से मेल खाने वाले टेम्पलेट्स को सूचीबद्ध करने के लिए, निम्नलिखित LDAP क्वेरी चलाई जा सकती है:
Misconfigured Enrolment Agent Templates - ESC3
Explanation
यह परिदृश्य पहले और दूसरे के समान है लेकिन भिन्न EKU (Certificate Request Agent) और 2 भिन्न टेम्पलेट्स का दुरुपयोग करता है (इसलिए इसमें 2 सेट की आवश्यकताएँ हैं),
Certificate Request Agent EKU (OID 1.3.6.1.4.1.311.20.2.1), जिसे Microsoft दस्तावेज़ में Enrollment Agent के रूप में जाना जाता है, एक प्रमुख को दूसरे उपयोगकर्ता की ओर से प्रमाणपत्र के लिए नामांकित करने की अनुमति देता है।
“enrollment agent” एक ऐसे टेम्पलेट में नामांकित होता है और परिणामस्वरूप प्राप्त प्रमाणपत्र का उपयोग दूसरे उपयोगकर्ता की ओर से एक CSR को सह-हस्ताक्षरित करने के लिए करता है। फिर यह सह-हस्ताक्षरित CSR को CA को भेजता है, एक टेम्पलेट में नामांकित होता है जो “की ओर से नामांकित” की अनुमति देता है, और CA “दूसरे” उपयोगकर्ता का प्रमाणपत्र प्रदान करता है।
Requirements 1:
Enterprise CA द्वारा निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार दिए जाते हैं।
प्रबंधक अनुमोदन की आवश्यकता को छोड़ दिया गया है।
अधिकृत हस्ताक्षरों की कोई आवश्यकता नहीं है।
प्रमाणपत्र टेम्पलेट का सुरक्षा वर्णन excessively permissive है, जो निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार प्रदान करता है।
प्रमाणपत्र टेम्पलेट में Certificate Request Agent EKU शामिल है, जो अन्य प्रमुखों की ओर से अन्य प्रमाणपत्र टेम्पलेट्स के अनुरोध की अनुमति देता है।
Requirements 2:
Enterprise CA निम्न-privileged उपयोगकर्ताओं को नामांकन अधिकार प्रदान करता है।
प्रबंधक अनुमोदन को बायपास किया गया है।
टेम्पलेट का स्कीमा संस्करण 1 है या 2 से अधिक है, और यह एक Application Policy Issuance Requirement निर्दिष्ट करता है जो Certificate Request Agent EKU की आवश्यकता है।
प्रमाणपत्र टेम्पलेट में परिभाषित EKU डोमेन प्रमाणीकरण की अनुमति देता है।
CA पर नामांकन एजेंटों के लिए प्रतिबंध लागू नहीं होते हैं।
Abuse
आप इस परिदृश्य का दुरुपयोग करने के लिए Certify या Certipy का उपयोग कर सकते हैं:
The उपयोगकर्ता जिन्हें नामांकन एजेंट प्रमाणपत्र प्राप्त करने की अनुमति है, उन टेम्पलेट्स में जिनमें नामांकन एजेंट नामांकित होने की अनुमति है, और खाते जिनके behalf पर नामांकन एजेंट कार्य कर सकता है, को एंटरप्राइज CA द्वारा सीमित किया जा सकता है। यह certsrc.msc स्नैप-इन को खोलकर, CA पर राइट-क्लिक करके, गुण पर क्लिक करके, और फिर “Enrollment Agents” टैब पर नेविगेट करके प्राप्त किया जाता है।
हालांकि, यह नोट किया गया है कि CA के लिए डिफ़ॉल्ट सेटिंग “नामांकन एजेंटों को प्रतिबंधित न करें” है। जब नामांकन एजेंटों पर प्रतिबंध को प्रशासकों द्वारा सक्षम किया जाता है, तो इसे “Restrict enrollment agents” पर सेट करने से डिफ़ॉल्ट कॉन्फ़िगरेशन अत्यधिक अनुमति देने वाला बना रहता है। यह सभी को किसी भी टेम्पलेट में नामांकित होने की अनुमति देता है।
Vulnerable Certificate Template Access Control - ESC4
व्याख्या
प्रमाणपत्र टेम्पलेट्स पर सुरक्षा वर्णनकर्ता उन अनुमतियों को परिभाषित करता है जो विशिष्ट AD प्रिंसिपल टेम्पलेट के संबंध में रखते हैं।
यदि एक हमलावर के पास टेम्पलेट को बदलने और पिछले अनुभागों में उल्लिखित किसी भी शोषण योग्य गलत कॉन्फ़िगरेशन को लागू करने के लिए आवश्यक अनुमतियाँ हैं, तो विशेषाधिकार वृद्धि को सक्षम किया जा सकता है।
प्रमाणपत्र टेम्पलेट्स पर लागू होने वाली महत्वपूर्ण अनुमतियाँ शामिल हैं:
Owner: वस्तु पर निहित नियंत्रण प्रदान करता है, जिससे किसी भी विशेषता को संशोधित करने की अनुमति मिलती है।
FullControl: वस्तु पर पूर्ण अधिकार प्रदान करता है, जिसमें किसी भी विशेषता को बदलने की क्षमता शामिल है।
WriteOwner: हमलावर के नियंत्रण में एक प्रिंसिपल के लिए वस्तु के मालिक को बदलने की अनुमति देता है।
WriteDacl: पहुँच नियंत्रण को समायोजित करने की अनुमति देता है, संभावित रूप से हमलावर को FullControl प्रदान करता है।
WriteProperty: किसी भी वस्तु की संपत्तियों को संपादित करने की अनुमति देता है।
दुरुपयोग
पिछले एक की तरह एक प्रिवेस्क का उदाहरण:
ESC4 तब होता है जब एक उपयोगकर्ता के पास एक प्रमाणपत्र टेम्पलेट पर लिखने के अधिकार होते हैं। इसे उदाहरण के लिए प्रमाणपत्र टेम्पलेट की कॉन्फ़िगरेशन को ओवरराइट करने के लिए दुरुपयोग किया जा सकता है ताकि टेम्पलेट ESC1 के लिए संवेदनशील हो जाए।
जैसा कि हम ऊपर के पथ में देख सकते हैं, केवल JOHNPC के पास ये अधिकार हैं, लेकिन हमारे उपयोगकर्ता JOHN के पास JOHNPC के लिए नया AddKeyCredentialLink एज है। चूंकि यह तकनीक प्रमाणपत्रों से संबंधित है, मैंने इस हमले को भी लागू किया है, जिसे Shadow Credentials के रूप में जाना जाता है। यहाँ पीड़ित के NT हैश को पुनः प्राप्त करने के लिए Certipy के shadow auto कमांड का एक छोटा पूर्वावलोकन है।
Certipy एकल कमांड के साथ एक प्रमाणपत्र टेम्पलेट की कॉन्फ़िगरेशन को ओवरराइट कर सकता है। डिफ़ॉल्ट रूप से, Certipy कॉन्फ़िगरेशन को ओवरराइट करेगा ताकि यह ESC1 के लिए संवेदनशील हो जाए। हम -save-old पैरामीटर को भी निर्दिष्ट कर सकते हैं ताकि पुरानी कॉन्फ़िगरेशन को सहेज सकें, जो हमारे हमले के बाद कॉन्फ़िगरेशन को पुनर्स्थापित करने के लिए उपयोगी होगा।
Vulnerable PKI Object Access Control - ESC5
Explanation
ACL-आधारित संबंधों का विस्तृत जाल, जिसमें प्रमाणपत्र टेम्पलेट और प्रमाणपत्र प्राधिकरण के अलावा कई वस्तुएं शामिल हैं, AD CS प्रणाली की सुरक्षा को प्रभावित कर सकता है। ये वस्तुएं, जो सुरक्षा को महत्वपूर्ण रूप से प्रभावित कर सकती हैं, में शामिल हैं:
CA सर्वर का AD कंप्यूटर ऑब्जेक्ट, जिसे S4U2Self या S4U2Proxy जैसे तंत्रों के माध्यम से समझौता किया जा सकता है।
CA सर्वर का RPC/DCOM सर्वर।
विशेष कंटेनर पथ
CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>के भीतर कोई भी वंशज AD ऑब्जेक्ट या कंटेनर। इस पथ में, लेकिन सीमित नहीं है, प्रमाणपत्र टेम्पलेट्स कंटेनर, प्रमाणन प्राधिकरणों का कंटेनर, NTAuthCertificates ऑब्जेक्ट, और नामांकन सेवाओं का कंटेनर शामिल हैं।
यदि एक निम्न-विशिष्टता वाला हमलावर इन महत्वपूर्ण घटकों में से किसी पर नियंत्रण प्राप्त करने में सफल होता है, तो PKI प्रणाली की सुरक्षा समझौता की जा सकती है।
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Explanation
CQure Academy पोस्ट में चर्चा किए गए विषय में EDITF_ATTRIBUTESUBJECTALTNAME2 ध्वज के प्रभावों पर भी प्रकाश डाला गया है, जैसा कि Microsoft द्वारा वर्णित किया गया है। यह कॉन्फ़िगरेशन, जब एक प्रमाणन प्राधिकरण (CA) पर सक्रिय किया जाता है, तो किसी भी अनुरोध के लिए विभव-परिभाषित मानों को विषय वैकल्पिक नाम में शामिल करने की अनुमति देता है, जिसमें Active Directory® से निर्मित अनुरोध भी शामिल हैं। परिणामस्वरूप, यह प्रावधान एक घुसपैठिए को किसी भी टेम्पलेट के माध्यम से नामांकन करने की अनुमति देता है जो डोमेन प्रमाणीकरण के लिए सेट किया गया है—विशेष रूप से वे जो निम्न-विशिष्टता उपयोगकर्ता नामांकन के लिए खुले हैं, जैसे कि मानक उपयोगकर्ता टेम्पलेट। इसके परिणामस्वरूप, एक प्रमाणपत्र सुरक्षित किया जा सकता है, जिससे घुसपैठिए को डोमेन प्रशासक के रूप में या डोमेन के भीतर किसी अन्य सक्रिय इकाई के रूप में प्रमाणीकरण करने की अनुमति मिलती है।
Note: एक प्रमाणपत्र हस्ताक्षर अनुरोध (CSR) में वैकल्पिक नामों को जोड़ने के लिए -attrib "SAN:" तर्क के माध्यम से certreq.exe में उपयोग की जाने वाली विधि (जिसे "नाम मान जोड़े" के रूप में संदर्भित किया जाता है) ESC1 में SANs के शोषण रणनीति से विभिन्नता प्रस्तुत करती है। यहाँ, भेद कैसे खाता जानकारी को संकुचित किया जाता है—एक प्रमाणपत्र विशेषता के भीतर, न कि एक विस्तार के रूप में।
Abuse
यह सत्यापित करने के लिए कि सेटिंग सक्रिय है या नहीं, संगठन निम्नलिखित कमांड का उपयोग कर सकते हैं certutil.exe के साथ:
यह ऑपरेशन मूल रूप से रिमोट रजिस्ट्री एक्सेस का उपयोग करता है, इसलिए, एक वैकल्पिक दृष्टिकोण हो सकता है:
Tools like Certify और Certipy इस गलत कॉन्फ़िगरेशन का पता लगाने और इसका लाभ उठाने में सक्षम हैं:
इन सेटिंग्स को बदलने के लिए, यह मानते हुए कि किसी के पास डोमेन प्रशासनिक अधिकार या समकक्ष हैं, निम्नलिखित कमांड किसी भी कार्यस्थल से निष्पादित किया जा सकता है:
इस कॉन्फ़िगरेशन को अपने वातावरण में अक्षम करने के लिए, ध्वज को हटाया जा सकता है:
मई 2022 के सुरक्षा अपडेट के बाद, नए जारी किए गए certificates में एक सुरक्षा विस्तार होगा जो अनुरोधकर्ता के objectSid प्रॉपर्टी को शामिल करता है। ESC1 के लिए, यह SID निर्दिष्ट SAN से निकाला गया है। हालाँकि, ESC6 के लिए, SID अनुरोधकर्ता के objectSid को दर्शाता है, न कि SAN को।
ESC6 का लाभ उठाने के लिए, यह आवश्यक है कि सिस्टम ESC10 (कमजोर प्रमाणपत्र मैपिंग) के प्रति संवेदनशील हो, जो नए सुरक्षा विस्तार की तुलना में SAN को प्राथमिकता देता है।
कमजोर प्रमाणपत्र प्राधिकरण पहुंच नियंत्रण - ESC7
हमला 1
व्याख्या
एक प्रमाणपत्र प्राधिकरण के लिए पहुंच नियंत्रण एक सेट अनुमतियों के माध्यम से बनाए रखा जाता है जो CA क्रियाओं को नियंत्रित करता है। इन अनुमतियों को certsrv.msc तक पहुँचकर, CA पर राइट-क्लिक करके, प्रॉपर्टीज़ का चयन करके, और फिर सुरक्षा टैब पर जाकर देखा जा सकता है। इसके अतिरिक्त, PSPKI मॉड्यूल का उपयोग करके अनुमतियों को निम्नलिखित कमांड के साथ सूचीबद्ध किया जा सकता है:
यह मुख्य अधिकारों, अर्थात् ManageCA और ManageCertificates के बारे में जानकारी प्रदान करता है, जो क्रमशः "CA प्रशासक" और "प्रमाणपत्र प्रबंधक" की भूमिकाओं से संबंधित हैं।
दुरुपयोग
एक प्रमाणपत्र प्राधिकरण पर ManageCA अधिकार होने से प्रमुख को PSPKI का उपयोग करके दूरस्थ रूप से सेटिंग्स को संशोधित करने की अनुमति मिलती है। इसमें EDITF_ATTRIBUTESUBJECTALTNAME2 ध्वज को टॉगल करना शामिल है ताकि किसी भी टेम्पलेट में SAN निर्दिष्ट करने की अनुमति मिल सके, जो डोमेन वृद्धि का एक महत्वपूर्ण पहलू है।
इस प्रक्रिया को PSPKI के Enable-PolicyModuleFlag cmdlet का उपयोग करके सरल बनाया जा सकता है, जो सीधे GUI इंटरैक्शन के बिना संशोधन की अनुमति देता है।
ManageCertificates अधिकारों का अधिग्रहण लंबित अनुरोधों की स्वीकृति को सुविधाजनक बनाता है, प्रभावी रूप से "CA प्रमाणपत्र प्रबंधक स्वीकृति" सुरक्षा को दरकिनार करता है।
Certify और PSPKI मॉड्यूल का संयोजन एक प्रमाणपत्र के लिए अनुरोध, स्वीकृति और डाउनलोड करने के लिए उपयोग किया जा सकता है:
Attack 2
Explanation
In the previous attack Manage CA permissions were used to enable the EDITF_ATTRIBUTESUBJECTALTNAME2 flag to perform the ESC6 attack, but this will not have any effect until the CA service (CertSvc) is restarted. When a user has the Manage CA access right, the user is also allowed to restart the service. However, it does not mean that the user can restart the service remotely. Furthermore, ESC6 might not work out of the box in most patched environments due to the May 2022 security updates.
इसलिए, यहाँ एक और हमला प्रस्तुत किया गया है।
Perquisites:
केवल
ManageCAअनुमतिManage Certificatesअनुमति (कोManageCAसे दी जा सकती है)प्रमाणपत्र टेम्पलेट
SubCAको सक्षम करना होगा (कोManageCAसे सक्षम किया जा सकता है)
यह तकनीक इस तथ्य पर निर्भर करती है कि Manage CA और Manage Certificates पहुँच अधिकार वाले उपयोगकर्ता असफल प्रमाणपत्र अनुरोध जारी कर सकते हैं। SubCA प्रमाणपत्र टेम्पलेट ESC1 के प्रति संवेदनशील है, लेकिन केवल प्रशासक टेम्पलेट में नामांकित हो सकते हैं। इसलिए, एक उपयोगकर्ता SubCA में नामांकन के लिए अनुरोध कर सकता है - जिसे अस्वीकृत किया जाएगा - लेकिन फिर बाद में प्रबंधक द्वारा जारी किया जाएगा।
Abuse
आप अपने लिए Manage Certificates पहुँच अधिकार दे सकते हैं अपने उपयोगकर्ता को एक नए अधिकारी के रूप में जोड़कर।
SubCA टेम्पलेट को -enable-template पैरामीटर के साथ CA पर सक्रिय किया जा सकता है। डिफ़ॉल्ट रूप से, SubCA टेम्पलेट सक्रिय होता है।
यदि हमने इस हमले के लिए पूर्वापेक्षाएँ पूरी कर ली हैं, तो हम SubCA टेम्पलेट के आधार पर एक प्रमाणपत्र के लिए अनुरोध करना शुरू कर सकते हैं।
यह अनुरोध अस्वीकृत कर दिया जाएगा, लेकिन हम निजी कुंजी को सहेज लेंगे और अनुरोध आईडी को नोट कर लेंगे।
हमारे Manage CA और Manage Certificates के साथ, हम फिर असफल प्रमाणपत्र अनुरोध को ca कमांड और -issue-request <request ID> पैरामीटर के साथ जारी कर सकते हैं।
और अंत में, हम req कमांड और -retrieve <request ID> पैरामीटर के साथ जारी किया गया प्रमाणपत्र प्राप्त कर सकते हैं।
NTLM Relay to AD CS HTTP Endpoints – ESC8
Explanation
उन वातावरणों में जहाँ AD CS स्थापित है, यदि एक वेब नामांकन अंत बिंदु जो कमजोर है मौजूद है और कम से कम एक प्रमाणपत्र टेम्पलेट प्रकाशित है जो डोमेन कंप्यूटर नामांकन और क्लाइंट प्रमाणीकरण की अनुमति देता है (जैसे कि डिफ़ॉल्ट Machine टेम्पलेट), तो स्पूलर सेवा सक्रिय किसी भी कंप्यूटर को एक हमलावर द्वारा समझौता किया जा सकता है!
AD CS द्वारा कई HTTP-आधारित नामांकन विधियों का समर्थन किया जाता है, जो अतिरिक्त सर्वर भूमिकाओं के माध्यम से उपलब्ध होती हैं जिन्हें प्रशासक स्थापित कर सकते हैं। HTTP-आधारित प्रमाणपत्र नामांकन के लिए ये इंटरफेस NTLM रिले हमलों के प्रति संवेदनशील होते हैं। एक हमलावर, एक समझौता किए गए मशीन से, किसी भी AD खाते का अनुकरण कर सकता है जो इनबाउंड NTLM के माध्यम से प्रमाणीकरण करता है। पीड़ित खाते का अनुकरण करते समय, इन वेब इंटरफेस को एक हमलावर द्वारा User या Machine प्रमाणपत्र टेम्पलेट्स का उपयोग करके क्लाइंट प्रमाणीकरण प्रमाणपत्र के लिए अनुरोध करने के लिए एक्सेस किया जा सकता है।
वेब नामांकन इंटरफेस (एक पुरानी ASP एप्लिकेशन जो
http://<caserver>/certsrv/पर उपलब्ध है), डिफ़ॉल्ट रूप से केवल HTTP पर सेट है, जो NTLM रिले हमलों के खिलाफ सुरक्षा प्रदान नहीं करता है। इसके अतिरिक्त, यह स्पष्ट रूप से केवल NTLM प्रमाणीकरण की अनुमति देता है अपने Authorization HTTP हेडर के माध्यम से, जिससे अधिक सुरक्षित प्रमाणीकरण विधियाँ जैसे Kerberos अनुपयुक्त हो जाती हैं।प्रमाणपत्र नामांकन सेवा (CES), प्रमाणपत्र नामांकन नीति (CEP) वेब सेवा, और नेटवर्क डिवाइस नामांकन सेवा (NDES) डिफ़ॉल्ट रूप से अपने Authorization HTTP हेडर के माध्यम से बातचीत प्रमाणीकरण का समर्थन करते हैं। बातचीत प्रमाणीकरण दोनों Kerberos और NTLM का समर्थन करता है, जिससे एक हमलावर NTLM प्रमाणीकरण में डाउनग्रेड कर सकता है रिले हमलों के दौरान। हालाँकि ये वेब सेवाएँ डिफ़ॉल्ट रूप से HTTPS सक्षम करती हैं, HTTPS अकेले NTLM रिले हमलों के खिलाफ सुरक्षा नहीं करता है। HTTPS सेवाओं के लिए NTLM रिले हमलों से सुरक्षा केवल तब संभव है जब HTTPS को चैनल बाइंडिंग के साथ जोड़ा जाए। दुर्भाग्यवश, AD CS IIS पर प्रमाणीकरण के लिए विस्तारित सुरक्षा को सक्रिय नहीं करता है, जो चैनल बाइंडिंग के लिए आवश्यक है।
NTLM रिले हमलों के साथ एक सामान्य समस्या NTLM सत्रों की संक्षिप्त अवधि और हमलावर की उन सेवाओं के साथ बातचीत करने में असमर्थता है जो NTLM साइनिंग की आवश्यकता होती है।
फिर भी, इस सीमा को एक NTLM रिले हमले का लाभ उठाकर उपयोगकर्ता के लिए एक प्रमाणपत्र प्राप्त करके पार किया जाता है, क्योंकि प्रमाणपत्र की वैधता अवधि सत्र की अवधि को निर्धारित करती है, और प्रमाणपत्र का उपयोग उन सेवाओं के साथ किया जा सकता है जो NTLM साइनिंग की आवश्यकता होती है। चुराए गए प्रमाणपत्र का उपयोग करने के निर्देशों के लिए, देखें:
AD CS Account PersistenceNTLM रिले हमलों की एक और सीमा यह है कि एक हमलावर-नियंत्रित मशीन को एक पीड़ित खाते द्वारा प्रमाणीकरण किया जाना चाहिए। हमलावर या तो इंतजार कर सकता है या इस प्रमाणीकरण को बलात्कृत करने का प्रयास कर सकता है:
Force NTLM Privileged AuthenticationAbuse
Certify’s cas सक्षम HTTP AD CS अंत बिंदुओं की सूची बनाता है:
msPKI-Enrollment-Servers प्रॉपर्टी का उपयोग एंटरप्राइज सर्टिफिकेट ऑथोरिटीज़ (CAs) द्वारा सर्टिफिकेट एनरोलमेंट सर्विस (CES) एंडपॉइंट्स को स्टोर करने के लिए किया जाता है। इन एंडपॉइंट्स को Certutil.exe टूल का उपयोग करके पार्स और लिस्ट किया जा सकता है:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Certify के साथ दुरुपयोग
Abuse with Certipy
सर्टिफिकेट के लिए अनुरोध Certipy द्वारा डिफ़ॉल्ट रूप से Machine या User टेम्पलेट के आधार पर किया जाता है, जो इस पर निर्भर करता है कि क्या रिले किया जा रहा खाता नाम $ पर समाप्त होता है। एक वैकल्पिक टेम्पलेट का निर्दिष्ट करना -template पैरामीटर का उपयोग करके किया जा सकता है।
एक तकनीक जैसे PetitPotam का उपयोग फिर प्रमाणीकरण को मजबूर करने के लिए किया जा सकता है। डोमेन नियंत्रकों के साथ काम करते समय, -template DomainController का निर्दिष्ट करना आवश्यक है।
No Security Extension - ESC9
Explanation
नया मान CT_FLAG_NO_SECURITY_EXTENSION (0x80000) के लिए msPKI-Enrollment-Flag, जिसे ESC9 के रूप में संदर्भित किया जाता है, एक प्रमाणपत्र में नए szOID_NTDS_CA_SECURITY_EXT सुरक्षा विस्तार को एम्बेड करने से रोकता है। यह ध्वज तब प्रासंगिक हो जाता है जब StrongCertificateBindingEnforcement को 1 (डिफ़ॉल्ट सेटिंग) पर सेट किया गया हो, जो 2 के सेटिंग के विपरीत है। इसका महत्व उन परिदृश्यों में बढ़ जाता है जहां Kerberos या Schannel के लिए एक कमजोर प्रमाणपत्र मैपिंग का शोषण किया जा सकता है (जैसे ESC10 में), यह देखते हुए कि ESC9 की अनुपस्थिति आवश्यकताओं को नहीं बदलेगी।
इस ध्वज के सेटिंग के महत्वपूर्ण होने की शर्तें शामिल हैं:
StrongCertificateBindingEnforcementको2पर समायोजित नहीं किया गया है (डिफ़ॉल्ट1है), याCertificateMappingMethodsमेंUPNध्वज शामिल है।प्रमाणपत्र को
msPKI-Enrollment-Flagसेटिंग के भीतरCT_FLAG_NO_SECURITY_EXTENSIONध्वज के साथ चिह्नित किया गया है।किसी भी क्लाइंट प्रमाणीकरण EKU को प्रमाणपत्र द्वारा निर्दिष्ट किया गया है।
किसी भी खाते पर
GenericWriteअनुमतियाँ उपलब्ध हैं ताकि किसी अन्य को समझौता किया जा सके।
Abuse Scenario
मान लीजिए John@corp.local के पास Jane@corp.local पर GenericWrite अनुमतियाँ हैं, जिसका लक्ष्य Administrator@corp.local को समझौता करना है। ESC9 प्रमाणपत्र टेम्पलेट, जिसमें Jane@corp.local को नामांकित करने की अनुमति है, को इसके msPKI-Enrollment-Flag सेटिंग में CT_FLAG_NO_SECURITY_EXTENSION ध्वज के साथ कॉन्फ़िगर किया गया है।
शुरुआत में, Jane का हैश Shadow Credentials का उपयोग करके प्राप्त किया जाता है, धन्यवाद John के GenericWrite:
इसके बाद, Jane का userPrincipalName Administrator में संशोधित किया जाता है, जानबूझकर @corp.local डोमेन भाग को छोड़ दिया जाता है:
यह संशोधन प्रतिबंधों का उल्लंघन नहीं करता है, यह देखते हुए कि Administrator@corp.local Administrator के userPrincipalName के रूप में अलग बना रहता है।
इसके बाद, Jane के रूप में अनुरोध किया गया ESC9 प्रमाणपत्र टेम्पलेट, जिसे कमजोर के रूप में चिह्नित किया गया है:
यह नोट किया गया है कि प्रमाणपत्र का userPrincipalName Administrator को दर्शाता है, जिसमें कोई “object SID” नहीं है।
Jane का userPrincipalName फिर से उसके मूल, Jane@corp.local में बदल दिया गया है:
प्रदत्त प्रमाणपत्र के साथ प्रमाणीकरण करने का प्रयास अब Administrator@corp.local का NT हैश देता है। कमांड में -domain <domain> शामिल होना चाहिए क्योंकि प्रमाणपत्र में डोमेन निर्दिष्ट नहीं है:
कमजोर प्रमाणपत्र मैपिंग - ESC10
व्याख्या
डोमेन नियंत्रक पर दो रजिस्ट्री कुंजी मान ESC10 द्वारा संदर्भित हैं:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannelके तहतCertificateMappingMethodsके लिए डिफ़ॉल्ट मान0x18(0x8 | 0x10) है, जो पहले0x1Fपर सेट था।HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdcके तहतStrongCertificateBindingEnforcementके लिए डिफ़ॉल्ट सेटिंग1है, जो पहले0थी।
मामला 1
जब StrongCertificateBindingEnforcement को 0 के रूप में कॉन्फ़िगर किया गया है।
मामला 2
यदि CertificateMappingMethods में UPN बिट (0x4) शामिल है।
दुरुपयोग मामला 1
जब StrongCertificateBindingEnforcement को 0 के रूप में कॉन्फ़िगर किया गया है, तो GenericWrite अनुमतियों के साथ एक खाता A का उपयोग किसी भी खाता B को समझौता करने के लिए किया जा सकता है।
उदाहरण के लिए, Jane@corp.local पर GenericWrite अनुमतियों के साथ, एक हमलावर Administrator@corp.local को समझौता करने का लक्ष्य रखता है। यह प्रक्रिया ESC9 के समान है, जो किसी भी प्रमाणपत्र टेम्पलेट का उपयोग करने की अनुमति देती है।
शुरुआत में, Jane का हैश Shadow Credentials का उपयोग करके प्राप्त किया जाता है, GenericWrite का दुरुपयोग करते हुए।
इसके बाद, Jane का userPrincipalName Administrator में बदल दिया जाता है, जानबूझकर @corp.local भाग को छोड़ दिया जाता है ताकि कोई बाधा उल्लंघन न हो।
इसके बाद, Jane के रूप में क्लाइंट प्रमाणीकरण सक्षम करने वाला एक प्रमाणपत्र अनुरोध किया जाता है, जो डिफ़ॉल्ट User टेम्पलेट का उपयोग करता है।
Jane का userPrincipalName फिर से उसके मूल, Jane@corp.local पर वापस लाया जाता है।
प्राप्त प्रमाणपत्र के साथ प्रमाणीकरण करने से Administrator@corp.local का NT हैश प्राप्त होगा, जो कि प्रमाणपत्र में डोमेन विवरण की अनुपस्थिति के कारण कमांड में डोमेन को निर्दिष्ट करने की आवश्यकता को दर्शाता है।
Abuse Case 2
CertificateMappingMethods में UPN बिट फ्लैग (0x4) होने के साथ, एक खाता A जिसके पास GenericWrite अनुमतियाँ हैं, किसी भी खाते B को समझौता कर सकता है जिसमें userPrincipalName प्रॉपर्टी नहीं है, जिसमें मशीन खाते और अंतर्निहित डोमेन प्रशासक Administrator शामिल हैं।
यहाँ, लक्ष्य DC$@corp.local को समझौता करना है, Jane के हैश को Shadow Credentials के माध्यम से प्राप्त करने के साथ, GenericWrite का लाभ उठाते हुए।
Jane का userPrincipalName फिर DC$@corp.local पर सेट किया जाता है।
एक प्रमाणपत्र क्लाइंट प्रमाणीकरण के लिए Jane के रूप में डिफ़ॉल्ट User टेम्पलेट का उपयोग करते हुए अनुरोध किया गया है।
Jane का userPrincipalName इस प्रक्रिया के बाद अपने मूल पर वापस आ जाता है।
Schannel के माध्यम से प्रमाणीकरण करने के लिए, Certipy का -ldap-shell विकल्प उपयोग किया जाता है, जो प्रमाणीकरण की सफलता को u:CORP\DC$ के रूप में दर्शाता है।
LDAP शेल के माध्यम से, set_rbcd जैसे कमांड रिसोर्स-आधारित सीमित प्रतिनिधित्व (RBCD) हमलों को सक्षम करते हैं, जो संभावित रूप से डोमेन नियंत्रक को खतरे में डाल सकते हैं।
यह कमजोरियाँ किसी भी उपयोगकर्ता खाते पर लागू होती हैं जिसमें userPrincipalName नहीं है या जहाँ यह sAMAccountName से मेल नहीं खाता, जिसमें डिफ़ॉल्ट Administrator@corp.local एक प्रमुख लक्ष्य है क्योंकि इसके पास उच्च LDAP विशेषाधिकार हैं और डिफ़ॉल्ट रूप से userPrincipalName की अनुपस्थिति है।
Relaying NTLM to ICPR - ESC11
Explanation
यदि CA Server को IF_ENFORCEENCRYPTICERTREQUEST के साथ कॉन्फ़िगर नहीं किया गया है, तो यह RPC सेवा के माध्यम से साइन किए बिना NTLM रिले हमलों को सक्षम कर सकता है। Reference in here।
आप यह देखने के लिए certipy का उपयोग कर सकते हैं कि क्या Enforce Encryption for Requests अक्षम है और certipy ESC11 कमजोरियों को दिखाएगा।
Abuse Scenario
एक रिले सर्वर सेटअप करना आवश्यक है:
नोट: डोमेन नियंत्रकों के लिए, हमें DomainController में -template निर्दिष्ट करना होगा।
या sploutchy के impacket के फोर्क का उपयोग करते हुए :
Shell access to ADCS CA with YubiHSM - ESC12
Explanation
प्रशासक प्रमाणपत्र प्राधिकरण को "Yubico YubiHSM2" जैसे बाहरी उपकरण पर संग्रहीत करने के लिए सेट कर सकते हैं।
यदि USB उपकरण CA सर्वर से USB पोर्ट के माध्यम से जुड़ा है, या यदि CA सर्वर एक वर्चुअल मशीन है तो USB उपकरण सर्वर में, YubiHSM में कुंजी उत्पन्न करने और उपयोग करने के लिए एक प्रमाणीकरण कुंजी (जिसे कभी-कभी "पासवर्ड" कहा जाता है) की आवश्यकता होती है।
यह कुंजी/पासवर्ड रजिस्ट्री में HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword के तहत स्पष्ट पाठ में संग्रहीत होती है।
यहाँ संदर्भित करें।
Abuse Scenario
यदि CA की निजी कुंजी एक भौतिक USB उपकरण पर संग्रहीत है जब आपको शेल एक्सेस मिला, तो कुंजी को पुनर्प्राप्त करना संभव है।
पहले, आपको CA प्रमाणपत्र प्राप्त करना होगा (यह सार्वजनिक है) और फिर:
अंत में, CA प्रमाणपत्र और इसके निजी कुंजी का उपयोग करके एक नया मनमाना प्रमाणपत्र बनाने के लिए certutil -sign कमांड का उपयोग करें।
OID समूह लिंक दुरुपयोग - ESC13
व्याख्या
msPKI-Certificate-Policy विशेषता प्रमाणपत्र टेम्पलेट में जारी करने की नीति को जोड़ने की अनुमति देती है। msPKI-Enterprise-Oid वस्तुएं जो नीतियों को जारी करने के लिए जिम्मेदार हैं, उन्हें PKI OID कंटेनर के कॉन्फ़िगरेशन नामकरण संदर्भ (CN=OID,CN=Public Key Services,CN=Services) में खोजा जा सकता है। एक नीति को इस वस्तु की msDS-OIDToGroupLink विशेषता का उपयोग करके एक AD समूह से जोड़ा जा सकता है, जिससे एक प्रणाली को उस उपयोगकर्ता को अधिकृत करने की अनुमति मिलती है जो प्रमाणपत्र प्रस्तुत करता है जैसे कि वह समूह का सदस्य हो। यहाँ संदर्भ।
दूसरे शब्दों में, जब एक उपयोगकर्ता को एक प्रमाणपत्र में नामांकित करने की अनुमति होती है और प्रमाणपत्र एक OID समूह से जुड़ा होता है, तो उपयोगकर्ता इस समूह के विशेषाधिकारों को विरासत में ले सकता है।
OIDToGroupLink खोजने के लिए Check-ADCSESC13.ps1 का उपयोग करें:
Abuse Scenario
एक उपयोगकर्ता अनुमति खोजें जिसे certipy find या Certify.exe find /showAllPermissions का उपयोग किया जा सके।
यदि John को VulnerableTemplate में नामांकित करने की अनुमति है, तो उपयोगकर्ता VulnerableGroup समूह के विशेषाधिकारों को विरासत में ले सकता है।
उसे केवल टेम्पलेट निर्दिष्ट करने की आवश्यकता है, उसे OIDToGroupLink अधिकारों के साथ एक प्रमाणपत्र प्राप्त होगा।
प्रमाणपत्रों के साथ जंगलों का समझौता निष्क्रिय वाणी में समझाया गया
समझौता किए गए CAs द्वारा जंगलों के विश्वासों का टूटना
क्रॉस-फॉरेस्ट नामांकन के लिए कॉन्फ़िगरेशन को अपेक्षाकृत सरल बनाया गया है। संसाधन जंगल से रूट CA प्रमाणपत्र को खाता जंगलों में प्रशासकों द्वारा प्रकाशित किया जाता है, और संसाधन जंगल से एंटरप्राइज CA प्रमाणपत्रों को प्रत्येक खाता जंगल में NTAuthCertificates और AIA कंटेनरों में जोड़ा जाता है। स्पष्ट करने के लिए, यह व्यवस्था संसाधन जंगल में CA को सभी अन्य जंगलों पर पूर्ण नियंत्रण प्रदान करती है जिनका वह PKI प्रबंधित करता है। यदि इस CA को हमलावरों द्वारा समझौता किया जाता है, तो संसाधन और खाता जंगलों में सभी उपयोगकर्ताओं के लिए प्रमाणपत्रों को उनके द्वारा जाली बनाया जा सकता है, जिससे जंगल की सुरक्षा सीमा टूट जाती है।
विदेशी प्रिंसिपलों को दिए गए नामांकन विशेषाधिकार
बहु-जंगल वातावरण में, एंटरप्राइज CAs के संबंध में सावधानी बरतने की आवश्यकता है जो प्रमाणपत्र टेम्पलेट्स प्रकाशित करते हैं जो प्रमाणीकृत उपयोगकर्ताओं या विदेशी प्रिंसिपलों (उपयोगकर्ता/समूह जो उस जंगल के बाहर हैं जिसमें एंटरप्राइज CA है) को नामांकन और संपादन अधिकार प्रदान करते हैं। एक विश्वास के पार प्रमाणीकरण के बाद, प्रमाणीकृत उपयोगकर्ताओं का SID AD द्वारा उपयोगकर्ता के टोकन में जोड़ा जाता है। इसलिए, यदि एक डोमेन में एक एंटरप्राइज CA है जिसमें एक टेम्पलेट है जो प्रमाणीकृत उपयोगकर्ताओं को नामांकन अधिकार प्रदान करता है, तो एक टेम्पलेट को एक अलग जंगल के उपयोगकर्ता द्वारा नामांकित किया जा सकता है। इसी तरह, यदि एक टेम्पलेट द्वारा एक विदेशी प्रिंसिपल को स्पष्ट रूप से नामांकन अधिकार दिए जाते हैं, तो एक क्रॉस-फॉरेस्ट एक्सेस-कंट्रोल संबंध इस प्रकार बनाया जाता है, जिससे एक जंगल के प्रिंसिपल को दूसरे जंगल के टेम्पलेट में नामांकित करने की अनुमति मिलती है।
दोनों परिदृश्य एक जंगल से दूसरे जंगल में हमले की सतह में वृद्धि की ओर ले जाते हैं। प्रमाणपत्र टेम्पलेट की सेटिंग्स का उपयोग एक हमलावर द्वारा एक विदेशी डोमेन में अतिरिक्त विशेषाधिकार प्राप्त करने के लिए किया जा सकता है।
