GCP - Container Privesc
container
container.clusters.get
container.clusters.get
Diese Berechtigung ermöglicht es, Anmeldeinformationen für den Kubernetes-Cluster zu sammeln, indem beispielsweise:
Ohne zusätzliche Berechtigungen sind die Anmeldeinformationen ziemlich grundlegend, da Sie nur einige Ressourcen auflisten können, aber sie sind nützlich, um Konfigurationsfehler in der Umgebung zu finden.
Beachten Sie, dass Kubernetes-Cluster möglicherweise so konfiguriert sind, dass sie privat sind, was den Zugriff auf den Kube-API-Server aus dem Internet verhindert.
Wenn Sie diese Berechtigung nicht haben, können Sie dennoch auf den Cluster zugreifen, aber Sie müssen Ihre eigene kubectl-Konfigurationsdatei erstellen mit den Clusterinformationen. Eine neu generierte sieht so aus:
container.roles.escalate
| container.clusterRoles.escalate
container.roles.escalate
| container.clusterRoles.escalate
Kubernetes verhindert standardmäßig, dass Prinzipale Rollen und Cluster-Rollen mit mehr Berechtigungen erstellen oder aktualisieren können als die, die der Prinzipal hat. Ein GCP-Prinzipal mit diesen Berechtigungen kann jedoch Rollen/Cluster-Rollen mit mehr Berechtigungen erstellen/aktualisieren, und somit die Kubernetes-Schutzmaßnahmen umgehen.
container.roles.create
und/oder container.roles.update
ODER container.clusterRoles.create
und/oder container.clusterRoles.update
sind ebenfalls erforderlich, um diese Privilegien-Eskalationsaktionen durchzuführen.
container.roles.bind
| container.clusterRoles.bind
container.roles.bind
| container.clusterRoles.bind
Kubernetes verhindert standardmäßig, dass Prinzipale Rollenbindungen und Cluster-Rollenbindungen erstellen oder aktualisieren, um mehr Berechtigungen zu vergeben als die, die der Prinzipal hat. Ein GCP-Prinzipal mit diesen Berechtigungen kann jedoch Rollenbindungen/Cluster-Rollenbindungen mit mehr Berechtigungen erstellen/aktualisieren, und somit die Kubernetes-Schutzmaßnahmen umgehen.
container.roleBindings.create
und/oder container.roleBindings.update
ODER container.clusterRoleBindings.create
und/oder container.clusterRoleBindings.update
sind ebenfalls erforderlich, um diese Privilegien-Eskalationsaktionen 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
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
Alle diese Berechtigungen ermöglichen es Ihnen, eine Ressource zu erstellen oder zu aktualisieren, in der Sie ein Pod definieren können. Durch die Definition eines Pods können Sie den SA angeben, der angehängt wird, und das Image, das ausgeführt wird. Somit können Sie ein Image ausführen, das das Token des SA auf Ihren Server exfiltriert, was es Ihnen ermöglicht, zu einem beliebigen Dienstkontos zu eskalieren. Für weitere Informationen siehe:
Da wir uns in einer GCP-Umgebung befinden, können Sie auch das Nodepool GCP SA aus dem Metadatendienst abrufen und Berechtigungen in GCP eskalieren (standardmäßig wird der Compute SA verwendet).
container.secrets.get
| container.secrets.list
container.secrets.get
| container.secrets.list
Mit diesen Berechtigungen können Sie, wie auf dieser Seite erklärt, die Token aller SAs von Kubernetes lesen, und somit zu ihnen eskalieren.
container.pods.exec
container.pods.exec
Mit dieser Berechtigung können Sie in Pods eintreten, was Ihnen Zugriff auf alle in den Pods ausgeführten Kubernetes-SAs gibt, um Privilegien innerhalb von K8s zu eskalieren. Außerdem können Sie das GCP-Dienstkonto des NodePools stehlen, um Berechtigungen in GCP zu eskalieren.
container.pods.portForward
container.pods.portForward
Wie auf dieser Seite erklärt, können Sie mit diesen Berechtigungen auf lokale Dienste in Pods zugreifen, die es Ihnen ermöglichen könnten, Privilegien in Kubernetes (und in GCP, wenn Sie irgendwie mit dem Metadatendienst kommunizieren können) zu eskalieren.
container.serviceAccounts.createToken
container.serviceAccounts.createToken
Aufgrund des Namens der Berechtigung scheint es, dass Sie Tokens der K8s-Servicekonten generieren können, sodass Sie zu jedem SA innerhalb von Kubernetes eskalieren können. Ich konnte jedoch keinen API-Endpunkt finden, um dies zu nutzen. Lassen Sie mich wissen, wenn Sie ihn finden.
container.mutatingWebhookConfigurations.create
| container.mutatingWebhookConfigurations.update
container.mutatingWebhookConfigurations.create
| container.mutatingWebhookConfigurations.update
Diese Berechtigungen könnten es Ihnen ermöglichen, Privilegien in Kubernetes zu eskalieren, aber wahrscheinlicher könnten Sie sie missbrauchen, um im Cluster zu persistieren. Für weitere Informationen folgen Sie diesem Link.
Last updated