GCP - Container Privesc

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

kontener

container.clusters.get

To uprawnienie pozwala na zebranie poświadczeń dla klastra Kubernetes za pomocą czegoś takiego jak:

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

Bez dodatkowych uprawnień, poświadczenia są dość podstawowe, ponieważ można tylko wyświetlić pewne zasoby, ale są one przydatne do znalezienia błędów konfiguracji w środowisku.

Zauważ, że klastry Kubernetes mogą być skonfigurowane jako prywatne, co uniemożliwia dostęp do serwera Kube-API z Internetu.

Jeśli nie masz tych uprawnień, nadal możesz uzyskać dostęp do klastra, ale musisz utworzyć własny plik konfiguracyjny kubectl z informacjami o klastrach. Nowo wygenerowany plik wygląda tak:

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

Domyślnie Kubernetes uniemożliwia podmiotom tworzenie lub aktualizowanie ról i clusterRól z większymi uprawnieniami niż te, które posiada podmiot. Jednak podmiot GCP posiadający te uprawnienia będzie mógł tworzyć/aktualizować role/clusterRole z większymi uprawnieniami niż te, które posiada, co umożliwia obejście ochrony Kubernetes przed tym zachowaniem.

Wymagane są również uprawnienia container.roles.create i/lub container.roles.update LUB container.clusterRoles.create i/lub container.clusterRoles.update do wykonania tych działań eskalacji uprawnień.

container.roles.bind | container.clusterRoles.bind

Domyślnie Kubernetes uniemożliwia podmiotom tworzenie lub aktualizowanie RoleBindings i ClusterRoleBindings w celu nadania większych uprawnień niż te, które posiada podmiot. Jednak podmiot GCP posiadający te uprawnienia będzie mógł tworzyć/aktualizować RoleBindings/ClusterRoleBindings z większymi uprawnieniami niż te, które posiada, co umożliwia obejście ochrony Kubernetes przed tym zachowaniem.

Wymagane są również uprawnienia container.roleBindings.create i/lub container.roleBindings.update LUB container.clusterRoleBindings.create i/lub container.clusterRoleBindings.update do wykonania tych działań eskalacji uprawnień.

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

Wszystkie te uprawnienia umożliwiają tworzenie lub aktualizowanie zasobu, w którym można zdefiniować pod. Definiując pod, można określić SA, który zostanie do niego dołączony, oraz obraz, który zostanie uruchomiony. Dzięki temu można uruchomić obraz, który wykradnie token SA do twojego serwera, umożliwiając eskalację do dowolnego konta usługi. Aby uzyskać więcej informacji, sprawdź:

Ponieważ jesteśmy w środowisku GCP, będziesz również mógł uzyskać SA nodepoola z usługi metadanych i eskalować uprawnienia w GCP (domyślnie używane jest SA obliczeniowe).

container.secrets.get | container.secrets.list

Z tymi uprawnieniami można odczytać tokeny wszystkich SA w Kubernetes, co umożliwia eskalację do nich.

container.pods.exec

Dzięki temu uprawnieniu będziesz mógł wykonać polecenie wewnątrz podów, co daje dostęp do wszystkich SA Kubernetes działających w podach, umożliwiając eskalację uprawnień w K8s. Będziesz również mógł ukraść GCP Service Account z NodePool, eskalując uprawnienia w GCP.

container.pods.portForward

Z tymi uprawnieniami można uzyskać dostęp do lokalnych usług uruchomionych w podach, co może umożliwić eskalację uprawnień w Kubernetes (i w GCP, jeśli uda ci się somehow porozmawiać z usługą metadanych).

container.serviceAccounts.createToken

Ze względu na nazwę uprawnienia wydaje się, że umożliwia generowanie tokenów kont usług K8s, dzięki czemu będziesz mógł eskalować uprawnienia do dowolnego SA wewnątrz Kubernetes. Jednak nie znalazłem żadnego punktu końcowego API do jego użycia, więc daj mi znać, jeśli go znajdziesz.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Te uprawnienia mogą umożliwić eskalację uprawnień w Kubernetes, ale bardziej prawdopodobne jest, że można je wykorzystać do trwałego pozostania w klastrze. Aby uzyskać więcej informacji, kliknij tutaj.

Last updated