Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Google Cloud verwendet eine Ressourcenhierarchie, die konzeptionell ähnlich ist wie die eines traditionellen Dateisystems. Dies bietet einen logischen Eltern-/Kind-Workflow mit spezifischen Anknüpfungspunkten für Richtlinien und Berechtigungen.
Auf hoher Ebene sieht es so aus:
Eine virtuelle Maschine (genannt Compute Instance) ist eine Ressource. Eine Ressource befindet sich in einem Projekt, wahrscheinlich neben anderen Compute Instances, Speicher-Buckets usw.
Es ist möglich, ein Projekt ohne Organisation in eine Organisation mit den Berechtigungen roles/resourcemanager.projectCreator und roles/resourcemanager.projectMover zu migrieren. Wenn sich das Projekt in einer anderen Organisation befindet, muss GCP-Support kontaktiert werden, um es zuerst aus der Organisation zu verschieben. Für weitere Informationen siehe dies.
Erlauben es, die Kontrolle über die Cloud-Ressourcen Ihrer Organisation zu zentralisieren:
Zentralisieren Sie die Kontrolle, um Einschränkungen zu konfigurieren, wie die Ressourcen Ihrer Organisation verwendet werden können.
Definieren und etablieren Sie Richtlinien, damit Ihre Entwicklungsteams innerhalb der Compliance-Grenzen bleiben.
Helfen Sie Projektbesitzern und ihren Teams, schnell zu arbeiten, ohne sich Sorgen über die Einhaltung der Vorschriften machen zu müssen.
Diese Richtlinien können erstellt werden, um die gesamte Organisation, Ordner oder Projekte zu beeinflussen. Nachkommen des Zielressourcen-Hierarchieknotens erben die Organisationsrichtlinie.
Um eine Organisationsrichtlinie zu definieren, wählen Sie eine Einschränkung, die eine bestimmte Art von Einschränkung gegen einen Google Cloud-Dienst oder eine Gruppe von Google Cloud-Diensten ist. Sie konfigurieren diese Einschränkung mit Ihren gewünschten Einschränkungen.
Begrenzen Sie die Ressourcenteilung basierend auf der Domain.
Begrenzen Sie die Nutzung von Identitäts- und Zugriffsmanagement-Dienstkonten.
Beschränken Sie den physischen Standort neu erstellter Ressourcen.
Deaktivieren Sie die Erstellung von Dienstkonten.
Es gibt viele weitere Einschränkungen, die Ihnen eine feinkörnige Kontrolle über die Ressourcen Ihrer Organisation geben. Für weitere Informationen siehe die Liste aller Einschränkungen des Organisation Policy Service.
Diese sind wie IAM-Richtlinien in AWS, da jede Rolle eine Reihe von Berechtigungen enthält.
Im Gegensatz zu AWS gibt es jedoch kein zentrales Repository für Rollen. Stattdessen geben Ressourcen X Zugriffsrollen an Y Prinzipale, und der einzige Weg herauszufinden, wer Zugriff auf eine Ressource hat, besteht darin, die get-iam-policy-Methode über diese Ressource zu verwenden.
Das könnte ein Problem darstellen, da dies bedeutet, dass der einzige Weg herauszufinden, welche Berechtigungen ein Prinzipal hat, darin besteht, jede Ressource zu fragen, wem sie Berechtigungen erteilt, und ein Benutzer möglicherweise nicht die Berechtigungen hat, um Berechtigungen von allen Ressourcen abzurufen.
Es gibt drei Arten von Rollen in IAM:
Basis-/Primitive Rollen, die die Rollen Owner, Editor und Viewer umfassen, die vor der Einführung von IAM existierten.
Vordefinierte Rollen, die granularen Zugriff auf einen bestimmten Dienst bieten und von Google Cloud verwaltet werden. Es gibt viele vordefinierte Rollen, Sie können alle mit den Berechtigungen, die sie haben, hier sehen hier.
Benutzerdefinierte Rollen, die granularen Zugriff gemäß einer benutzerspezifizierten Liste von Berechtigungen bieten.
Es gibt Tausende von Berechtigungen in GCP. Um zu überprüfen, ob eine Rolle eine Berechtigung hat, können Sie hier nach der Berechtigung suchen und sehen, welche Rollen sie haben.
Sie können auch hier nach vordefinierten Rollen suchen, die von jedem Produkt angeboten werden. Beachten Sie, dass einige Rollen nicht Benutzern zugewiesen werden können und nur SAs zugewiesen werden können, aufgrund einiger Berechtigungen, die sie enthalten. Darüber hinaus beachten Sie, dass Berechtigungen nur wirksam werden, wenn sie dem relevanten Dienst zugewiesen sind.
Oder überprüfen Sie, ob eine benutzerdefinierte Rolle eine spezifische Berechtigung hier verwenden kann.
GCP - IAM, Principals & Org Policies EnumIn der GCP-Konsole gibt es kein Benutzer- oder Gruppenmanagement, das erfolgt in Google Workspace. Obwohl Sie einen anderen Identitätsanbieter in Google Workspace synchronisieren könnten.
Sie können auf die Benutzer und Gruppen von Workspaces unter https://admin.google.com zugreifen.
MFA kann für Workspaces-Benutzer erzwungen werden, jedoch könnte ein Angreifer ein Token verwenden, um GCP über die CLI zuzugreifen, das nicht durch MFA geschützt ist (es wird nur geschützt, wenn der Benutzer sich anmeldet, um es zu generieren: gcloud auth login).
Wenn eine Organisation erstellt wird, wird dringend empfohlen, mehrere Gruppen zu erstellen. Wenn Sie eine davon verwalten, könnten Sie die gesamte Organisation oder einen wichtigen Teil davon kompromittiert haben:
Gruppe | Funktion |
| Verwaltung aller Ressourcen, die zur Organisation gehören. Weisen Sie diese Rolle sparsam zu; Org-Admins haben Zugriff auf alle Ihre Google Cloud-Ressourcen. Alternativ, da diese Funktion hochprivilegiert ist, ziehen Sie in Betracht, individuelle Konten anstelle der Erstellung einer Gruppe zu verwenden. |
| Erstellung von Netzwerken, Subnetzen, Firewall-Regeln und Netzwerkgeräten wie Cloud Router, Cloud VPN und Cloud Load Balancers. |
| Einrichtung von Abrechnungskonten und Überwachung ihrer Nutzung. |
| Entwicklung, Codierung und Testen von Anwendungen. |
| Festlegung und Verwaltung von Sicherheitsrichtlinien für die gesamte Organisation, einschließlich Zugriffsmanagement und Organisationsbeschränkungsrichtlinien. Siehe den Leitfaden zu den Sicherheitsgrundlagen von Google Cloud für weitere Informationen zur Planung Ihrer Google Cloud-Sicherheitsinfrastruktur. |
| Erstellung oder Verwaltung von End-to-End-Pipelines, die kontinuierliche Integration und Bereitstellung, Überwachung und Systembereitstellung unterstützen. |
| |
| |
| |
| Überwachung der Ausgaben für Projekte. Typische Mitglieder sind Teil des Finanzteams. |
| Überprüfung von Ressourceninformationen in der Google Cloud-Organisation. |
| Überprüfung der Cloud-Sicherheit. |
| Überprüfung von Netzwerkkonfigurationen. |
| Einsehen von Audit-Protokollen. |
| Verwaltung des Security Command Center. |
| Verwaltung von Geheimnissen im Secret Manager. |
Durchsetzung starker Passwörter
Zwischen 8 und 100 Zeichen
Keine Wiederverwendung
Keine Ablaufzeit
Wenn Personen über einen Drittanbieter auf Workspace zugreifen, werden diese Anforderungen nicht angewendet.
Dies sind die Prinzipale, die Ressourcen haben angehängt und Zugriff haben, um einfach mit GCP zu interagieren. Zum Beispiel ist es möglich, auf das Auth-Token eines Dienstkontos zuzugreifen, das an eine VM in den Metadaten angehängt ist.
Es ist möglich, einige Konflikte zu begegnen, wenn sowohl IAM als auch Zugriffsscope verwendet werden. Zum Beispiel kann Ihr Dienstkonto die IAM-Rolle compute.instanceAdmin haben, aber die Instanz, die Sie kompromittiert haben, wurde mit der Scope-Beschränkung https://www.googleapis.com/auth/compute.readonly eingeschränkt. Dies würde Sie daran hindern, Änderungen mit dem OAuth-Token vorzunehmen, das automatisch Ihrer Instanz zugewiesen wird.
Es ist ähnlich wie IAM-Rollen von AWS. Aber im Gegensatz zu AWS kann jedes Dienstkonto an jeden Dienst angehängt werden (es muss nicht über eine Richtlinie erlaubt werden).
Mehrere der Dienstkonten, die Sie finden werden, sind tatsächlich automatisch von GCP generiert, wenn Sie einen Dienst zu nutzen beginnen, wie:
Es ist jedoch auch möglich, benutzerdefinierte Dienstkonten zu erstellen und an Ressourcen anzuhängen, die so aussehen werden:
Es gibt 2 Hauptwege, um auf GCP als Dienstkonto zuzugreifen:
Via OAuth-Tokens: Dies sind Tokens, die Sie von Orten wie Metadatenendpunkten oder durch Stehlen von HTTP-Anfragen erhalten, und sie sind durch die Zugriffsbereiche eingeschränkt.
Schlüssel: Dies sind öffentliche und private Schlüsselpaar, die es Ihnen ermöglichen, Anfragen als Dienstkonto zu signieren und sogar OAuth-Tokens zu generieren, um Aktionen als Dienstkonto durchzuführen. Diese Schlüssel sind gefährlich, da sie komplizierter zu begrenzen und zu kontrollieren sind, weshalb GCP empfiehlt, sie nicht zu generieren.
Beachten Sie, dass jedes Mal, wenn ein SA erstellt wird, GCP einen Schlüssel für das Dienstkonto generiert, auf den der Benutzer keinen Zugriff hat (und der nicht in der Webanwendung aufgeführt wird). Laut diesem Thread wird dieser Schlüssel intern von GCP verwendet, um den Metadatenendpunkten den Zugriff zu gewähren, um die zugänglichen OAuth-Tokens zu generieren.
Zugriffsbereiche sind an generierte OAuth-Tokens angehängt, um auf die GCP-API-Endpunkte zuzugreifen. Sie beschränken die Berechtigungen des OAuth-Tokens. Das bedeutet, dass, wenn ein Token einem Eigentümer einer Ressource gehört, aber nicht den im Token definierten Bereich hat, um auf diese Ressource zuzugreifen, das Token nicht verwendet werden kann, um diese Berechtigungen (miss)zuverwenden.
Google empfiehlt tatsächlich, dass Zugriffsbereiche nicht verwendet werden und vollständig auf IAM vertraut wird. Das Webverwaltungsportal setzt dies tatsächlich durch, aber Zugriffsbereiche können weiterhin programmgesteuert auf Instanzen angewendet werden, die benutzerdefinierte Dienstkonten verwenden.
Sie können sehen, welche Bereiche zugewiesen sind, indem Sie abfragen:
Die vorherigen Scopes sind die, die standardmäßig mit gcloud generiert werden, um auf Daten zuzugreifen. Das liegt daran, dass Sie beim Verwenden von gcloud zuerst ein OAuth-Token erstellen und es dann verwenden, um die Endpunkte zu kontaktieren.
Der wichtigste Scope davon ist wahrscheinlich cloud-platform, was im Grunde bedeutet, dass es möglich ist, auf jeden Dienst in GCP zuzugreifen.
Sie können eine Liste von allen möglichen Scopes hier finden.
Wenn Sie gcloud Browser-Anmeldeinformationen haben, ist es möglich, ein Token mit anderen Scopes zu erhalten, indem Sie etwas wie Folgendes tun:
Wie von terraform in https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam definiert, gibt es beim Einsatz von terraform mit GCP verschiedene Möglichkeiten, einem Principal Zugriff auf eine Ressource zu gewähren:
Mitgliedschaften: Sie setzen Principals als Mitglieder von Rollen ohne Einschränkungen über die Rolle oder die Principals. Sie können einen Benutzer als Mitglied einer Rolle festlegen und dann eine Gruppe als Mitglied derselben Rolle festlegen und auch diese Principals (Benutzer und Gruppe) als Mitglieder anderer Rollen festlegen.
Bindungen: Mehrere Principals können an eine Rolle gebunden werden. Diese Principals können weiterhin an andere Rollen gebunden oder Mitglieder anderer Rollen sein. Wenn jedoch ein Principal, der nicht an die Rolle gebunden ist, als Mitglied einer gebundenen Rolle festgelegt wird, wird die Mitgliedschaft beim nächsten Mal, wenn die Bindung angewendet wird, verschwinden.
Richtlinien: Eine Richtlinie ist verbindlich, sie gibt Rollen und Principals an und dann können diese Principals keine weiteren Rollen haben und diese Rollen können keine weiteren Principals haben, es sei denn, diese Richtlinie wird geändert (nicht einmal in anderen Richtlinien, Bindungen oder Mitgliedschaften). Daher sind alle Privilegien, wenn eine Rolle oder ein Principal in der Richtlinie angegeben ist, durch diese Richtlinie eingeschränkt. Offensichtlich kann dies umgangen werden, wenn dem Principal die Möglichkeit gegeben wird, die Richtlinie zu ändern oder Berechtigungen zur Privilegieneskalation zu erhalten (wie das Erstellen eines neuen Principals und das Binden an eine neue Rolle).
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
