Az - Tokens & Public Applications
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID ist die cloudbasierte Identitäts- und Zugriffsmanagementplattform (IAM) von Microsoft und dient als grundlegendes Authentifizierungs- und Autorisierungssystem für Dienste wie Microsoft 365 und Azure Resource Manager. 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 die Zugriffslevel angeben.
Zustimmung: Der Prozess, durch den ein Ressourcenbesitzer einer Client-Anwendung die Erlaubnis erteilt, auf Ressourcen mit bestimmten Scopes zuzugreifen.
Integration von Microsoft 365:
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 bis zum Ablauf nicht widerrufen werden - das sind 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.
Aktualisierungstokens: 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 Aktualisierungstokens und keine Ablaufzeit für aktive Tokens (es ist möglich, aus einem Aktualisierungstoken neue Aktualisierungstokens zu erhalten).
Ein Aktualisierungstoken sollte an ein aud, an einige Scopes und an einen Mandanten gebunden sein und sollte nur in der Lage sein, Zugriffstokens für dieses aud, diese Scopes (und nicht mehr) und diesen Mandanten zu generieren. Dies ist jedoch nicht der Fall bei FOCI-Anwendungstokens.
Ein Aktualisierungstoken ist verschlüsselt und nur Microsoft kann es entschlüsseln.
Das Erhalten eines neuen Aktualisierungstokens widerruft nicht das vorherige Aktualisierungstoken.
Informationen für bedingten Zugriff sind innerhalb des JWT gespeichert. Wenn Sie also das Token von einer erlaubten IP-Adresse anfordern, wird diese IP im Token gespeichert, und dann können Sie dieses Token von einer nicht erlaubten IP verwenden, um auf die Ressourcen zuzugreifen.
Das im Feld "aud" 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:
Beachten Sie, dass die folgenden nur die von az account get-access-token unterstützten APIs sind, es gibt jedoch weitere.
Der Scope eines Zugriffstokens wird im Schlüssel scp 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, kann es die Aktion nicht mit diesem JWT ausführen.
Zuvor wurde erwähnt, dass Refresh-Token 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, Zugriffstoken für andere Ressourcen und Mandanten zu generieren, auf die der Benutzer Zugriff hat, und mit mehr Scopes, als ursprünglich beabsichtigt.
Darüber hinaus ist dies mit allen Refresh-Token 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-Token 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 Zugriffstoken über jede Kombination von Ressource und Mandant zu erwerben, für die er die Berechtigung hat. Refresh-Token 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.
Bekannte FOCI-Clients, die in der ursprünglichen Forschung gemeldet wurden, können hier gefunden werden.
Im Folgenden wird im vorherigen Beispielcode ein neues Token für einen anderen Scope angefordert:
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
