GCP - Container Privesc
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)
container.clusters.get
Diese Berechtigung ermöglicht es, Anmeldeinformationen für den Kubernetes-Cluster zu sammeln mit etwas wie:
Ohne zusätzliche Berechtigungen sind die Anmeldeinformationen ziemlich grundlegend, da Sie einige Ressourcen auflisten können, aber sie sind nützlich, um Fehlkonfigurationen in der Umgebung zu finden.
Beachten Sie, dass Kubernetes-Cluster so konfiguriert sein können, dass sie privat sind, was den Zugriff auf den Kube-API-Server aus dem Internet verbietet.
Wenn Sie diese Berechtigung nicht haben, können Sie dennoch auf den Cluster zugreifen, aber Sie müssen Ihre eigene kubectl-Konfigurationsdatei mit den Clusterinformationen erstellen. Eine neu generierte sieht so aus:
container.roles.escalate
| container.clusterRoles.escalate
Kubernetes verhindert standardmäßig, dass Principals Rollen und ClusterRollen mit mehr Berechtigungen erstellen oder aktualisieren, als die, die der Principal hat. Ein GCP-Principal mit diesen Berechtigungen wird jedoch in der Lage sein, Rollen/ClusterRollen mit mehr Berechtigungen zu erstellen/aktualisieren, als er besitzt, und damit den Kubernetes-Schutz gegen dieses Verhalten zu umgehen.
container.roles.create
und/oder container.roles.update
ODER container.clusterRoles.create
und/oder container.clusterRoles.update
sind ebenfalls notwendig, um diese Privilegieneskalationsaktionen durchzuführen.
container.roles.bind
| container.clusterRoles.bind
Kubernetes verhindert standardmäßig, dass Principals RoleBindings und ClusterRoleBindings erstellen oder aktualisieren, um mehr Berechtigungen zu gewähren, als die, die der Principal hat. Ein GCP-Principal mit diesen Berechtigungen wird jedoch in der Lage sein, RoleBindings/ClusterRoleBindings mit mehr Berechtigungen zu erstellen/aktualisieren, als er hat, und damit den Kubernetes-Schutz gegen dieses Verhalten zu umgehen.
container.roleBindings.create
und/oder container.roleBindings.update
ODER container.clusterRoleBindings.create
und/oder container.clusterRoleBindings.update
sind ebenfalls notwendig, um diese Privilegieneskalationsaktionen durchzuführen.
container.cronJobs.create
| container.cronJobs.update
| container.daemonSets.create
| container.daemonSets.update
| container.deployments.create
| container.deployments.update
| container.jobs.create
| container.jobs.update
| container.pods.create
| container.pods.update
| container.replicaSets.create
| container.replicaSets.update
| container.replicationControllers.create
| container.replicationControllers.update
| container.scheduledJobs.create
| container.scheduledJobs.update
| container.statefulSets.create
| container.statefulSets.update
All diese Berechtigungen ermöglichen es Ihnen, eine Ressource zu erstellen oder zu aktualisieren, bei der Sie einen Pod definieren können. Indem Sie einen Pod definieren, können Sie die SA angeben, die angehängt wird, und das Image, das ausgeführt wird. Daher können Sie ein Image ausführen, das das Token der SA an Ihren Server exfiltriert, wodurch Sie auf jedes Dienstkonto eskalieren können. Für weitere Informationen siehe:
Da wir uns in einer GCP-Umgebung befinden, werden Sie auch in der Lage sein, die Nodepool GCP SA vom Metadaten-Dienst abzurufen und Privilegien in GCP zu eskalieren (standardmäßig wird die Compute SA verwendet).
container.secrets.get
| container.secrets.list
Wie auf dieser Seite erklärt können Sie mit diesen Berechtigungen die Tokens aller SAs von Kubernetes lesen, sodass Sie zu ihnen eskalieren können.
container.pods.exec
Mit dieser Berechtigung können Sie in Pods exec ausführen, was Ihnen Zugriff auf alle Kubernetes SAs, die in Pods ausgeführt werden, gibt, um Privilegien innerhalb von K8s zu eskalieren. Sie werden auch in der Lage sein, die GCP Service Account des NodePools zu stehlen, wodurch Sie die Privilegien in GCP eskalieren.
container.pods.portForward
Wie auf dieser Seite erklärt, können Sie mit diesen Berechtigungen auf lokale Dienste zugreifen, die in Pods ausgeführt werden und Ihnen möglicherweise ermöglichen, Privilegien in Kubernetes (und in GCP, wenn Sie es schaffen, mit dem Metadaten-Dienst zu kommunizieren) zu eskalieren.
container.serviceAccounts.createToken
Aufgrund des Namens der Berechtigung sieht es so aus, als würde es Ihnen erlauben, Tokens der K8s-Dienstkonten zu generieren, sodass Sie zu jedem SA innerhalb von Kubernetes eskalieren können. Ich konnte jedoch keinen API-Endpunkt finden, um ihn zu verwenden, lassen Sie es mich wissen, wenn Sie ihn finden.
container.mutatingWebhookConfigurations.create
| container.mutatingWebhookConfigurations.update
Diese Berechtigungen könnten es Ihnen ermöglichen, Privilegien in Kubernetes zu eskalieren, aber wahrscheinlicher ist, dass Sie sie missbrauchen könnten, um im Cluster persistent zu bleiben. Für weitere Informationen folgen Sie diesem Link.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)