GCP - Container Privesc

Support HackTricks

container

container.clusters.get

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

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

बिना अतिरिक्त अनुमतियों के, क्रेडेंशियल्स काफी बुनियादी होते हैं क्योंकि आप कुछ संसाधनों की सूची बना सकते हैं, लेकिन ये वातावरण में गलत कॉन्फ़िगरेशन खोजने के लिए उपयोगी होते हैं।

ध्यान दें कि क्यूबेरनेट्स क्लस्टर को निजी रूप से कॉन्फ़िगर किया जा सकता है, जो इंटरनेट से Kube-API सर्वर तक पहुंच को अस्वीकार करेगा।

यदि आपके पास यह अनुमति नहीं है, तो आप अभी भी क्लस्टर तक पहुंच सकते हैं, लेकिन आपको क्लस्टर की जानकारी के साथ अपना खुद का kubectl कॉन्फ़िग फ़ाइल बनाना होगा। एक नया उत्पन्न किया गया फ़ाइल इस तरह दिखता है:

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 डिफ़ॉल्ट रूप से रोकता है कि प्रिंसिपल निर्माण या अपडेट Roles और ClusterRoles को अधिक अनुमतियों के साथ कर सकें जो प्रिंसिपल के पास हैं। हालाँकि, एक GCP प्रिंसिपल जिसके पास वह अनुमतियाँ हैं, अधिक अनुमतियों के साथ Roles/ClusterRoles को निर्माण/अपडेट करने में सक्षम होगा, प्रभावी रूप से Kubernetes के इस व्यवहार के खिलाफ सुरक्षा को बायपास करते हुए।

container.roles.create और/या container.roles.update या container.clusterRoles.create और/या container.clusterRoles.update क्रमशः उन विशेषाधिकार वृद्धि क्रियाओं को करने के लिए भी आवश्यक हैं।

container.roles.bind | container.clusterRoles.bind

Kubernetes डिफ़ॉल्ट रूप से रोकता है कि प्रिंसिपल निर्माण या अपडेट RoleBindings और ClusterRoleBindings को अधिक अनुमतियों के साथ कर सकें जो प्रिंसिपल के पास हैं। हालाँकि, एक GCP प्रिंसिपल जिसके पास वह अनुमतियाँ हैं, अधिक अनुमतियों के साथ RolesBindings/ClusterRolesBindings को निर्माण/अपडेट करने में सक्षम होगा, प्रभावी रूप से Kubernetes के इस व्यवहार के खिलाफ सुरक्षा को बायपास करते हुए।

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

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

इन सभी अनुमतियों से आपको एक संसाधन बनाने या अपडेट करने की अनुमति मिलेगी जहाँ आप एक पोड को परिभाषित कर सकते हैं। एक पोड को परिभाषित करते समय आप SA को निर्धारित कर सकते हैं जो संलग्न किया जाएगा और छवि जो चलायी जाएगी, इसलिए आप एक छवि चला सकते हैं जो SA के टोकन को आपके सर्वर पर एक्सफिल्ट्रेट करेगी जिससे आप किसी भी सेवा खाते में वृद्धि कर सकें। अधिक जानकारी के लिए देखें:

चूंकि हम एक GCP वातावरण में हैं, आप मेटाडेटा सेवा से नोडपूल GCP SA को भी प्राप्त कर सकेंगे और GCP में विशेषाधिकार बढ़ा सकेंगे (डिफ़ॉल्ट रूप से कंप्यूट SA का उपयोग किया जाता है)।

container.secrets.get | container.secrets.list

जैसा कि इस पृष्ठ में समझाया गया है, इन अनुमतियों के साथ आप कुबेरनेट्स के सभी SA के टोकन को पढ़ सकते हैं, इसलिए आप उनके लिए विशेषाधिकार बढ़ा सकते हैं।

container.pods.exec

इस अनुमति के साथ आप पोड्स में exec करने में सक्षम होंगे, जो आपको कुबरनेट्स SA तक पहुँच प्रदान करता है जो पोड्स में चल रहे हैं ताकि आप K8s के भीतर विशेषाधिकार बढ़ा सकें, लेकिन आप नोडपूल का GCP सेवा खाता भी चुरा सकते हैं, GCP में विशेषाधिकार बढ़ाते हुए

container.pods.portForward

जैसा कि इस पृष्ठ में समझाया गया है, इन अनुमतियों के साथ आप पोड्स में चल रहे स्थानीय सेवाओं तक पहुँच प्राप्त कर सकते हैं जो आपको कुबरनेट्स में विशेषाधिकार बढ़ाने की अनुमति दे सकते हैं (और GCP में यदि आप किसी तरह मेटाडेटा सेवा से बात करने में सफल होते हैं)

container.serviceAccounts.createToken

अनुमति के नाम के कारण, यह लगता है कि यह आपको K8s सेवा खातों के टोकन उत्पन्न करने की अनुमति देगा, इसलिए आप कुबेरनेट्स के भीतर किसी भी SA के लिए विशेषाधिकार बढ़ा सकेंगे। हालाँकि, मैं इसका उपयोग करने के लिए कोई API एंडपॉइंट नहीं ढूंढ सका, इसलिए यदि आप इसे ढूंढते हैं तो मुझे बताएं।

container.mutatingWebhookConfigurations.create | container.mutatingWebhookConfigurations.update

ये अनुमतियाँ आपको कुबेरनेट्स में विशेषाधिकार बढ़ाने की अनुमति दे सकती हैं, लेकिन अधिक संभावना है, आप उनका दुरुपयोग करके क्लस्टर में स्थायी हो सकते हैं। अधिक जानकारी के लिए इस लिंक का पालन करें.

Support HackTricks

Last updated