GCP - Container Privesc

Reading time: 5 minutes

container

container.clusters.get

Cette permission permet de rassembler des identifiants pour le cluster Kubernetes en utilisant quelque chose comme :

gcloud container clusters get-credentials <cluster_name> --zone <zone>

Sans autorisations supplémentaires, les identifiants sont assez basiques car vous pouvez simplement lister certaines ressources, mais ils sont utiles pour trouver des erreurs de configuration dans l'environnement.

Si vous n'avez pas cette autorisation, vous pouvez toujours accéder au cluster, mais vous devez créer votre propre fichier de configuration kubectl avec les informations des clusters. Un nouveau généré ressemble à ceci :

apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUVMRENDQXBTZ0F3SUJBZ0lRRzNaQmJTSVlzeVRPR1FYODRyNDF3REFOQmdrcWhraUc5dzBCQVFzRkFEQXYKTVMwd0t3WURWUVFERXlRMk9UQXhZVEZoWlMweE56ZGxMVFF5TkdZdE9HVmhOaTAzWVdFM01qVmhNR05tTkdFdwpJQmNOTWpJeE1qQTBNakl4T1RJMFdoZ1BNakExTWpFeE1qWXlNekU1TWpSYU1DOHhMVEFyQmdOVkJBTVRKRFk1Ck1ERmhNV0ZsTFRFM04yVXROREkwWmkwNFpXRTJMVGRoWVRjeU5XRXdZMlkwWVRDQ0FhSXdEUVlKS29aSWh2Y04KQVFFQkJRQURnZ0dQQURDQ0FZb0NnZ0dCQU00TWhGemJ3Y3VEQXhiNGt5WndrNEdGNXRHaTZmb0pydExUWkI4Rgo5TDM4a2V2SUVWTHpqVmtoSklpNllnSHg4SytBUHl4RHJQaEhXMk5PczFNMmpyUXJLSHV6M0dXUEtRUmtUWElRClBoMy9MMDVtbURwRGxQK3hKdzI2SFFqdkE2Zy84MFNLakZjRXdKRVhZbkNMMy8yaFBFMzdxN3hZbktwTWdKVWYKVnoxOVhwNEhvbURvOEhUN2JXUTJKWTVESVZPTWNpbDhkdDZQd3FUYmlLNjJoQzNRTHozNzNIbFZxaiszNy90RgpmMmVwUUdFOG90a0VVOFlHQ3FsRTdzaVllWEFqbUQ4bFZENVc5dk1RNXJ0TW8vRHBTVGNxRVZUSzJQWk1rc0hyCmMwbGVPTS9LeXhnaS93TlBRdW5oQ2hnRUJIZTVzRmNxdmRLQ1pmUFovZVI1Qk0vc0w1WFNmTE9sWWJLa2xFL1YKNFBLNHRMVmpiYVg1VU9zMUZIVXMrL3IyL1BKQ2hJTkRaVTV2VjU0L1c5NWk4RnJZaUpEYUVGN0pveXJvUGNuMwpmTmNjQ2x1eGpOY1NsZ01ISGZKRzZqb0FXLzB0b2U3ek05RHlQOFh3NW44Zm5lQm5aVTFnYXNKREZIYVlZbXpGCitoQzFETmVaWXNibWNxOGVPVG9LOFBKRjZ3SURBUUFCbzBJd1FEQU9CZ05WSFE4QkFmOEVCQU1DQWdRd0R3WUQKVlIwVEFRSC9CQVV3QXdFQi96QWRCZ05WSFE0RUZnUVU5UkhvQXlxY3RWSDVIcmhQZ1BjYzF6Sm9kWFV3RFFZSgpLb1pJaHZjTkFRRUxCUUFEZ2dHQkFLbnp3VEx0QlJBVE1KRVB4TlBNbmU2UUNqZDJZTDgxcC9oeVc1eWpYb2w5CllkMTRRNFVlVUJJVXI0QmJadzl0LzRBQ3ZlYUttVENaRCswZ2wyNXVzNzB3VlFvZCtleVhEK2I1RFBwUUR3Z1gKbkJLcFFCY1NEMkpvZ29tT3M3U1lPdWVQUHNrODVvdWEwREpXLytQRkY1WU5ublc3Z1VLT2hNZEtKcnhuYUVGZAprVVl1TVdPT0d4U29qVndmNUsyOVNCbGJ5YXhDNS9tOWkxSUtXV2piWnZPN0s4TTlYLytkcDVSMVJobDZOSVNqCi91SmQ3TDF2R0crSjNlSjZneGs4U2g2L28yRnhxZWFNdDladWw4MFk4STBZaGxXVmlnSFMwZmVBUU1NSzUrNzkKNmozOWtTZHFBYlhPaUVOMzduOWp2dVlNN1ZvQzlNUk1oYUNyQVNhR2ZqWEhtQThCdlIyQW5iQThTVGpQKzlSMQp6VWRpK3dsZ0V4bnFvVFpBcUVHRktuUTlQcjZDaDYvR0xWWStqYXhuR3lyUHFPYlpNZTVXUDFOUGs4NkxHSlhCCjc1elFvanEyRUpxanBNSjgxT0gzSkxOeXRTdmt4UDFwYklxTzV4QUV0OWxRMjh4N28vbnRuaWh1WmR6M0lCRU8KODdjMDdPRGxYNUJQd0hIdzZtKzZjUT09Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
server: https://34.123.141.28
name: gke_security-devbox_us-central1_autopilot-cluster-1
contexts:
- context:
cluster: gke_security-devbox_us-central1_autopilot-cluster-1
user: gke_security-devbox_us-central1_autopilot-cluster-1
name: gke_security-devbox_us-central1_autopilot-cluster-1
current-context: gke_security-devbox_us-central1_autopilot-cluster-1
kind: Config
preferences: {}
users:
- name: gke_security-devbox_us-central1_autopilot-cluster-1
user:
auth-provider:
config:
access-token: <access token>
cmd-args: config config-helper --format=json
cmd-path: gcloud
expiry: "2022-12-06T01:13:11Z"
expiry-key: "{.credential.token_expiry}"
token-key: "{.credential.access_token}"
name: gcp

container.roles.escalate | container.clusterRoles.escalate

Kubernetes par défaut empêche les principaux de pouvoir créer ou mettre à jour des Roles et ClusterRoles avec plus de permissions que celles que le principal possède. Cependant, un principal GCP avec ces permissions sera capable de créer/mettre à jour des Roles/ClusterRoles avec plus de permissions que celles qu'il détenait, contournant ainsi efficacement la protection de Kubernetes contre ce comportement.

container.roles.create et/ou container.roles.update OU container.clusterRoles.create et/ou container.clusterRoles.update respectivement sont également nécessaires pour effectuer ces actions d'escalade de privilèges.

container.roles.bind | container.clusterRoles.bind

Kubernetes par défaut empêche les principaux de pouvoir créer ou mettre à jour des RoleBindings et ClusterRoleBindings pour donner plus de permissions que celles que le principal possède. Cependant, un principal GCP avec ces permissions sera capable de créer/mettre à jour des RoleBindings/ClusterRoleBindings avec plus de permissions que celles qu'il a, contournant ainsi efficacement la protection de Kubernetes contre ce comportement.

container.roleBindings.create et/ou container.roleBindings.update OU container.clusterRoleBindings.create et/ou container.clusterRoleBindings.update respectivement sont également nécessaires pour effectuer ces actions d'escalade de privilèges.

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

Toutes ces permissions vous permettront de créer ou mettre à jour une ressource où vous pouvez définir un pod. En définissant un pod, vous pouvez spécifier le SA qui va être attaché et l'image qui va être exécutée, vous permettant ainsi d'exécuter une image qui va exfiltrer le token du SA vers votre serveur, vous permettant d'escalader vers n'importe quel compte de service.
Pour plus d'informations, consultez :

Étant dans un environnement GCP, vous pourrez également obtenir le SA du nodepool GCP à partir du service metadata et escalader les privilèges dans GCP (par défaut, le SA de calcul est utilisé).

container.secrets.get | container.secrets.list

Comme expliqué sur cette page, avec ces permissions, vous pouvez lire les tokens de tous les SAs de kubernetes, vous permettant ainsi de vous y escalader.

container.pods.exec

Avec cette permission, vous pourrez exec dans des pods, ce qui vous donne accès à tous les SAs Kubernetes exécutés dans des pods pour escalader les privilèges au sein de K8s, mais vous pourrez également voler le GCP Service Account du NodePool, escaladant les privilèges dans GCP.

container.pods.portForward

Comme expliqué sur cette page, avec ces permissions, vous pouvez accéder aux services locaux exécutés dans des pods qui pourraient vous permettre d'escalader les privilèges dans Kubernetes (et dans GCP si d'une manière ou d'une autre vous parvenez à communiquer avec le service metadata).

container.serviceAccounts.createToken

En raison du nom de la permission, il semble que cela vous permettra de générer des tokens des K8s Service Accounts, vous permettant ainsi de privesc à n'importe quel SA à l'intérieur de Kubernetes. Cependant, je n'ai pas trouvé d'endpoint API à utiliser, donc faites-moi savoir si vous le trouvez.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Ces permissions pourraient vous permettre d'escalader les privilèges dans Kubernetes, mais plus probablement, vous pourriez les abuser pour persister dans le cluster.
Pour plus d'informations, suivez ce lien.