GCP - Container Privesc

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks

container

container.clusters.get

To uprawnienie umożliwia pozyskanie poświadczeń klastra Kubernetes przy użyciu czegoś takiego:

Pobierz poświadczenia klastra Kubernetes ```bash gcloud container clusters get-credentials --zone ```

Bez dodatkowych uprawnień poświadczenia są dość podstawowe — możesz tylko wylistować niektóre zasoby, ale i tak są przydatne do wykrywania błędów konfiguracji w środowisku.

Note

Zwróć uwagę, że kubernetes clusters mogą być skonfigurowane jako prywatne, co uniemożliwi dostęp do Kube-API server z Internetu.

Jeśli nie masz tego uprawnienia, nadal możesz uzyskać dostęp do klastra, ale musisz utworzyć własny kubectl config file z informacjami o klastrze. Nowo wygenerowany wygląda tak:

Przykładowy kubectl config file dla klastra GKE ```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 domyślnie uniemożliwia podmiotom tworzenie lub aktualizowanie Roles i ClusterRoles z większymi uprawnieniami niż te, które posiada dany podmiot. Jednakże podmiot GCP posiadający te uprawnienia będzie w stanie tworzyć/aktualizować Roles/ClusterRoles z większymi uprawnieniami niż posiadał, skutecznie obejmując mechanizmy ochronne Kubernetes przed takim zachowaniem.

container.roles.create i/lub container.roles.update LUB container.clusterRoles.create i/lub container.clusterRoles.update są odpowiednio również niezbędne do przeprowadzenia tych działań eskalacji uprawnień.

container.roles.bind | container.clusterRoles.bind

Kubernetes domyślnie uniemożliwia podmiotom tworzenie lub aktualizowanie RoleBindings i ClusterRoleBindings w celu nadania większych uprawnień niż te, które posiada dany podmiot. Jednakże podmiot GCP posiadający te uprawnienia będzie w stanie tworzyć/aktualizować RoleBindings/ClusterRoleBindings z większymi uprawnieniami niż posiada, skutecznie obejmując mechanizmy ochronne Kubernetes przed tym zachowaniem.

container.roleBindings.create i/lub container.roleBindings.update LUB container.clusterRoleBindings.create i/lub container.clusterRoleBindings.update są odpowiednio również niezbędne do przeprowadzenia 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 pozwolą ci utworzyć lub zaktualizować zasób, w którym możesz zdefiniować pod. Definiując pod możesz określić SA, który zostanie do niego przypisany, oraz image, który zostanie uruchomiony, dzięki czemu możesz uruchomić obraz, który wyeksfiltruje token SA na twój serwer, pozwalając ci eskalować do dowolnego service account.
Po więcej informacji sprawdź:

Jako że działamy w środowisku GCP, będziesz również w stanie pobrać nodepool GCP SA z serwisu metadata i escalate privileges in GCP (domyślnie używany jest compute SA).

container.secrets.get | container.secrets.list

Jak wyjaśniono na tej stronie, z tymi uprawnieniami możesz odczytać tokeny wszystkich SA w Kubernetes, więc możesz na nie eskalować.

container.pods.exec

Z tym uprawnieniem będziesz mógł exec into pods, co daje ci dostęp do wszystkich Kubernetes SA uruchomionych w podach w celu eskalacji uprawnień w K8s, ale także będziesz w stanie ukraść GCP Service Account z NodePool, escalating privileges in GCP.

container.pods.portForward

Jak wyjaśniono na tej stronie, z tymi uprawnieniami możesz dostępować lokalnych usług działających w podach, które mogą pozwolić ci escalate privileges in Kubernetes (i w GCP, jeśli w jakiś sposób uda ci się porozmawiać z serwisem metadata).

container.serviceAccounts.createToken

Ze względu na nazwę tego uprawnienia, wygląda na to, że pozwoli ono wygenerować tokeny K8s Service Accounts, więc będziesz mógł privesc do dowolnego SA wewnątrz Kubernetes. Jednak nie znalazłem żadnego endpointu API, który by to obsługiwał — daj znać, jeśli go znajdziesz.

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

Te uprawnienia mogą pozwolić ci na eskalację uprawnień w Kubernetes, ale bardziej prawdopodobne jest to, że możesz je nadużyć, aby utrzymać trwały dostęp w klastrze.
Po więcej informacji follow this link.

Tip

Ucz się & ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się & ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się & ćwicz Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Wspieraj HackTricks