Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagement (IAM) Plattform von Microsoft, die als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager dient. Azure AD implementiert das OAuth 2.0 Autorisierungsframework und das OpenID Connect (OIDC) Authentifizierungsprotokoll zur Verwaltung des Zugriffs auf Ressourcen.
Wichtige Teilnehmer in OAuth 2.0:
Ressourcenserver (RS): Schützt Ressourcen, die dem Ressourcenbesitzer gehören.
Ressourcenbesitzer (RO): Typischerweise ein Endbenutzer, der die geschützten Ressourcen besitzt.
Client-Anwendung (CA): Eine Anwendung, die im Namen des Ressourcenbesitzers Zugriff auf Ressourcen anfordert.
Autorisierungsserver (AS): Gibt Zugriffstoken an Client-Anwendungen aus, nachdem diese authentifiziert und autorisiert wurden.
Scopes und Zustimmung:
Scopes: Granulare Berechtigungen, die auf dem Ressourcenserver definiert sind und Zugriffslevel spezifizieren.
Zustimmung: Der Prozess, durch den ein Ressourcenbesitzer einer Client-Anwendung die Erlaubnis erteilt, auf Ressourcen mit bestimmten Scopes zuzugreifen.
Microsoft 365 Integration:
Microsoft 365 nutzt Azure AD für IAM und besteht aus mehreren "First-Party" OAuth-Anwendungen.
Diese Anwendungen sind tief integriert und haben oft voneinander abhängige Dienstbeziehungen.
Um die Benutzererfahrung zu vereinfachen und die Funktionalität aufrechtzuerhalten, gewährt Microsoft diesen First-Party-Anwendungen "implizite Zustimmung" oder "Vorab-Zustimmung".
Implizite Zustimmung: Bestimmte Anwendungen erhalten automatisch Zugriff auf spezifische Scopes ohne ausdrückliche Genehmigung des Benutzers oder Administrators.
Diese vorab genehmigten Scopes sind typischerweise sowohl für Benutzer als auch für Administratoren verborgen, was sie in den Standardverwaltungsoberflächen weniger sichtbar macht.
Typen von Client-Anwendungen:
Vertrauliche Clients:
Besitzen eigene Anmeldeinformationen (z. B. Passwörter oder Zertifikate).
Können sich sicher beim Autorisierungsserver authentifizieren.
Öffentliche Clients:
Haben keine einzigartigen Anmeldeinformationen.
Können sich nicht sicher beim Autorisierungsserver authentifizieren.
Sicherheitsimplikation: Ein Angreifer kann eine öffentliche Client-Anwendung nachahmen, wenn er Tokens anfordert, da es keinen Mechanismus gibt, mit dem der Autorisierungsserver die Legitimität der Anwendung überprüfen kann.
Es gibt drei Arten von Tokens, die in OIDC verwendet werden:
Zugriffstoken: Der Client präsentiert dieses Token dem Ressourcenserver, um auf Ressourcen zuzugreifen. Es kann nur für eine spezifische Kombination aus Benutzer, Client und Ressource verwendet werden und kann nicht widerrufen werden, bis es abläuft - das ist standardmäßig 1 Stunde.
ID-Tokens: Der Client erhält dieses Token vom Autorisierungsserver. Es enthält grundlegende Informationen über den Benutzer. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden.
Aktualisierungstoken: Werden dem Client mit dem Zugriffstoken bereitgestellt. Wird verwendet, um neue Zugriffs- und ID-Tokens zu erhalten. Es ist an eine spezifische Kombination aus Benutzer und Client gebunden und kann widerrufen werden. Die Standardablaufzeit beträgt 90 Tage für inaktive Aktualisierungstoken und keine Ablaufzeit für aktive Tokens (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstoken zu erhalten).
Ein Aktualisierungstoken sollte an ein aud, an einige Scopes und an einen Mandanten gebunden sein und sollte nur in der Lage sein, Zugriffstoken für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei FOCI-Anwendungstoken.
Ein Aktualisierungstoken ist verschlüsselt und nur Microsoft kann es entschlüsseln.
Das Erhalten eines neuen Aktualisierungstokens widerruft das vorherige Aktualisierungstoken nicht.
Informationen für bedingten Zugriff sind innerhalb des JWT gespeichert. Wenn du also das Token von einer erlaubten IP-Adresse anforderst, wird diese IP im Token gespeichert und du kannst dieses Token von einer nicht erlaubten IP verwenden, um auf die Ressourcen zuzugreifen.
Das im "aud"-Feld angegebene Feld ist der Ressourcenserver (die Anwendung), die zum Anmelden verwendet wird.
Der Befehl az account get-access-token --resource-type [...] unterstützt die folgenden Typen, und jeder von ihnen wird ein spezifisches "aud" im resultierenden Zugriffstoken hinzufügen:
Beachte, dass die folgenden nur die von az account get-access-token unterstützten APIs sind, es gibt jedoch mehr.
Der Scope eines Zugriffstokens wird im scp-Schlüssel innerhalb des Zugriffstoken-JWT gespeichert. Diese Scopes definieren, auf was das Zugriffstoken Zugriff hat.
Wenn ein JWT berechtigt ist, eine bestimmte API zu kontaktieren, aber nicht den Scope hat, um die angeforderte Aktion auszuführen, wird es nicht in der Lage sein, die Aktion mit diesem JWT auszuführen.
Zuvor wurde erwähnt, dass Refresh-Tokens an die Scopes gebunden sein sollten, mit denen sie generiert wurden, an die Anwendung und den Mandanten, für die sie generiert wurden. Wenn eine dieser Grenzen überschritten wird, ist es möglich, Privilegien zu eskalieren, da es möglich sein wird, Zugriffstokens für andere Ressourcen und Mandanten zu generieren, auf die der Benutzer Zugriff hat, und mit mehr Scopes, als ursprünglich vorgesehen.
Darüber hinaus ist dies mit allen Refresh-Tokens in der Microsoft-Identitätsplattform (Microsoft Entra-Konten, Microsoft-Persönliche Konten und soziale Konten wie Facebook und Google) möglich, da die Dokumentation erwähnt: "Refresh-Tokens sind an eine Kombination aus Benutzer und Client gebunden, aber nicht an eine Ressource oder einen Mandanten gebunden. Ein Client kann ein Refresh-Token verwenden, um Zugriffstokens über jede Kombination von Ressource und Mandant zu erwerben, für die er die Berechtigung hat. Refresh-Tokens sind verschlüsselt und nur die Microsoft-Identitätsplattform kann sie lesen."
Darüber hinaus beachten Sie, dass die FOCI-Anwendungen öffentliche Anwendungen sind, sodass kein Geheimnis erforderlich ist, um sich beim Server zu authentifizieren.
Dann bekannte FOCI-Clients, die in der ursprünglichen Forschung gemeldet wurden, können hier gefunden werden.
Folgend mit dem vorherigen Beispielcode wird in diesem Code ein neues Token für einen anderen Scope angefordert:
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
