Az - Federation
Grundlegende Informationen
Aus den Dokumenten:Federation ist eine Sammlung von Domänen, die Vertrauen aufgebaut haben. Das Vertrauensniveau kann variieren, umfasst jedoch typischerweise Authentifizierung und fast immer Autorisierung. Eine typische Federation könnte eine Anzahl von Organisationen umfassen, die Vertrauen für den gemeinsamen Zugriff auf eine Reihe von Ressourcen aufgebaut haben.
Sie können Ihre On-Premises-Umgebung mit Azure AD föderieren und diese Federation für Authentifizierung und Autorisierung verwenden. Diese Anmeldemethode stellt sicher, dass alle Benutzerauthentifizierungen vor Ort erfolgen. Diese Methode ermöglicht Administratoren die Implementierung strengerer Zugriffskontrollen. Federation mit AD FS und PingFederate ist verfügbar.
Grundsätzlich erfolgt bei der Federation alle Authentifizierung in der On-Prem-Umgebung und der Benutzer erlebt SSO in allen vertrauenswürdigen Umgebungen. Daher können Benutzer Cloud-Anwendungen mit ihren On-Prem-Anmeldeinformationen zugreifen.
Security Assertion Markup Language (SAML) wird verwendet, um alle Authentifizierungs- und Autorisierungsinformationen zwischen den Anbietern auszutauschen.
In jeder Federation-Setup gibt es drei Parteien:
Benutzer oder Client
Identity Provider (IdP)
Service Provider (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 (Service Provider oder SP, wie AWS-Konsole oder vSphere-Webclient) zu. Dieser Schritt kann umgangen werden, indem der Client je nach spezifischer Implementierung direkt zum IdP (Identity Provider) geleitet wird.
Anschließend identifiziert der SP den entsprechenden 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 eine SAMLResponse vom IdP erstellt und über den Benutzer an den SP weitergeleitet.
Schließlich bewertet der SP die SAMLResponse. Wenn sie erfolgreich validiert wird, was eine Vertrauensbeziehung mit dem IdP impliziert, wird dem Benutzer der Zugriff gewährt. Dies markiert den Abschluss des Anmeldeprozesses und ermöglicht dem Benutzer die Nutzung des Dienstes.
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.
"..claims sind einfach Aussagen (zum Beispiel Name, Identität, Gruppe), die über Benutzer gemacht werden und hauptsächlich zur Autorisierung des Zugriffs auf claims-basierte Anwendungen verwendet werden, die sich überall im Internet befinden."
Claims 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.
Die ImmutableID wird vor Ort 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 vom AD FS-Server mit DA-Berechtigungen extrahiert und dann von jeder internetverbundenen Maschine aus verwendet werden.
Golden SAML
Der Prozess, bei dem ein Identity Provider (IdP) eine SAMLResponse zur Autorisierung der Benutzeranmeldung erstellt, ist von entscheidender Bedeutung. Abhängig von der spezifischen Implementierung des IdP kann die Antwort mit dem privaten Schlüssel des IdP signiert oder verschlüsselt werden. Dieses Verfahren ermöglicht es dem Service Provider (SP), die Authentizität 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 golden tickets, privater Token-Signaturschlüssel für golden SAML) manipuliert werden kann, um ein Authentifizierungsobjekt (TGT oder SAMLResponse) zu fälschen. Dies ermöglicht die Nachahmung 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 Federation zu sein.
Sie bleiben auch bei aktivierter Zwei-Faktor-Authentifizierung (2FA) wirksam.
Der Token-Signatur-private Schlüssel erneuert sich nicht automatisch.
Ändern des Benutzerpassworts macht einen bereits generierten 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 (Federation) erleichtert. Es ermöglicht im Wesentlichen einem Domänendienst, Benutzeridentitäten mit anderen Dienstanbietern innerhalb einer Federation zu teilen.
Da AWS der kompromittierten Domäne (in einer Federation) vertraut, 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 der 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 golden SAML Angriffs umfassen:
Token-Signatur privater Schlüssel
IdP öffentliches Zertifikat
IdP Name
Rollenname (Rolle zu übernehmen)
Domäne\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 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 sicherstellen, dass Sie als ADFS-Benutzer angemeldet sind:
Mit all diesen Informationen ist es möglich, eine gültige SAMLResponse als den Benutzer, den Sie imitieren möchten, mit shimit zu vergessen**:**
On-prem -> cloud
Es ist auch möglich, ImmutableID von nur Cloud-Benutzern zu erstellen und sie zu imitieren.
Referenzen
Last updated