AWS - EKS Post Exploitation
Last updated
Last updated
Για περισσότερες πληροφορίες ελέγξτε
Αν έχετε την άδεια eks:AccessKubernetesApi
μπορείτε να προβάλετε αντικείμενα Kubernetes μέσω της κονσόλας AWS EKS (Μάθετε περισσότερα).
Εύκολος τρόπος:
Δεν είναι τόσο εύκολο:
Αν μπορείτε να αποκτήσετε ένα τεκμήριο με την εντολή aws eks get-token --name <cluster_name>
αλλά δεν έχετε δικαιώματα να λάβετε πληροφορίες για το cluster (describeCluster), μπορείτε να προετοιμάσετε το δικό σας ~/.kube/config
. Ωστόσο, έχοντας το τεκμήριο, χρειάζεστε ακόμα το url endpoint για σύνδεση (αν καταφέρατε να λάβετε ένα JWT τεκμήριο από ένα pod διαβάστε εδώ) και το όνομα του cluster.
Στην περίπτωσή μου, δεν βρήκα τις πληροφορίες στα CloudWatch logs, αλλά τις βρήκα στα userData των LaunchTemplates και επίσης στα EC2 μηχανήματα στα userData επίσης. Μπορείτε να δείτε αυτές τις πληροφορίες στο userData εύκολα, για παράδειγμα στο επόμενο παράδειγμα (το όνομα του cluster ήταν cluster-name):
Ο δημιουργός του EKS cluster θα έχει πάντα πρόσβαση στο τμήμα του kubernetes cluster της ομάδας system:masters
(k8s admin). Προς το παρόν δεν υπάρχει άμεσος τρόπος να βρείτε ποιος δημιούργησε το cluster (μπορείτε να ελέγξετε το CloudTrail). Και δεν υπάρχει τρόπος να αφαιρέσετε αυτό το προνόμιο.
Ο τρόπος για να χορηγήσετε πρόσβαση στο K8s σε περισσότερους χρήστες ή ρόλους AWS IAM είναι μέσω του configmap aws-auth
.
Συνεπώς, οποιοσδήποτε με δικαίωμα εγγραφής στο config map aws-auth
θα μπορεί να θέσει σε κίνδυνο ολόκληρο το cluster.
Για περισσότερες πληροφορίες σχετικά με το πώς να χορηγήσετε επιπλέον προνόμια σε ρόλους & χρήστες IAM στο ίδιο ή διαφορετικό λογαριασμό και πώς να καταχραστείτε αυτό για έλεγχο προνομίων ελέγξτε αυτήν τη σελίδα.
Ελέγξτε επίσης αυτήν την εκπληκτική ανάρτηση για να μάθετε πώς λειτουργεί η πιστοποίηση IAM -> Kubernetes.
Είναι δυνατόν να επιτραπεί μια ταυτοποίηση OpenID για λογαριασμό υπηρεσίας Kubernetes ώστε να τους επιτραπεί να υιοθετήσουν ρόλους στο AWS. Μάθετε πώς λειτουργεί αυτό σε αυτήν τη σελίδα.
Δεν βρέθηκε κάποια τεκμηρίωση που εξηγεί τα κριτήρια για τα 'two chars' και το 'number'. Ωστόσο, κάνοντας μερικές δοκιμές μόνος μου, βλέπω να επαναλαμβάνονται τα παρακάτω:
gr7
yl4
Πάντως, είναι μόνο 3 χαρακτήρες και μπορούμε να τους αναζητήσουμε με βία. Χρησιμοποιήστε το παρακάτω script για τη δημιουργία της λίστας.
Στη συνέχεια με το wfuzz
Να θυμάστε να αντικαταστήσετε τα & .
Εάν ένας εισβολέας αποκτήσει διαπιστευτήρια ενός AWS με άδειες πάνω σε ένα EKS. Εάν ο εισβολέας διαμορφώσει το δικό του kubeconfig
(χωρίς να καλέσει το update-kubeconfig
) όπως εξηγήθηκε προηγουμένως, το get-token
δεν δημιουργεί καταγραφές στο CloudTrail επειδή δεν αλληλεπιδρά με το AWS API (απλά δημιουργεί το token τοπικά).
Έτσι, όταν ο εισβολέας επικοινωνεί με το EKS cluster, το cloudtrail δεν καταγράφει τίποτα σχετικά με τον χρήστη που έχει κλαπεί και έχει πρόσβαση σε αυτό.
Να σημειωθεί ότι το EKS cluster μπορεί να έχει ενεργοποιημένα logs που θα καταγράφουν αυτήν την πρόσβαση (αν και, από προεπιλογή, είναι απενεργοποιημένα).
Από προεπιλογή, ο χρήστης ή ρόλος που δημιούργησε ένα cluster θα έχει πάντα δικαιώματα διαχειριστή πάνω στο cluster. Και αυτή είναι η μοναδική "ασφαλής" πρόσβαση που θα έχει το AWS στο Kubernetes cluster.
Έτσι, εάν ένας εισβολέας διακινδυνεύει ένα cluster χρησιμοποιώντας fargate και αφαιρεί όλους τους άλλους διαχειριστές και διαγράφει τον AWS χρήστη/ρόλο που δημιούργησε το Cluster, ο εισβολέας θα μπορούσε να έχει ζητήσει λύτρα για το clusterr.
Να σημειωθεί ότι εάν το cluster χρησιμοποιούσε EC2 VMs, θα μπορούσε να είναι δυνατή η απόκτηση δικαιωμάτων διαχειριστή από τον Node και η ανάκτηση του cluster.
Πράγματι, εάν το cluster χρησιμοποιεί Fargate, θα μπορούσατε να χρησιμοποιήσετε τους κόμβους EC2 ή να μεταφέρετε τα πάντα σε EC2 στο cluster και να το ανακτήσετε έχοντας πρόσβαση στα τοκεν στον κόμβο.
Αποκωδικοποιώντας το διακριτικό JWT λαμβάνουμε το αναγνωριστικό του cluster και επίσης την περιοχή. Γνωρίζοντας ότι η τυπική μορφή για το URL του EKS είναι