GCP - Container Privesc

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

container

container.clusters.get

यह अनुमति Kubernetes cluster के लिए क्रेडेंशियल्स इकट्ठा करने की अनुमति देती है, जैसे:

Kubernetes cluster के क्रेडेंशियल्स प्राप्त करें ```bash gcloud container clusters get-credentials --zone ```

Without extra permissions, the credentials are pretty basic as you can just list some resource, but hey are useful to find miss-configurations in the environment.

Note

Note that kubernetes clusters might be configured to be private, that will disallow that access to the Kube-API server from the Internet.

If you don’t have this permission you can still access the cluster, but you need to create your own kubectl config file with the clusters info. A new generated one looks like this:

उदाहरण: kubectl config file 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 डिफ़ॉल्ट रूप से prevents प्रिंसिपल्स को उन Roles और ClusterRoles को create या update करने से रोकता है जिनमें उनके पास मौजूद more permissions से अधिक permissions हों। हालांकि, एक GCP प्रिंसिपल जिसके पास ये permissions हों, वह able to create/update Roles/ClusterRoles with more permissions के साथ Roles/ClusterRoles को create/update कर पाएगा, जिससे Kubernetes की इस रक्षा को प्रभावी रूप से बाइपास किया जा सकता है।

container.roles.create और/या container.roles.update OR container.clusterRoles.create और/या container.clusterRoles.update क्रमशः उन privilege escalation क्रियाओं को करने के लिए भी necessary हैं।

container.roles.bind | container.clusterRoles.bind

Kubernetes डिफ़ॉल्ट रूप से प्रिंसिपल्स को RoleBindings और ClusterRoleBindings को create या update करके उन लोगों को more permissions देने से prevents करता है जिनके पास वे permissions नहीं हैं। हालांकि, एक GCP प्रिंसिपल जिसके पास ये permissions हों, वह able to create/update RolesBindings/ClusterRolesBindings with more permissions के साथ RolesBindings/ClusterRolesBindings को create/update कर पाएगा, जिससे Kubernetes की इस सुरक्षा का बायपास हो जाएगा।

container.roleBindings.create और/या container.roleBindings.update OR container.clusterRoleBindings.create और/या container.clusterRoleBindings.update क्रमशः उन privilege escalation क्रियाओं को करने के लिए भी आवश्यक हैं।

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

ये सभी permissions आपको एक ऐसा resource create या update करने की अनुमति देंगे जहाँ आप एक pod define कर सकते हैं। एक pod define करके आप उस SA को specify कर सकते हैं जो attach होगा और वह image specify कर सकते हैं जो run होगी; इसलिए आप ऐसी image चला सकते हैं जो उस SA के token को आपके सर्वर पर exfiltrate कर दे, जिससे आप किसी भी service account पर escalate कर सकेंगे.
For more information check:

चूँकि हम GCP environment में हैं, आप metadata service से nodepool GCP SA भी प्राप्त कर पाएँगे और GCP में privileges escalate कर पाएँगे (डिफ़ॉल्ट रूप से compute SA उपयोग किया जाता है)।

container.secrets.get | container.secrets.list

explained in this page, इन permissions के साथ आप Kubernetes के सभी SAs के tokens पढ़ सकते हैं, इसलिए आप उन SAs तक escalate कर सकते हैं।

container.pods.exec

इस permission के साथ आप exec into pods कर पाएँगे, जिससे आपको pods में चल रहे सभी Kubernetes SAs तक पहुँच मिलती है ताकि आप K8s में privileges escalate कर सकें; साथ ही आप NodePool का GCP Service Account भी steal कर के GCP में privileges escalate कर पाएँगे।

container.pods.portForward

जैसा कि इस पृष्ठ में समझाया गया है, इन permissions के साथ आप pods में चल रहे local services तक पहुँच सकते हैं जो आपको Kubernetes (और अगर किसी तरह आप metadata service से बात कर पाएँ तो GCP में भी) में privileges escalate करने की अनुमति दे सकते हैं।

container.serviceAccounts.createToken

permission के नाम की वजह से यह लगता है कि यह आपको K8s Service Accounts के tokens generate करने की अनुमति देगा, इसलिए आप Kubernetes के अंदर किसी भी SA पर privesc कर पाएँगे। हालांकि, मैं इसे उपयोग करने के लिए कोई API endpoint नहीं ढूँढ पाया/पाई — अगर आप इसे ढूँढते हैं तो बताइए।

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

ये permissions आपको Kubernetes में privileges escalate करने की अनुमति दे सकती हैं, लेकिन अधिक सम्भवतः आप इनका दुरुपयोग करके cluster में persist कर सकते हैं।
For more information follow this link.

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें