Az - Federation
Basic Information
From the docs: Federation एक डोमेन का संग्रह है जिसने विश्वास स्थापित किया है। विश्वास का स्तर भिन्न हो सकता है, लेकिन आमतौर पर इसमें प्रमाणीकरण शामिल होता है और लगभग हमेशा प्राधिकरण शामिल होता है। एक सामान्य संघ में कई संगठन शामिल हो सकते हैं जिन्होंने संसाधनों के एक सेट तक साझा पहुंच के लिए विश्वास स्थापित किया है।
आप अपने ऑन-प्रिमाइसेस वातावरण को Azure AD के साथ फेडरेट कर सकते हैं और प्रमाणीकरण और प्राधिकरण के लिए इस संघ का उपयोग कर सकते हैं। यह साइन-इन विधि सुनिश्चित करती है कि सभी उपयोगकर्ता प्रमाणीकरण ऑन-प्रिमाइसेस होता है। यह विधि प्रशासकों को अधिक कठोर स्तर के एक्सेस नियंत्रण को लागू करने की अनुमति देती है। AD FS और PingFederate के साथ संघ उपलब्ध है।
मूल रूप से, संघ में, सभी प्रमाणीकरण ऑन-प्रिम वातावरण में होता है और उपयोगकर्ता सभी विश्वसनीय वातावरणों में SSO का अनुभव करते हैं। इसलिए, उपयोगकर्ता अपने ऑन-प्रिम क्रेडेंशियल्स का उपयोग करके क्लाउड अनुप्रयोगों तक पहुंच सकते हैं।
Security Assertion Markup Language (SAML) का उपयोग प्रदाता के बीच सभी प्रमाणीकरण और प्राधिकरण जानकारी के आदान-प्रदान के लिए किया जाता है।
किसी भी संघ सेटअप में तीन पक्ष होते हैं:
उपयोगकर्ता या क्लाइंट
पहचान प्रदाता (IdP)
सेवा प्रदाता (SP)
(Images from https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
प्रारंभ में, एक उपयोगकर्ता द्वारा एक एप्लिकेशन (सेवा प्रदाता या SP, जैसे AWS कंसोल या vSphere वेब क्लाइंट) का उपयोग किया जाता है। इस चरण को बायपास किया जा सकता है, जिससे क्लाइंट सीधे IdP (पहचान प्रदाता) पर जा सकता है, जो विशिष्ट कार्यान्वयन पर निर्भर करता है।
इसके बाद, SP उपयोगकर्ता प्रमाणीकरण के लिए उपयुक्त IdP (जैसे, AD FS, Okta) की पहचान करता है। फिर यह एक SAML (Security Assertion Markup Language) AuthnRequest तैयार करता है और क्लाइंट को चुने हुए IdP पर पुनः निर्देशित करता है।
IdP कार्यभार संभालता है, उपयोगकर्ता को प्रमाणित करता है। प्रमाणीकरण के बाद, IdP द्वारा एक SAMLResponse तैयार किया जाता है और उपयोगकर्ता के माध्यम से SP को अग्रेषित किया जाता है।
अंत में, SP SAMLResponse का मूल्यांकन करता है। यदि सफलतापूर्वक मान्य हो जाता है, जिसका अर्थ है कि IdP के साथ एक विश्वास संबंध है, तो उपयोगकर्ता को पहुंच प्रदान की जाती है। यह लॉगिन प्रक्रिया का समापन करता है, जिससे उपयोगकर्ता सेवा का उपयोग कर सकता है।
यदि आप SAML प्रमाणीकरण और सामान्य हमलों के बारे में अधिक जानना चाहते हैं तो जाएं:
Pivoting
AD FS एक दावों-आधारित पहचान मॉडल है।
"..दावे केवल उपयोगकर्ताओं के बारे में कथन हैं (उदाहरण के लिए, नाम, पहचान, समूह), जो मुख्य रूप से इंटरनेट पर कहीं भी स्थित दावों-आधारित अनुप्रयोगों तक पहुंच को अधिकृत करने के लिए उपयोग किए जाते हैं।"
उपयोगकर्ता के लिए दावे SAML टोकन के अंदर लिखे जाते हैं और फिर IdP द्वारा गोपनीयता प्रदान करने के लिए हस्ताक्षरित होते हैं।
एक उपयोगकर्ता को ImmutableID द्वारा पहचाना जाता है। यह वैश्विक रूप से अद्वितीय है और Azure AD में संग्रहीत है।
उपयोगकर्ता के लिए ms-DS-ConsistencyGuid के रूप में ऑन-प्रिम में ImmutableID संग्रहीत होता है और/या उपयोगकर्ता के GUID से प्राप्त किया जा सकता है।
Golden SAML attack:
ADFS में, SAML प्रतिक्रिया एक टोकन-हस्ताक्षर प्रमाणपत्र द्वारा हस्ताक्षरित होती है।
यदि प्रमाणपत्र से समझौता किया जाता है, तो Azure AD के लिए किसी भी उपयोगकर्ता के रूप में प्रमाणित करना संभव है जो Azure AD के साथ सिंक किया गया है!
हमारे PTA दुरुपयोग की तरह, उपयोगकर्ता के लिए पासवर्ड परिवर्तन या MFA का कोई प्रभाव नहीं पड़ेगा क्योंकि हम प्रमाणीकरण प्रतिक्रिया को जाली बना रहे हैं।
प्रमाणपत्र को DA विशेषाधिकारों के साथ AD FS सर्वर से निकाला जा सकता है और फिर इसे किसी भी इंटरनेट से जुड़े मशीन से उपयोग किया जा सकता है।
Golden SAML
प्रक्रिया जहां एक पहचान प्रदाता (IdP) उपयोगकर्ता साइन-इन को अधिकृत करने के लिए एक SAMLResponse उत्पन्न करता है, महत्वपूर्ण है। IdP के विशिष्ट कार्यान्वयन के आधार पर, प्रतिक्रिया को IdP की निजी कुंजी का उपयोग करके हस्ताक्षरित या एन्क्रिप्टेड किया जा सकता है। यह प्रक्रिया सेवा प्रदाता (SP) को SAMLResponse की प्रामाणिकता की पुष्टि करने में सक्षम बनाती है, यह सुनिश्चित करते हुए कि यह वास्तव में एक विश्वसनीय IdP द्वारा जारी किया गया था।
गोल्डन टिकट अटैक के साथ एक समानांतर खींचा जा सकता है, जहां उपयोगकर्ता की पहचान और अनुमतियों को प्रमाणित करने वाली कुंजी (गोल्डन टिकट के लिए KRBTGT, गोल्डन SAML के लिए टोकन-हस्ताक्षर निजी कुंजी) को प्रमाणीकरण वस्तु (TGT या SAMLResponse) को जाली बनाने के लिए हेरफेर किया जा सकता है। यह किसी भी उपयोगकर्ता का प्रतिरूपण करने की अनुमति देता है, जिससे SP तक अनधिकृत पहुंच प्राप्त होती है।
गोल्डन SAML के कुछ फायदे हैं:
इन्हें दूरस्थ रूप से बनाया जा सकता है, प्रश्न में डोमेन या संघ का हिस्सा होने की आवश्यकता नहीं है।
ये टू-फैक्टर ऑथेंटिकेशन (2FA) सक्षम होने पर भी प्रभावी रहते हैं।
टोकन-हस्ताक्षर निजी कुंजी स्वचालित रूप से नवीनीकृत नहीं होती।
उपयोगकर्ता का पासवर्ड बदलने से पहले से उत्पन्न SAML अमान्य नहीं होता है।
AWS + AD FS + Golden SAML
Active Directory Federation Services (AD FS) एक Microsoft सेवा है जो विश्वसनीय व्यावसायिक भागीदारों (संघ) के बीच पहचान जानकारी के सुरक्षित आदान-प्रदान की सुविधा प्रदान करती है। यह मूल रूप से एक डोमेन सेवा को एक संघ के भीतर अन्य सेवा प्रदाताओं के साथ उपयोगकर्ता पहचान साझा करने की अनुमति देता है।
AWS के साथ समझौता किए गए डोमेन (एक संघ में) पर भरोसा करते हुए, इस भेद्यता का शोषण करके संभावित रूप से AWS वातावरण में किसी भी अनुमतियों को प्राप्त किया जा सकता है। हमले के लिए SAML वस्तुओं पर हस्ताक्षर करने के लिए उपयोग की जाने वाली निजी कुंजी की आवश्यकता होती है, जैसे कि गोल्डन टिकट हमले में KRBTGT की आवश्यकता होती है। इस निजी कुंजी को प्राप्त करने के लिए AD FS उपयोगकर्ता खाते तक पहुंच पर्याप्त है।
गोल्डन SAML हमले को निष्पादित करने के लिए आवश्यकताएँ शामिल हैं:
टोकन-हस्ताक्षर निजी कुंजी
IdP सार्वजनिक प्रमाणपत्र
IdP नाम
भूमिका नाम (भूमिका को ग्रहण करना)
डोमेन\उपयोगकर्ता नाम
AWS में भूमिका सत्र नाम
अमेज़न खाता आईडी
केवल बोल्ड में आइटम अनिवार्य हैं। अन्य को इच्छानुसार भरा जा सकता है।
निजी कुंजी प्राप्त करने के लिए, AD FS उपयोगकर्ता खाते तक पहुंच आवश्यक है। वहां से, निजी कुंजी को व्यक्तिगत स्टोर से निर्यात किया जा सकता है जैसे उपकरणों का उपयोग करके mimikatz। अन्य आवश्यक जानकारी एकत्र करने के लिए, आप Microsoft.Adfs.Powershell स्नैपिन का उपयोग कर सकते हैं, यह सुनिश्चित करते हुए कि आप ADFS उपयोगकर्ता के रूप में लॉग इन हैं:
सारी जानकारी के साथ, यह संभव है कि आप उस उपयोगकर्ता के रूप में एक वैध SAMLResponse भूल सकते हैं जिसे आप shimit का उपयोग करके प्रतिरूपित करना चाहते हैं**:**
ऑन-प्रेम -> क्लाउड
यह भी संभव है कि केवल क्लाउड उपयोगकर्ताओं का ImmutableID बनाया जाए और उनका प्रतिरूपण किया जाए।
संदर्भ
Last updated