GCP - Container Privesc

Wesprzyj HackTricks

kontener

container.clusters.get

To uprawnienie pozwala zbierać poświadczenia 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żesz tylko wymienić niektóre 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 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 podmiotom możliwość tworzenia lub aktualizowania Ról 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, efektywnie omijając ochronę Kubernetesa 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 podmiotom możliwość tworzenia lub aktualizowania RoleBindings i ClusterRoleBindings w celu nadania większych 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, efektywnie omijając ochronę Kubernetesa 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 utworzyć lub zaktualizować zasób, w którym możesz zdefiniować poddziałkę. Definiując podziałkę, możesz określić SA, który będzie dołączony oraz obraz, który będzie uruchomiony, dlatego możesz uruchomić obraz, który wyciągnie token SA na Twój serwer, umożliwiając Ci 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 GCP z usługi metadanych i eskalertować uprawnienia w GCP (domyślnie używane jest SA obliczeniowe).

container.secrets.get | container.secrets.list

Zgodnie z wyjaśnieniem na tej stronie, z tymi uprawnieniami możesz odczytać tokeny wszystkich SA Kubernetesa, 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 Kubernetesa działających w podach do eskalacji uprawnień w K8s, ale także będziesz mógł ukraść GCP Service Account z NodePool, eskalertują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 umożliwić Ci eskalertowanie uprawnień w Kubernetes (i w GCP jeśli jakoś uda Ci się połączyć z usługą metadanych).

container.serviceAccounts.createToken

Ze względu na nazwę uprawnienia, wygląda na to, że pozwoli Ci to generować tokeny kont usługi K8s, dzięki czemu będziesz mógł eskalertować do dowolnego SA wewnątrz Kubernetesa. 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ć Ci eskalację uprawnień w Kubernetes, ale bardziej prawdopodobne jest, że możesz je wykorzystać do utrzymania się w klastrze. Aby uzyskać więcej informacji kliknij ten link.

Wesprzyj HackTricks

Last updated