GCP - Container Privesc

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

container

container.clusters.get

Hierdie toestemming laat toe om inlogbesonderhede vir die Kubernetes-kluster in te samel deur iets soos te gebruik:

Kry Kubernetes-kluster inlogbesonderhede ```bash gcloud container clusters get-credentials --zone ```

Sonder ekstra permissions is die credentials redelik basies aangesien jy net ’n resource kan lys, maar hulle is nuttig om miskonfigurasies in die omgewing te vind.

Note

Let wel dat kubernetes clusters dalk gekonfigureer is om privaat te wees, wat toegang tot die Kube-API server vanaf die Internet sal verhoed.

As jy nie hierdie permission het nie, kan jy steeds toegang tot die cluster kry, maar jy moet jou eie kubectl config file skep met die cluster se inligting. ’n Nuut gegenereerde een lyk soos volg:

Voorbeeld kubectl config file for GKE cluster ```yaml 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: 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 voorkom standaard dat principals in staat is om Roles en ClusterRoles te skep of te bywerk met meer permissies as dié wat die principal het. ’n GCP principal met daardie permissies sal egter in staat wees om Roles/ClusterRoles te skep/bewerk met meer permissies as dié wat hy vooraf gehad het, en sodoende die Kubernetes-beskerming teen hierdie gedrag oorbrug.

container.roles.create en/of container.roles.update OF container.clusterRoles.create en/of container.clusterRoles.update is onderskeidelik ook nodig om daardie privilege escalation-aksies uit te voer.

container.roles.bind | container.clusterRoles.bind

Kubernetes voorkom standaard dat principals in staat is om RoleBindings en ClusterRoleBindings te skep of te bywerk om meer permissies te gee as dié wat die principal het. ’n GCP principal met daardie permissies sal egter in staat wees om RoleBindings/ClusterRoleBindings te skep/bewerk met meer permissies as dié wat hy het, en sodoende die Kubernetes-beskerming teen hierdie gedrag oorbrug.

container.roleBindings.create en/of container.roleBindings.update OF container.clusterRoleBindings.create en/of container.clusterRoleBindings.update is onderskeidelik ook nodig om daardie privilege escalation-aksies uit te voer.

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

Al hierdie permissies laat jou toe om ’n resource te skep of te bywerk waarin jy ’n pod kan definieer. Deur ’n pod te definieer kan jy die SA spesifiseer wat daaraan geheg gaan word en die image wat uitgevoer gaan word; dus kan jy ’n image laat loop wat die token van die SA na jou bediener gaan exfiltrate, wat jou toelaat om te escalate na enige service account.
Vir meer inligting kyk:

Aangesien ons in ’n GCP-omgewing is, sal jy ook die nodepool GCP SA van die metadata service kan kry en privileges in GCP eskaleer (by verstek word die compute SA gebruik).

container.secrets.get | container.secrets.list

As verduidelik op hierdie blad, met hierdie permissies kan jy die tokens van al die SAs of kubernetes lees, sodat jy na hulle kan escalate.

container.pods.exec

Met hierdie permission sal jy in staat wees om te exec into pods, wat jou toegang gee tot al die Kubernetes SAs running in pods om privileges binne K8s te escalate, maar jy sal ook die GCP Service Account van die NodePool kan steal, en sodoende privileges in GCP eskaleer.

container.pods.portForward

Soos verduidelik op hierdie blad, met hierdie permissies kan jy toegang kry tot plaaslike dienste wat in pods loop wat jou moontlik toelaat om privileges in Kubernetes te escalate (en in GCP as jy op een of ander manier met die metadata service kan kommunikeer).

container.serviceAccounts.createToken

Vanweë die naam van die permission, lyk dit asof dit jou sal toelaat om tokens van die K8s Service Accounts te genereer, sodat jy na enige SA binne Kubernetes kan privesc. Ek kon egter geen API-endpoint vind om dit te gebruik nie; laat weet my as jy dit vind.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Hierdie permissies kan jou moontlik toelaat om privileges in Kubernetes te eskaleer, maar waarskynliker kan jy dit misbruik om in die cluster te persisteer.
Vir meer inligting volg hierdie skakel.

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks