Abusing Roles/ClusterRoles in Kubernetes
Last updated
Last updated
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Εδώ μπορείτε να βρείτε κάποιες δυνητικά επικίνδυνες ρυθμίσεις Ρόλων και ClusterRoles.
Θυμηθείτε ότι μπορείτε να αποκτήσετε όλους τους υποστηριζόμενους πόρους με kubectl api-resources
Αναφερόμενοι ως η τέχνη του να αποκτάτε πρόσβαση σε έναν διαφορετικό κύριο εντός του cluster με διαφορετικά προνόμια (εντός του kubernetes cluster ή σε εξωτερικά νέφη) από αυτά που ήδη έχετε, στο Kubernetes υπάρχουν βασικά 4 κύριες τεχνικές για την αύξηση προνομίων:
Να μπορείτε να παριστάνετε άλλους χρήστες/ομάδες/SAs με καλύτερα προνόμια εντός του kubernetes cluster ή σε εξωτερικά νέφη
Να μπορείτε να δημιουργείτε/τροποποιείτε/εκτελείτε pods όπου μπορείτε να βρείτε ή να συνδέσετε SAs με καλύτερα προνόμια εντός του kubernetes cluster ή σε εξωτερικά νέφη
Να μπορείτε να διαβάζετε μυστικά καθώς τα tokens των SAs αποθηκεύονται ως μυστικά
Να μπορείτε να διαφύγετε στον κόμβο από ένα κοντέινερ, όπου μπορείτε να κλέψετε όλα τα μυστικά των κοντέινερ που εκτελούνται στον κόμβο, τα διαπιστευτήρια του κόμβου και τα δικαιώματα του κόμβου εντός του νέφους στο οποίο εκτελείται (αν υπάρχει)
Μια πέμπτη τεχνική που αξίζει να αναφερθεί είναι η ικανότητα να τρέχετε port-forward σε ένα pod, καθώς μπορεί να μπορείτε να αποκτήσετε πρόσβαση σε ενδιαφέροντες πόρους εντός αυτού του pod.
Ο wildcard (*) δίνει άδεια σε οποιονδήποτε πόρο με οποιοδήποτε ρήμα. Χρησιμοποιείται από διαχειριστές. Μέσα σε ένα ClusterRole αυτό σημαίνει ότι ένας επιτιθέμενος θα μπορούσε να καταχραστεί οποιοδήποτε namespace στο cluster
Στο RBAC, ορισμένες άδειες ενέχουν σημαντικούς κινδύνους:
create: Παρέχει τη δυνατότητα δημιουργίας οποιουδήποτε πόρου του cluster, θέτοντας σε κίνδυνο την κλιμάκωση προνομίων.
list: Επιτρέπει την καταγραφή όλων των πόρων, ενδεχομένως διαρρέοντας ευαίσθητα δεδομένα.
get: Επιτρέπει την πρόσβαση σε μυστικά από λογαριασμούς υπηρεσιών, θέτοντας σε κίνδυνο την ασφάλεια.
Ένας επιτιθέμενος με άδειες να δημιουργήσει ένα pod, θα μπορούσε να συνδέσει έναν προνομιούχο Λογαριασμό Υπηρεσίας στο pod και να κλέψει το token για να προσποιηθεί τον Λογαριασμό Υπηρεσίας. Αποτελεσματικά, κλιμακώνοντας τα προνόμια σε αυτόν.
Παράδειγμα ενός pod που θα κλέψει το token του λογαριασμού υπηρεσίας bootstrap-signer και θα το στείλει στον επιτιθέμενο:
Το παρακάτω υποδεικνύει όλα τα προνόμια που μπορεί να έχει ένα κοντέινερ:
Προνομιακή πρόσβαση (απενεργοποίηση προστασιών και ρύθμιση ικανοτήτων)
Απενεργοποίηση namespaces hostIPC και hostPid που μπορούν να βοηθήσουν στην κλιμάκωση προνομίων
Απενεργοποίηση hostNetwork namespace, δίνοντας πρόσβαση για κλοπή των προνομίων cloud των κόμβων και καλύτερη πρόσβαση σε δίκτυα
Σύνδεση hosts / μέσα στο κοντέινερ
Δημιουργήστε το pod με:
One-liner από αυτό το tweet και με μερικές προσθήκες:
Τώρα που μπορείτε να διαφύγετε στον κόμβο, ελέγξτε τις τεχνικές μετα-εκμετάλλευσης στο:
Πιθανώς θέλετε να είστε πιο διακριτικοί. Στις επόμενες σελίδες μπορείτε να δείτε τι θα μπορούσατε να έχετε πρόσβαση αν δημιουργήσετε ένα pod ενεργοποιώντας μόνο ορισμένα από τα προαναφερθέντα δικαιώματα στο προηγούμενο πρότυπο:
Privileged + hostPID
Privileged only
hostPath
hostPID
hostNetwork
hostIPC
Μπορείτε να βρείτε παραδείγματα για το πώς να δημιουργήσετε/εκμεταλλευτείτε τις προηγούμενες ρυθμίσεις privileged pods στο https://github.com/BishopFox/badPods
Αν μπορείτε να δημιουργήσετε ένα pod (και προαιρετικά έναν λογαριασμό υπηρεσίας), μπορεί να είστε σε θέση να αποκτήσετε δικαιώματα σε περιβάλλον cloud αναθέτοντας ρόλους cloud σε ένα pod ή σε έναν λογαριασμό υπηρεσίας και στη συνέχεια να έχετε πρόσβαση σε αυτό. Επιπλέον, αν μπορείτε να δημιουργήσετε ένα pod με το namespace δικτύου του host, μπορείτε να κλέψετε τον ρόλο IAM της περίπτωσης του κόμβου.
Για περισσότερες πληροφορίες ελέγξτε:
Είναι δυνατόν να εκμεταλλευτείτε αυτές τις άδειες για να δημιουργήσετε ένα νέο pod και να αποκτήσετε δικαιώματα όπως στο προηγούμενο παράδειγμα.
Το παρακάτω yaml δημιουργεί ένα daemonset και εξάγει το token του SA μέσα στο pod:
pods/exec είναι ένας πόρος στο kubernetes που χρησιμοποιείται για την εκτέλεση εντολών σε ένα shell μέσα σε ένα pod. Αυτό επιτρέπει να εκτελούνται εντολές μέσα στα containers ή να αποκτάται πρόσβαση σε ένα shell μέσα.
Επομένως, είναι δυνατόν να μπείτε μέσα σε ένα pod και να κλέψετε το token του SA, ή να εισέλθετε σε ένα προνομιούχο pod, να διαφύγετε στον κόμβο και να κλέψετε όλα τα tokens των pods στον κόμβο και (να) (κατα)χρηστείτε τον κόμβο:
Αυτή η άδεια επιτρέπει να προωθείται μία τοπική θύρα σε μία θύρα στο συγκεκριμένο pod. Αυτό προορίζεται για να διευκολύνει την αποσφαλμάτωση εφαρμογών που εκτελούνται μέσα σε ένα pod, αλλά ένας επιτιθέμενος μπορεί να το εκμεταλλευτεί για να αποκτήσει πρόσβαση σε ενδιαφέρουσες (όπως βάσεις δεδομένων) ή ευάλωτες εφαρμογές (ιστοσελίδες;) μέσα σε ένα pod:
Όπως υποδεικνύεται σε αυτή την έρευνα, αν μπορείτε να έχετε πρόσβαση ή να δημιουργήσετε ένα pod με το hosts /var/log/ directory mounted σε αυτό, μπορείτε να ξεφύγετε από το container.
Αυτό συμβαίνει βασικά επειδή όταν ο Kube-API προσπαθεί να πάρει τα logs ενός container (χρησιμοποιώντας kubectl logs <pod>), ζητά το αρχείο 0.log του pod χρησιμοποιώντας το /logs/ endpoint της υπηρεσίας Kubelet.
Η υπηρεσία Kubelet εκθέτει το /logs/ endpoint το οποίο βασικά εκθέτει το filesystem /var/log του container.
Επομένως, ένας επιτιθέμενος με πρόσβαση για εγγραφή στον φάκελο /var/log/ του container θα μπορούσε να εκμεταλλευτεί αυτή τη συμπεριφορά με 2 τρόπους:
Τροποποιώντας το αρχείο 0.log του container του (συνήθως τοποθετημένο στο /var/logs/pods/namespace_pod_uid/container/0.log) ώστε να είναι ένα symlink που δείχνει στο /etc/shadow για παράδειγμα. Στη συνέχεια, θα μπορείτε να εξάγετε το αρχείο shadow των hosts κάνοντας:
Αν ο επιτιθέμενος ελέγχει οποιοδήποτε κύριο με δικαιώματα για ανάγνωση nodes/log, μπορεί απλά να δημιουργήσει ένα symlink στο /host-mounted/var/log/sym προς / και όταν πρόσβαση στο https://<gateway>:10250/logs/sym/ θα καταγράψει το ριζικό σύστημα αρχείων των hosts (η αλλαγή του symlink μπορεί να παρέχει πρόσβαση σε αρχεία).
Ένα εργαστήριο και αυτοματοποιημένη εκμετάλλευση μπορεί να βρεθεί στο https://blog.aquasec.com/kubernetes-security-pod-escape-log-mounts
Αν είστε αρκετά τυχεροί και η πολύ προνομιακή δυνατότητα CAP_SYS_ADMIN είναι διαθέσιμη, μπορείτε απλά να ξανατοποθετήσετε τον φάκελο ως rw:
Όπως αναφέρεται σε αυτή την έρευνα, είναι δυνατόν να παρακαμφθεί η προστασία:
Που είχε σκοπό να αποτρέψει τις διαφυγές όπως οι προηγούμενες, χρησιμοποιώντας αντί για hostPath mount, ένα PersistentVolume και ένα PersistentVolumeClaim για να τοποθετήσει έναν φάκελο του host στο κοντέινερ με δικαιώματα εγγραφής:
Με ένα προνόμιο υποκατάστασης χρήστη, ένας επιτιθέμενος θα μπορούσε να υποκαταστήσει έναν προνομιακό λογαριασμό.
Απλά χρησιμοποιήστε την παράμετρο --as=<username> στην εντολή kubectl για να υποκαταστήσετε έναν χρήστη, ή --as-group=<group> για να υποκαταστήσετε μια ομάδα:
Ή χρησιμοποιήστε το REST API:
Η άδεια να καταγράψει μυστικά θα μπορούσε να επιτρέψει σε έναν επιτιθέμενο να διαβάσει πραγματικά τα μυστικά αποκτώντας πρόσβαση στο REST API endpoint:
Ενώ ένας επιτιθέμενος που κατέχει ένα token με δικαιώματα ανάγνωσης απαιτεί το ακριβές όνομα του μυστικού για να το χρησιμοποιήσει, σε αντίθεση με το ευρύτερο προνόμιο καταγραφής μυστικών, υπάρχουν ακόμα ευπάθειες. Οι προεπιλεγμένοι λογαριασμοί υπηρεσιών στο σύστημα μπορούν να απαριθμηθούν, καθένας από τους οποίους σχετίζεται με ένα μυστικό. Αυτά τα μυστικά έχουν μια δομή ονόματος: ένα στατικό πρόθεμα ακολουθούμενο από έναν τυχαίο αλφαριθμητικό κωδικό πέντε χαρακτήρων (εξαιρουμένων ορισμένων χαρακτήρων) σύμφωνα με τον κώδικα πηγής.
Ο κωδικός δημιουργείται από ένα περιορισμένο σύνολο 27 χαρακτήρων (bcdfghjklmnpqrstvwxz2456789), αντί για το πλήρες αλφαριθμητικό εύρος. Αυτός ο περιορισμός μειώνει τον συνολικό αριθμό πιθανών συνδυασμών σε 14,348,907 (27^5). Ως εκ τούτου, ένας επιτιθέμενος θα μπορούσε να εκτελέσει μια βίαιη επίθεση για να deduce τον κωδικό μέσα σε λίγες ώρες, ενδεχομένως οδηγώντας σε κλιμάκωση προνομίων μέσω της πρόσβασης σε ευαίσθητους λογαριασμούς υπηρεσιών.
Εάν έχετε τα ρήματα create στον πόρο certificatesigningrequests (ή τουλάχιστον στο certificatesigningrequests/nodeClient). Μπορείτε να δημιουργήσετε ένα νέο CeSR ενός νέου κόμβου.
Σύμφωνα με την τεκμηρίωση είναι δυνατό να εγκρίνετε αυτόματα αυτά τα αιτήματα, οπότε σε αυτή την περίπτωση δεν χρειάζεστε επιπλέον δικαιώματα. Αν όχι, θα χρειαστεί να μπορείτε να εγκρίνετε το αίτημα, που σημαίνει ενημέρωση στο certificatesigningrequests/approval και approve στο signers με resourceName <signerNameDomain>/<signerNamePath> ή <signerNameDomain>/*
Ένα παράδειγμα ρόλου με όλα τα απαιτούμενα δικαιώματα είναι:
Έτσι, με την έγκριση του νέου CSR κόμβου, μπορείτε να καταχραστείτε τις ειδικές άδειες των κόμβων για να κλέψετε μυστικά και να κλιμακώσετε προνόμια.
Στο αυτό το άρθρο και σε αυτό η διαμόρφωση TLS Bootstrap του GKE K8s είναι ρυθμισμένη με αυτόματη υπογραφή και καταχράται για να δημιουργήσει διαπιστευτήρια ενός νέου κόμβου K8s και στη συνέχεια να τα καταχραστεί για να κλιμακώσει προνόμια κλέβοντας μυστικά. Αν έχετε τα αναφερόμενα προνόμια, μπορείτε να κάνετε το ίδιο. Σημειώστε ότι το πρώτο παράδειγμα παρακάμπτει το σφάλμα που εμποδίζει έναν νέο κόμβο να έχει πρόσβαση σε μυστικά μέσα σε κοντέινερ, επειδή ένας κόμβος μπορεί να έχει πρόσβαση μόνο στα μυστικά των κοντέινερ που είναι τοποθετημένα σε αυτόν.
Ο τρόπος για να παρακάμψετε αυτό είναι απλώς να δημιουργήσετε διαπιστευτήρια κόμβου για το όνομα του κόμβου όπου είναι τοποθετημένο το κοντέινερ με τα ενδιαφέροντα μυστικά (αλλά απλώς ελέγξτε πώς να το κάνετε στο πρώτο άρθρο):
Οι φορείς που μπορούν να τροποποιήσουν configmaps στο namespace kube-system σε EKS (πρέπει να είναι σε AWS) κλάδους μπορούν να αποκτήσουν προνόμια διαχειριστή του κλάδου αντικαθιστώντας το aws-auth configmap.
Οι ρήτρες που απαιτούνται είναι update και patch, ή create αν το configmap δεν έχει δημιουργηθεί:
Μπορείτε να χρησιμοποιήσετε aws-auth για persistency δίνοντας πρόσβαση σε χρήστες από άλλους λογαριασμούς.
Ωστόσο, aws --profile other_account eks update-kubeconfig --name <cluster-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.
Υπάρχουν 2 τρόποι για να ανατεθούν άδειες K8s σε GCP principals. Σε κάθε περίπτωση, ο principal χρειάζεται επίσης την άδεια container.clusters.get για να μπορέσει να συγκεντρώσει διαπιστευτήρια για να έχει πρόσβαση στο cluster, αλλιώς θα χρειαστεί να δημιουργήσει το δικό του αρχείο ρυθμίσεων kubectl (ακολουθήστε τον επόμενο σύνδεσμο).
Όταν μιλάτε με το K8s api endpoint, το GCP auth token θα σταλεί. Στη συνέχεια, το GCP, μέσω του K8s api endpoint, θα ελέγξει πρώτα αν ο principal (με email) έχει πρόσβαση μέσα στο cluster, και μετά θα ελέγξει αν έχει οποιαδήποτε πρόσβαση μέσω GCP IAM. Αν οποιοδήποτε από αυτά είναι αληθινό, θα απαντηθεί. Αν όχι, θα δοθεί ένα σφάλμα που προτείνει να δοθούν άδειες μέσω GCP IAM.
Στη συνέχεια, η πρώτη μέθοδος είναι η χρήση του GCP IAM, οι άδειες K8s έχουν τις ισοδύναμες άδειες GCP IAM, και αν ο principal τις έχει, θα μπορεί να τις χρησιμοποιήσει.
Η δεύτερη μέθοδος είναι η ανάθεση αδειών K8s μέσα στο cluster αναγνωρίζοντας τον χρήστη μέσω του email του (συμπεριλαμβανομένων των λογαριασμών υπηρεσιών GCP).
Principals που μπορούν να δημιουργήσουν TokenRequests (serviceaccounts/token) όταν μιλούν με το K8s api endpoint SAs (πληροφορίες από εδώ).
Principals που μπορούν να update ή patch pods/ephemeralcontainers μπορούν να αποκτήσουν εκτέλεση κώδικα σε άλλα pods, και δυνητικά να σπάσουν στο node τους προσθέτοντας ένα ephemeral container με ένα privileged securityContext.
Principals με οποιοδήποτε από τα ρήματα create, update ή patch πάνω σε validatingwebhookconfigurations ή mutatingwebhookconfigurations μπορεί να είναι σε θέση να δημιουργήσουν μία από αυτές τις webhookconfigurations προκειμένου να μπορέσουν να αναβαθμίσουν τις άδειες.
Για ένα mutatingwebhookconfigurations παράδειγμα ελέγξτε αυτή την ενότητα της ανάρτησης.
Όπως μπορείτε να διαβάσετε στην επόμενη ενότητα: Built-in Privileged Escalation Prevention, ένας principal δεν μπορεί να ενημερώσει ούτε να δημιουργήσει ρόλους ή clusterroles χωρίς να έχει ο ίδιος αυτές τις νέες άδειες. Εκτός αν έχει το ρήμα escalate πάνω σε roles ή clusterroles.
Τότε μπορεί να ενημερώσει/δημιουργήσει νέους ρόλους, clusterroles με καλύτερες άδειες από αυτές που έχει.
Principals με πρόσβαση στο nodes/proxy υποπόρο μπορούν να εκτελούν κώδικα σε pods μέσω του Kubelet API (σύμφωνα με αυτό). Περισσότερες πληροφορίες σχετικά με την αυθεντικοποίηση Kubelet σε αυτή τη σελίδα:
Έχετε ένα παράδειγμα για το πώς να αποκτήσετε RCE μιλώντας εξουσιοδοτημένα σε ένα Kubelet API εδώ.
Principals που μπορούν να διαγράψουν pods (delete ρήμα πάνω σε pods πόρο), ή να εκδιώξουν pods (create ρήμα πάνω σε pods/eviction πόρο), ή να αλλάξουν την κατάσταση του pod (πρόσβαση σε pods/status) και μπορούν να κάνουν άλλα nodes μη προγραμματίσιμα (πρόσβαση σε nodes/status) ή να διαγράψουν nodes (delete ρήμα πάνω σε nodes πόρο) και έχουν έλεγχο πάνω σε ένα pod, θα μπορούσαν να κλέψουν pods από άλλα nodes ώστε να εκτελούνται στο συμβιβασμένο node και ο επιτιθέμενος μπορεί να κλέψει τα tokens από αυτά τα pods.
Οι φορείς που μπορούν να τροποποιήσουν services/status μπορεί να ρυθμίσουν το πεδίο status.loadBalancer.ingress.ip για να εκμεταλλευτούν το μη διορθωμένο CVE-2020-8554 και να ξεκινήσουν MiTM επιθέσεις κατά του cluster. Οι περισσότερες μετρήσεις για το CVE-2020-8554 αποτρέπουν μόνο τις υπηρεσίες ExternalIP (σύμφωνα με αυτό).
Οι φορείς με update ή patch δικαιώματα πάνω σε nodes/status ή pods/status, θα μπορούσαν να τροποποιήσουν τις ετικέτες για να επηρεάσουν τους περιορισμούς προγραμματισμού που επιβάλλονται.
Το Kubernetes διαθέτει έναν ενσωματωμένο μηχανισμό για την πρόληψη της κλιμάκωσης δικαιωμάτων.
Αυτό το σύστημα διασφαλίζει ότι οι χρήστες δεν μπορούν να αυξήσουν τα δικαιώματά τους τροποποιώντας ρόλους ή δεσμεύσεις ρόλων. Η επιβολή αυτού του κανόνα συμβαίνει σε επίπεδο API, παρέχοντας μια προστασία ακόμη και όταν ο RBAC authorizer είναι ανενεργός.
Ο κανόνας stipulates ότι ένας χρήστης μπορεί να δημιουργήσει ή να ενημερώσει έναν ρόλο μόνο εάν κατέχει όλα τα δικαιώματα που περιλαμβάνει ο ρόλος. Επιπλέον, το εύρος των υπαρχόντων δικαιωμάτων του χρήστη πρέπει να ευθυγραμμίζεται με αυτό του ρόλου που προσπαθεί να δημιουργήσει ή να τροποποιήσει: είτε σε επίπεδο cluster για ClusterRoles είτε περιορισμένο στο ίδιο namespace (ή σε επίπεδο cluster) για Roles.
Υπάρχει μια εξαίρεση στον προηγούμενο κανόνα. Εάν ένας φορέας έχει το ρήμα escalate πάνω σε roles ή clusterroles μπορεί να αυξήσει τα δικαιώματα των ρόλων και των clusterroles ακόμη και χωρίς να έχει τα δικαιώματα ο ίδιος.
Φαίνεται ότι αυτή η τεχνική λειτουργούσε πριν, αλλά σύμφωνα με τις δοκιμές μου δεν λειτουργεί πια για τον ίδιο λόγο που εξηγήθηκε στην προηγούμενη ενότητα. Δεν μπορείτε να δημιουργήσετε/τροποποιήσετε μια rolebinding για να δώσετε στον εαυτό σας ή σε έναν διαφορετικό SA κάποια δικαιώματα αν δεν έχετε ήδη.
Το δικαίωμα να δημιουργήσετε Rolebindings επιτρέπει σε έναν χρήστη να δεσμεύσει ρόλους σε έναν λογαριασμό υπηρεσίας. Αυτό το δικαίωμα μπορεί δυνητικά να οδηγήσει σε κλιμάκωση δικαιωμάτων επειδή επιτρέπει στον χρήστη να δεσμεύσει δικαιώματα διαχειριστή σε έναν συμβιβασμένο λογαριασμό υπηρεσίας.
Από προεπιλογή δεν υπάρχει κρυπτογράφηση στην επικοινωνία μεταξύ των pods. Αμοιβαία πιστοποίηση, αμφίδρομη, pod προς pod.
Δημιουργήστε το .yaml
Επεξεργαστείτε το .yaml σας και προσθέστε τις μη σχολιασμένες γραμμές:
Δείτε τα αρχεία καταγραφής του proxy:
Περισσότερες πληροφορίες στο: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Ένας ελεγκτής εισόδου παρεμβαίνει σε αιτήματα προς τον διακομιστή API του Kubernetes πριν από την αποθήκευση του αντικειμένου, αλλά μετά την πιστοποίηση και την εξουσιοδότηση του αιτήματος.
Εάν ένας επιτιθέμενος καταφέρει με κάποιο τρόπο να εισάγει έναν Κακόβουλο Ελεγκτή Εισόδου, θα είναι σε θέση να τροποποιήσει ήδη πιστοποιημένα αιτήματα. Έχοντας τη δυνατότητα να αποκτήσει προνόμια, και πιο συχνά να παραμείνει στο cluster.
Παράδειγμα από https://blog.rewanthtammana.com/creating-malicious-admission-controllers:
Έλεγχος της κατάστασης για να δούμε αν είναι έτοιμο:
Στη συνέχεια, αναπτύξτε ένα νέο pod:
Όταν μπορείτε να δείτε το σφάλμα ErrImagePull, ελέγξτε το όνομα της εικόνας με μία από τις ερωτήσεις:
Όπως μπορείτε να δείτε στην παραπάνω εικόνα, προσπαθήσαμε να εκτελέσουμε την εικόνα nginx, αλλά η τελική εκτελούμενη εικόνα είναι rewanthtammana/malicious-image. Τι μόλις συνέβη!!;
Το σενάριο ./deploy.sh δημιουργεί έναν μεταβαλλόμενο ελεγκτή εισόδου webhook, ο οποίος τροποποιεί τα αιτήματα προς το Kubernetes API όπως καθορίζεται στις γραμμές διαμόρφωσής του, επηρεάζοντας τα αποτελέσματα που παρατηρούνται:
The above snippet replaces the first container image in every pod with rewanthtammana/malicious-image.
Pods και Λογαριασμοί Υπηρεσίας: Από προεπιλογή, τα pods τοποθετούν ένα διακριτικό λογαριασμού υπηρεσίας. Για να ενισχυθεί η ασφάλεια, το Kubernetes επιτρέπει την απενεργοποίηση αυτής της αυτόματης τοποθέτησης.
Πώς να Εφαρμόσετε: Ορίστε automountServiceAccountToken: false στη διαμόρφωση των λογαριασμών υπηρεσίας ή των pods από την έκδοση 1.6 του Kubernetes.
Επιλεκτική Συμπερίληψη: Βεβαιωθείτε ότι μόνο οι απαραίτητοι χρήστες περιλαμβάνονται σε RoleBindings ή ClusterRoleBindings. Ελέγχετε τακτικά και αφαιρείτε μη σχετικούς χρήστες για να διατηρείτε σφιχτή ασφάλεια.
Ρόλοι vs. ClusterRoles: Προτιμήστε τη χρήση Ρόλων και RoleBindings για άδειες συγκεκριμένες σε namespace αντί για ClusterRoles και ClusterRoleBindings, που ισχύουν σε όλο το cluster. Αυτή η προσέγγιση προσφέρει πιο λεπτομερή έλεγχο και περιορίζει την έκταση των αδειών.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
