बढ़ते लॉग के माध्यम से कुबेरनेट्स में फली से परे जाना

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



कुबेरनेट में कई घटक होते हैं, और कभी-कभी उन्हें एक निश्चित तरीके से संयोजित करने से अप्रत्याशित परिणाम प्राप्त होते हैं। इस लेख में मैं दिखाऊंगा कि कैसे रूट के विशेषाधिकारों के साथ एक पॉड लॉन्च किया गया और नोड का एक माउंटेड /var/log डायरेक्टरी पूरे होस्ट फाइल सिस्टम की सामग्री को अपने लॉग तक पहुंच के साथ एक उपयोगकर्ता तक पहुंचा सकती है। हम इस समस्या के समाधान पर भी चर्चा करेंगे।

कुबेरनेट कैसे लॉग देखता है

क्या आपने कभी सोचा है कि कैसे kubectl logs <pod_name> अर्क लॉग करता है? कंटेनरों से लॉग एकत्र करने के लिए कौन जिम्मेदार है? और वे आपके कंप्यूटर पर कैसे आते हैं?

निम्नलिखित चित्र प्रक्रिया को दिखाता है:



क्यूबलेट मेजबान पर /var/log निर्देशिका के अंदर एक संरचना बनाता है जो मेजबान पर पॉड्स का प्रतिनिधित्व करता है। हमारी 0.log लिए निर्देशिका में एक फ़ाइल 0.log (1) है, लेकिन वास्तव में यह कंटेनर लॉग में /var/lib/docker/containers । यह सब मेजबान के दृष्टिकोण से है।

क्यूबलेट एंडपॉइंट /logs/ (2) को खोलता है, जो केवल निर्देशिका (3) में HTTP फ़ाइल सर्वर के साथ काम करता है, जिससे एपीआई सर्वर से आने वाले अनुरोधों के लिए लॉग उपलब्ध होता है।

अब कल्पना करें कि हमने hostPath साथ पॉड को तैनात किया /var/log माउंट /var/log । इस तरह के पॉड की मेजबानी पर सभी लॉग फ़ाइलों तक पहुंच होगी। हालांकि यह अपने आप में एक संभावित समस्या है, हम अगला तार्किक कदम उठा सकते हैं। क्या होगा यदि हम 0.log को एक 0.log साथ बदलते हैं ... कहें, /etc/shadow ?

 │ ├── var │ ├── logs │ │ ├── pods │ │ │ ├── default_mypod_e7869b14-abca-11e8-9888-42010a8e020e │ │ │ │ ├── mypod │ │ │ │ │ ├── 0.log -> /etc/shadow │ │ │ │ │ │ 

अब, ग्राहक मशीन पर kubectl logs का उपयोग करके लॉग डाउनलोड करने की कोशिश कर रहा है, हमें यह मिलता है:

 $ kubectl logs mypod failed to get parse function: unsupported log format: "root:*:18033:0:99999:7:::\n" 

क्यूबलेट लिंक का अनुसरण करता है और उस फ़ाइल की सामग्री को पढ़ता है जिसे वह इंगित करता है (यह नोड पर कोई भी फ़ाइल हो सकती है)।

चूंकि JSON की उम्मीद थी, पहली पंक्ति के बाद kubectl दुर्घटनाग्रस्त हो गया, हालांकि, हम आसानी से –-tail=-<line_number> साथ कमांड चलाकर shadow फ़ाइल की विशिष्ट पंक्तियों को पढ़ सकते हैं।

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

फली से बच

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

मैंने इस हमले के वेक्टर का प्रदर्शन करते हुए अवधारणा (POC) का प्रमाण लिखा:

• आरोह बिंदु /var/log साथ फली की तैनाती;
• मेजबान की जड़ निर्देशिका का प्रतीकात्मक लिंक बनाना;
• होस्ट पर उपयोगकर्ता की ssh निजी कुंजी पढ़ना।

निम्नलिखित वीडियो में दो विशेष कमांड दिखाए गए हैं जो एक फली के अंदर चलते हैं:

• lsh == ls (होस्ट फ़ाइल सिस्टम पर);
• cath == cat (होस्ट फ़ाइल सिस्टम पर)।

लगभग। ट्रांस। : दुर्भाग्य से, उन्होंने हब पर एस्सिनेमा से सामग्री की प्रविष्टि को ठीक नहीं किया, हालांकि हमने पहले से ही इस समस्या को संबोधित किया है, इसलिए हम ऊपर दिए गए सरल लिंक के साथ वीडियो को "एम्बेड" करने के लिए मजबूर हैं।

इस POC में शामिल सभी फाइलें संबंधित GitHub रिपॉजिटरी में पाई जा सकती हैं। एक और POC स्क्रिप्ट है जो स्वचालित रूप से निजी कुंजी और ServiceAccount टोकन को होस्ट फ़ाइल सिस्टम से एकत्र करती है।

बढ़ते निर्देशिका खतरनाक हो सकते हैं

तो क्या यह भेद्यता है या सिर्फ बुरा व्यवहार है?

/var/log hostPath /var/log में hostPath साथ एक पॉड को तैनात करना दुर्लभ है (पॉड में मेजबान गुप्त निर्देशिकाओं के बढ़ते दुरुपयोग के अन्य तरीके भी हैं)। लेकिन यहां तक ​​कि अगर आपको पता था कि बढ़ते /var/log एक संदिग्ध अभ्यास था, तो आपको शायद यह उम्मीद नहीं थी कि आप इतनी आसानी से नोड पर कब्जा करने की अनुमति देंगे।

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

इस विधि का परीक्षण कुबेरनेट्स 1.15 और 1.13 पर किया गया है, लेकिन सबसे अधिक संभावना अन्य संस्करणों को प्रभावित करती है।

उन्मूलन

ऐसा "पलायन" तभी संभव है जब फली जड़ के रूप में चल रही हो। इससे आमतौर पर बचना चाहिए । एक्वा सीएसपी आपको न्यूनतम प्रयासों के साथ एक नीति निर्धारित करने की अनुमति देता है जो कंटेनरों को रूट के तहत चलने से रोकता है या केवल छवियों के एक विशिष्ट समूह को अनुमति देता है जिन्हें वास्तव में रूट की आवश्यकता होती है।

एक अन्य तरीका यह है कि hostPath साथ पॉड्स को केवल hostPath /var/log में न लिखें। यह दृष्टिकोण डिफ़ॉल्ट रूप से सेट नहीं किया गया है और एक सामान्य अभ्यास नहीं है, इसलिए इसे जानबूझकर निर्धारित करना आवश्यक है (हालांकि, संभावना अभी भी बनी हुई है)। लेकिन जांच कैसे करें?

हमने क्यूब-हंटर के लिए एक नई स्क्रिप्ट (शिकारी) - कुबेरनेट्स के परीक्षण के लिए हमारे हल्के ओपन सोर्स टूल को जोड़ा - जो ऐसे खतरनाक माउंट बिंदुओं के साथ फली के लिए क्लस्टर की जांच करता है। ( नोट : क्यूब-शिकारी K8s सुरक्षा उपयोगिताओं की हालिया समीक्षा में मौजूद था, जिसे हमने अपने ब्लॉग पर पोस्ट किया था।)

एक्वा उपयोगकर्ता कुछ जोखिमों को माउंट होने से रोकने के लिए रनटाइम पॉलिसी का उपयोग करके इस जोखिम से खुद की रक्षा कर सकते हैं:



लगभग। ट्रांस। : इस समस्या का एक हिस्सा पॉड सिक्योरिटी पॉलिसियों , अर्थात् AllowedHostPaths का उपयोग करके हल किया जा सकता है। हालाँकि, यह सिम्बलिंक से सुरक्षा भी नहीं है। अंत में, जैसा कि टिप्पणियां बताती हैं, हम लॉन्च को मूल रूप से सीमित कर सकते हैं, फिर से पीएसपी द्वारा निर्देशित।

परिणाम

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

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

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

• " सबसे लोकप्रिय डॉकर छवियों के 19% में, रूट के लिए कोई पासवर्ड नहीं है ";
• " 33+ कुबेरनेट सुरक्षा उपकरण ";
• " सुरक्षा पेशेवरों के लिए कुबेरनेट्स नेटवर्क नीतियों का परिचय ";
• " सुरक्षा-मांग वाले वातावरण में डोकर और कुबेरनेट्स ";
• " कुबेरनेट्स में 9 सर्वश्रेष्ठ सुरक्षा अभ्यास ";
• " 11 तरीके (नॉट) कुबेरनेट हैकिंग का शिकार बनें ।"