Français - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

GCP - Container Privesc

Apprenez le piratage AWS de zéro à héros avec htARTE (Expert de l'équipe rouge HackTricks AWS)!

Autres façons de soutenir HackTricks :

conteneur

container.clusters.get

Cette autorisation permet de recueillir des informations d'identification pour le cluster Kubernetes en utilisant quelque chose comme :

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

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

Notez que les clusters Kubernetes peuvent être configurés pour être privés, ce qui empêchera l'accès au serveur Kube-API depuis Internet.

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 fichier 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 Rôles et ClusterRoles avec plus de permissions que celles détenues par le principal. Cependant, un principal GCP avec ces permissions pourra créer/mettre à jour des Rôles/ClusterRoles avec plus de permissions que celles qu'il détient, contournant ainsi la protection de Kubernetes contre ce comportement.

Les permissions 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 détenues par le principal. Cependant, un principal GCP avec ces permissions pourra créer/mettre à jour des RoleBindings/ClusterRoleBindings avec plus de permissions que celles qu'il détient, contournant ainsi la protection de Kubernetes contre ce comportement.

Les permissions 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 vont vous permettre 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 jeton du SA vers votre serveur, vous permettant d'escalader vers n'importe quel compte de service. Pour plus d'informations, consultez :

Comme nous sommes dans un environnement GCP, vous pourrez également obtenir le SA GCP du pool de nœuds à partir du service de métadonnées 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 jetons de tous les SA de Kubernetes, vous permettant d'escalader vers eux.

container.pods.exec

Avec cette permission, vous pourrez exécuter des commandes dans des pods, ce qui vous donne accès à tous les SA Kubernetes s'exécutant dans les pods pour escalader les privilèges au sein de K8s, mais vous pourrez également voler le compte de service GCP du pool de nœuds, escaladant les privilèges dans GCP.

container.pods.portForward

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

container.serviceAccounts.createToken

En raison du nom de la permission, il semble que cela vous permettra de générer des jetons des comptes de service K8s, vous pourrez donc escalader vers n'importe quel SA à l'intérieur de Kubernetes. Cependant, je n'ai trouvé aucun point de terminaison API à utiliser, alors 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 utiliser pour persister dans le cluster. Pour plus d'informations, suivez ce lien.

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres façons de soutenir HackTricks :

PrécédentGCP - Composer PrivescSuivantGCP - Deploymentmaneger Privesc

Dernière mise à jour