GCP - Privilege Escalation
Last updated
Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
GCP hat, wie jede andere Cloud, einige Prinzipien: Benutzer, Gruppen und Dienstkonten sowie einige Ressourcen wie Compute Engine, Cloud Functions… Dann werden über Rollen Berechtigungen diesen Prinzipien über die Ressourcen gewährt. Dies ist der Weg, um die Berechtigungen, die ein Prinzip über eine Ressource in GCP hat, zu spezifizieren. Es gibt bestimmte Berechtigungen, die es einem Benutzer ermöglichen, noch mehr Berechtigungen über die Ressource oder Drittanbieter-Ressourcen zu erhalten, und das nennt man Privilegieneskalation (auch die Ausnutzung von Schwachstellen, um mehr Berechtigungen zu erhalten).
Daher möchte ich die Techniken zur Privilegieneskalation in GCP in 2 Gruppen unterteilen:
Privesc zu einem Prinzip: Dies ermöglicht es dir, ein anderes Prinzip zu impersonifizieren und somit wie es mit all seinen Berechtigungen zu handeln. z.B.: Missbrauch von getAccessToken, um ein Dienstkonto zu impersonifizieren.
Privesc auf der Ressource: Dies ermöglicht es dir, mehr Berechtigungen über die spezifische Ressource zu erhalten. z.B.: Du kannst die Berechtigung setIamPolicy über Cloud Functions missbrauchen, um die Funktion auszulösen.
Beachte, dass einige Ressourcenberechtigungen dir auch erlauben, ein beliebiges Dienstkonto an die Ressource anzuhängen. Das bedeutet, dass du eine Ressource mit einem SA starten, in die Ressource gelangen und das SA-Token stehlen kannst. Daher wird dies ermöglichen, über eine Ressourcenskalation zu einem Prinzip zu eskalieren. Dies ist in mehreren Ressourcen zuvor passiert, aber jetzt ist es weniger häufig (kann aber immer noch passieren).
Offensichtlich sind die interessantesten Techniken zur Privilegieneskalation die der zweiten Gruppe, da sie es dir ermöglichen, mehr Privilegien außerhalb der Ressourcen zu erhalten, über die du bereits einige Privilegien hast. Beachte jedoch, dass Eskalation in Ressourcen dir auch Zugang zu sensiblen Informationen oder sogar zu anderen Prinzipien geben kann (vielleicht durch das Lesen eines Geheimnisses, das ein Token eines SA enthält).
Es ist auch wichtig zu beachten, dass in GCP Dienstkonten sowohl Prinzipien als auch Berechtigungen sind, sodass das Eskalieren von Berechtigungen in einem SA es dir auch ermöglicht, es zu impersonifizieren.
Die in Klammern angegebenen Berechtigungen zeigen die Berechtigungen an, die erforderlich sind, um die Schwachstelle mit gcloud
auszunutzen. Diese könnten nicht erforderlich sein, wenn sie über die API ausgenutzt werden.
So teste ich auf spezifische Berechtigungen, um spezifische Aktionen innerhalb von GCP durchzuführen.
Lade das GitHub-Repo https://github.com/carlospolop/gcp_privesc_scripts herunter.
Füge im Verzeichnis tests/ das neue Skript hinzu.
Tokens von SA, die aus dem GCP-Metadatenservice geleakt wurden, haben Zugriffsscoping. Dies sind Einschränkungen für die Berechtigungen, die das Token hat. Zum Beispiel, wenn das Token den https://www.googleapis.com/auth/cloud-platform
Scope hat, hat es vollen Zugriff auf alle GCP-Dienste. Wenn das Token jedoch den https://www.googleapis.com/auth/cloud-platform.read-only
Scope hat, hat es nur schreibgeschützten Zugriff auf alle GCP-Dienste, selbst wenn das SA mehr Berechtigungen in IAM hat.
Es gibt keinen direkten Weg, diese Berechtigungen zu umgehen, aber du könntest immer versuchen, nach neuen Anmeldeinformationen im kompromittierten Host zu suchen, den Dienstschlüssel zu finden, um ein OAuth-Token ohne Einschränkungen zu generieren oder zu einer anderen VM mit weniger Einschränkungen zu springen.
Wenn Zugriffsscoping verwendet wird, wird das OAuth-Token, das für die Compute-Instanz (VM) generiert wird, eine Scope Einschränkung enthalten. Du könntest jedoch in der Lage sein, diese Einschränkung zu umgehen und die Berechtigungen, die das kompromittierte Konto hat, auszunutzen.
Der beste Weg, diese Einschränkung zu umgehen, besteht entweder darin, neue Anmeldeinformationen im kompromittierten Host zu finden, den Dienstschlüssel zu finden, um ein OAuth-Token ohne Einschränkungen zu generieren oder eine andere VM mit einem weniger eingeschränkten SA zu kompromittieren.
Überprüfe SA mit Schlüsseln, die generiert wurden mit:
Der Weg, um Ihre Berechtigungen in AWS zu eskalieren, besteht darin, genügend Berechtigungen zu haben, um auf die Berechtigungen anderer Dienstkonten/Nutzer/Gruppen zugreifen zu können. Ketteneskalationen, bis Sie Administratorzugriff auf die Organisation haben.
GCP hat Hunderte (wenn nicht Tausende) von Berechtigungen, die einer Entität gewährt werden können. In diesem Buch finden Sie alle Berechtigungen, die ich kenne, die Sie missbrauchen können, um Berechtigungen zu eskalieren, aber wenn Sie einen Weg kennen, der hier nicht erwähnt wird, teilen Sie ihn bitte.
Die Unterseiten dieses Abschnitts sind nach Diensten geordnet. Sie finden auf jedem Dienst verschiedene Möglichkeiten, Berechtigungen auf den Diensten zu eskalieren.
Wenn Sie sich auf einer Maschine in GCP befinden, könnten Sie in der Lage sein, Berechtigungen zu missbrauchen, um Berechtigungen sogar lokal zu eskalieren:
GCP - local privilege escalation ssh pivotingLernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)