Az - Federation
Grundlegende Informationen
Aus den Dokumenten:Föderation ist eine Sammlung von Domänen, die Vertrauen aufgebaut haben. Das Vertrauensniveau kann variieren, umfasst jedoch in der Regel Authentifizierung und beinhaltet 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 aufgebaut haben.
Sie können Ihre On-Premises-Umgebung mit Azure AD föderieren und diese Föderation für die Authentifizierung und Autorisierung verwenden. Diese Anmeldeart stellt sicher, dass alle Benutzer die Authentifizierung vor Ort durchführen. Diese Methode ermöglicht es Administratoren, strengere Zugriffskontrollen zu implementieren. Die Föderation mit AD FS und PingFederate ist verfügbar.
Grundsätzlich erfolgt in der Föderation die gesamte Authentifizierung in der On-Prem-Umgebung, und der Benutzer erlebt SSO in allen vertrauenswürdigen Umgebungen. Benutzer können daher auf Cloud-Anwendungen zugreifen, indem sie ihre On-Prem-Anmeldeinformationen verwenden.
Für den Austausch aller Authentifizierungs- und Autorisierungsinformationen zwischen den Anbietern wird das Security Assertion Markup Language (SAML) verwendet.
In jedem Föderations-Setup 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)
Zunächst greift ein Benutzer auf eine Anwendung (Dienstanbieter oder SP, wie z.B. AWS-Konsole oder vSphere-Webclient) zu. Dieser Schritt kann umgangen werden, indem der Client direkt zum IdP (Identitätsanbieter) geleitet wird, abhängig von der spezifischen Implementierung.
Anschließend identifiziert der SP den geeigneten IdP (z.B. AD FS, Okta) für die Benutzerauthentifizierung. Er erstellt dann eine SAML (Security Assertion Markup Language) AuthnRequest und leitet den Client zum ausgewählten IdP um.
Der IdP übernimmt die Authentifizierung des Benutzers. Nach der Authentifizierung wird ein SAMLResponse vom IdP formuliert und über den Benutzer an den SP weitergeleitet.
Schließlich bewertet der SP die SAMLResponse. Bei erfolgreicher Validierung, was auf eine Vertrauensbeziehung zum IdP hinweist, erhält der Benutzer Zugriff. Dies markiert den Abschluss des Anmeldevorgangs und ermöglicht es dem Benutzer, 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 claims-basiertes Identitätsmodell.
"..claimsaresimplystatements(forexample,name,identity,group), made about users, that are used primarily for authorizing access to claims-based applications located anywhere on the Internet."
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 in Azure AD gespeichert.
TheImmuatbleIDisstoredon-premasms-DS-ConsistencyGuidforthe user and/or can be derived from the GUID of the user.
Weitere Informationen unter https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims
Goldener SAML-Angriff:
Bei ADFS wird die SAML-Antwort von einem Token-Signaturzertifikat signiert.
Wenn das Zertifikat kompromittiert ist, ist es möglich, sich als BELIEBIGER Benutzer, der mit Azure AD synchronisiert ist, bei Azure AD anzumelden!
Genau wie bei unserem PTA-Missbrauch hat die Änderung des Passworts für einen Benutzer oder MFA keine Auswirkungen, da wir die Authentifizierungsantwort fälschen.
Das Zertifikat kann vom AD FS-Server mit DA-Berechtigungen extrahiert und dann von einem beliebigen mit dem Internet verbundenen Gerät verwendet werden.
Goldener SAML
Der Prozess, bei dem ein Identitätsanbieter (IdP) eine SAMLResponse zur Autorisierung der Benutzeranmeldung erstellt, ist entscheidend. Abhängig von der spezifischen Implementierung des IdP kann die Antwort mit dem privaten Schlüssel des IdP signiert oder verschlüsselt sein. Dieses Verfahren ermöglicht es dem Dienstanbieter (SP), die Echtheit der SAMLResponse zu bestätigen und sicherzustellen, dass sie tatsächlich von einem vertrauenswürdigen IdP ausgestellt wurde.
Ein Vergleich kann mit dem Golden Ticket-Angriff gezogen werden, bei dem der Schlüssel zur Authentifizierung der Identität und Berechtigungen des Benutzers (KRBTGT für Goldene Tickets, privater Schlüssel für das Token-Signieren für Golden SAML) manipuliert werden kann, um ein Authentifizierungsobjekt (TGT oder SAMLResponse) zu fälschen. Dies ermöglicht die Übernahme der Identität eines beliebigen Benutzers und gewährt unbefugten Zugriff auf den SP.
Goldene SAMLs bieten bestimmte Vorteile:
Sie können remote erstellt werden, ohne Teil der betreffenden Domäne oder Föderation zu sein.
Sie bleiben auch bei aktivierter Zwei-Faktor-Authentifizierung (2FA) wirksam.
Der private Schlüssel zum Signieren von Tokens erneuert sich nicht automatisch.
Das Ändern des Benutzerpassworts macht einen bereits generierten SAML nicht ungültig.
AWS + AD FS + Goldener 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. Es ermöglicht im Wesentlichen einem Domänendienst, Benutzeridentitäten mit anderen Dienstanbietern innerhalb einer Föderation zu teilen.
Indem AWS der kompromittierten Domäne vertraut (in einer Föderation), kann diese Schwachstelle ausgenutzt werden, um potenziell beliebige Berechtigungen in der AWS-Umgebung zu erlangen. Der Angriff erfordert den privaten Schlüssel, der zum Signieren der SAML-Objekte verwendet wird, ähnlich wie beim benötigten KRBTGT bei 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 goldenen SAML-Angriffs umfassen:
Privater Schlüssel zum Signieren von Tokens
Öffentliches Zertifikat des IdP
IdP-Name
Rollenname (zu übernehmende Rolle)
Domäne\Benutzername
Rollensitzungsname in AWS
Amazon-Konto-ID
Nur die fett gedruckten Elemente sind obligatorisch. Die anderen können nach Belieben ausgefüllt werden.
Um den privaten Schlüssel zu erhalten, ist der Zugriff auf das AD FS-Benutzerkonto erforderlich. Von dort aus kann der private Schlüssel mit Tools wie mimikatz aus dem persönlichen Speicher exportiert werden. Um die anderen erforderlichen Informationen zu sammeln, können Sie das Microsoft.Adfs.Powershell-Snapin wie folgt verwenden, wobei Sie als ADFS-Benutzer angemeldet sind:
Mit all diesen Informationen ist es möglich, eine gültige SAMLResponse als Benutzer zu vergessen, den Sie mit shimit impersonieren möchten:
On-prem -> Cloud
Es ist auch möglich, die ImmutableID von nur Cloud-Benutzern zu erstellen und sich als sie auszugeben.
Referenzen
Last updated