GCP - Container Privesc

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

kontener

container.clusters.get

To uprawnienie pozwala na zbieranie poświadczeń dla klastra Kubernetes przy użyciu czegoś takiego jak:

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

Bez dodatkowych uprawnień, poświadczenia są dość podstawowe, ponieważ możesz po prostu wylistować niektóre zasoby, ale są przydatne do znajdowania błędów w konfiguracji w środowisku.

Zauważ, że klastry kubernetes mogą być skonfigurowane jako prywatne, co uniemożliwi 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

Kubernetes domyślnie zapobiega temu, aby podmioty mogły tworzyć lub aktualizować Role i ClusterRoles z większymi uprawnieniami niż te, które posiada podmiot. Jednak podmiot GCP z tymi uprawnieniami będzie mógł tworzyć/aktualizować Role/ClusterRoles z większymi uprawnieniami niż te, które posiada, skutecznie omijając ochronę Kubernetes przed tym zachowaniem.

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

container.roles.bind | container.clusterRoles.bind

Kubernetes domyślnie zapobiega temu, aby podmioty mogły tworzyć lub aktualizować RoleBindings i ClusterRoleBindings, aby nadać więcej uprawnień niż te, które posiada podmiot. Jednak podmiot GCP z tymi uprawnieniami będzie mógł tworzyć/aktualizować RoleBindings/ClusterRolesBindings z większymi uprawnieniami niż te, które posiada, skutecznie omijając ochronę Kubernetes przed tym zachowaniem.

container.roleBindings.create i/lub container.roleBindings.update LUB container.clusterRoleBindings.create i/lub container.clusterRoleBindings.update są również konieczne 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 pozwolą ci tworzyć lub aktualizować zasób, w którym możesz zdefiniować pod. Definiując pod, możesz określić SA, który będzie przypisany oraz obraz, który będzie uruchamiany, dzięki czemu możesz uruchomić obraz, który wyeksfiltruje token SA na twój serwer, umożliwiając ci eskalację do dowolnego konta serwisowego. Aby uzyskać więcej informacji, sprawdź:

Ponieważ jesteśmy w środowisku GCP, będziesz również w stanie uzyskać SA nodepool GCP z usługi metadata i eskalować uprawnienia w GCP (domyślnie używany jest SA compute).

container.secrets.get | container.secrets.list

Jak wyjaśniono na tej stronie, z tymi uprawnieniami możesz czytać tokeny wszystkich SA Kubernetes, więc możesz się do nich eskalować.

container.pods.exec

Dzięki temu uprawnieniu będziesz mógł wykonać polecenie w podach, co daje ci dostęp do wszystkich SA Kubernetes działających w podach, aby eskalować uprawnienia w K8s, ale także będziesz mógł ukraść GCP Service Account z NodePool, eskalując uprawnienia w GCP.

container.pods.portForward

Jak wyjaśniono na tej stronie, z tymi uprawnieniami możesz uzyskać dostęp do lokalnych usług działających w podach, co może pozwolić ci eskalować uprawnienia w Kubernetes (i w GCP, jeśli w jakiś sposób uda ci się skontaktować z usługą metadata).

container.serviceAccounts.createToken

Z powodu nazwa uprawnienia, wydaje się, że pozwoli ci to generować tokeny K8s Service Accounts, więc będziesz mógł eskalować do dowolnego SA wewnątrz Kubernetes. Jednak nie mogłem znaleźć żadnego punktu końcowego API, aby go użyć, więc daj mi 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, że możesz je wykorzystać do utrzymania się w klastrze. Aby uzyskać więcej informacji, śledź ten link.

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

• Sprawdź plany subskrypcyjne!

• Dołącz do 💬 grupy Discord lub grupy telegram lub śledź nas na Twitterze 🐦 @hacktricks_live.

• Podziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.