Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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.
Du kannst deine 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)
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.
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 zum gewählten IdP weiter.
Der IdP übernimmt und authentifiziert den Benutzer. Nach der Authentifizierung wird eine SAMLResponse vom IdP formuliert und über den Benutzer an den SP weitergeleitet.
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 du mehr über SAML-Authentifizierung und gängige Angriffe erfahren möchtest, gehe zu:
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 innerhalb der SAML-Token geschrieben und dann vom IdP signiert, um Vertraulichkeit zu gewährleisten.
Ein Benutzer wird durch ImmutableID identifiziert. Sie 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.
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.
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.
Mit AWS, das 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, kannst du das Microsoft.Adfs.Powershell-Snapin wie folgt verwenden, wobei du sicherstellst, dass du als ADFS-Benutzer angemeldet bist:
Mit all den Informationen ist es möglich, eine gültige SAMLResponse als den Benutzer, den Sie nachahmen möchten, mit shimit** zu vergessen:**
Es ist auch möglich, ImmutableID von nur Cloud-Benutzern zu erstellen und sich als diese auszugeben.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
