अवलोकन

CVE-2020-8558 एक Kubernetes भेद्यता है जिसे इसलिए प्रकाशित किया गया क्योंकि kube-proxy अप्रत्याशित रूप से localhost से बंधी होस्ट सेवाओं को नेटवर्क पर अन्य लोगों के लिए उपलब्ध कराता है। मैं "अप्रत्याशित रूप से" पर जोर इसलिए देता हूं क्योंकि यह भेद्यता एक डिज़ाइन दोष (उपेक्षा/चूक) के कारण है, न कि कार्यान्वयन दोष (बग) के कारण। कोड वही करता है जो वह कहता है, लेकिन हम सभी उस निर्णय के सुरक्षा निहितार्थों को पहचानने में विफल रहे।

होस्ट प्रक्रियाओं को 127.0.0.1 (localhost) पते के माध्यम से NodePort सेवाओं तक पहुंचने की अनुमति देने के लिए, kube-proxy net.ipv4.conf.all.route_localnet=1 sysctl सेटिंग सेट करता है। कर्नेल दस्तावेज़ीकरण के अनुसार, यह सेटिंग कर्नेल को "लूपबैक पतों को martian नहीं मानने" के लिए बनाती है — जिसका एक परिणाम यह है कि उन्हें नेटवर्क पर अन्य नोड्स द्वारा एक्सेस किया जा सकता है। यह एक बड़ी बात है यदि आपके पास संवेदनशील बिना-प्रमाणीकरण वाली सेवाएं हैं जिनकी एकमात्र सुरक्षा localhost से बंधा होना है!

इस लेखन के समय, Kubernetes समुदाय अभी भी CVE-2020-8558 को संबोधित करने का सबसे अच्छा तरीका खोज रहा है। दो स्पष्ट विकल्प हैं: पहले स्थान पर route_localnet sysctl सेट करना बंद करना, या iptables का उपयोग करके अनुचित रूप से रूट किए गए localnet पैकेटों को ब्लॉक करना। बाद की रणनीति का उपयोग करने वाला एक फिक्स पहले ही kubelet >= 1.18.4, 1.17.7, या 1.16.11 में जारी किया जा चुका है। आप इस CVE के लिए Kubernetes issue का संदर्भ लेकर इसे स्वयं भी लागू कर सकते हैं, जो नीचे लिंक किया गया है।

इतिहास और पृष्ठभूमि

net.ipv4.conf.all.route_localnet=1 सेट करना एक CVE ID के योग्य क्यों है? मुख्य रूप से क्योंकि यह IP नेटवर्क के बारे में हमारे अंतर्ज्ञान का उल्लंघन करता है।

कम से कम 1989 के RFC 1122 के बाद से, localhost नेटवर्क 127.0.0.1/8 के पैकेटों के साथ विशेष व्यवहार किया जाता रहा है, और उन्हें "किसी होस्ट के बाहर दिखाई देने" से प्रतिबंधित किया गया है। (यदि आप 127/8 के विशेष गुणों के किसी पहले संदर्भ के बारे में जानते हैं तो कृपया मुझसे Twitter पर संपर्क करें।) किसी भी RFC-अनुरूप होस्ट में अनिवार्य रूप से एक अंतर्निहित, गैर-हटाने योग्य फ़ायरवॉल नियम होता है जो 127.0.0.1 (और उस नेटवर्क के अन्य IP — यदि आपने पहले कभी नहीं किया है तो 127.127.127.127 को ping करके देखें!) से बंधी सेवाओं तक बाहरी पहुंच को ब्लॉक करता है। हम उस व्यवहार पर निर्भर हो गए हैं और उसकी अपेक्षा करते हैं। हम अक्सर बिना प्रमाणीकरण या एन्क्रिप्शन के संवेदनशील सेवाएं चलाते हैं, और सुरक्षा के लिए उन्हें localhost से बांधते हैं। उदाहरण के लिए, plaintext HTTP बैकएंड, redis key-value स्टोर, और अवशिष्ट Kubernetes api-server insecure पोर्ट — ये सभी आमतौर पर इसी तरह घुसपैठ से सुरक्षित रहते हैं। हम इस व्यवहार के इतने आदी हैं कि यह हमारी सहज समझ का एक अंतर्निहित हिस्सा है कि IP होस्ट होने का क्या अर्थ है। इस दृष्टिकोण से देखें, तो यह समझ में आता है कि कई विशेषज्ञ इतने लंबे समय तक इस दोष को अनदेखा कर सकते थे।

यह कैसे काम करता है?

आइए किसी भी इकाई को IP पते वाली "नोड" कहें। IP पैकेट एक नोड से दूसरे नोड को भेजे जाते हैं, जिन्हें पैकेट हेडर में स्रोत और गंतव्य IP पते द्वारा पहचाना जाता है। प्रत्येक IP नोड या तो एक राउटर (RFC1122 में गेटवे कहा जाता है) या एक होस्ट होता है। प्राथमिक अंतर यह है कि जब कोई होस्ट किसी और के पते के लिए नियत पैकेट प्राप्त करता है, तो वह उन्हें अनदेखा कर देता है। एक राउटर अपनी रूटिंग टेबल देखता है और पैकेटों को उनके अंतिम गंतव्य के करीब लाने के प्रयास में उन्हें पुनः प्रसारित (फॉरवर्ड) करता है। एक होस्ट कुछ स्थानीय रूप से जुड़े नोड्स के बारे में जानता होगा; अन्य नोड्स तक पहुंचने के लिए, उसे अपने पैकेट किसी स्थानीय रूप से जुड़े राउटर को भेजने होंगे। वे स्थानीय कनेक्शन point-to-point (जैसे PPP लिंक या कुछ वर्चुअल नेटवर्क) या shared-medium (जैसे Ethernet) हो सकते हैं।

आपके मेलबॉक्स की कल्पना आपके घर और स्थानीय डाकघर के बीच एक point-to-point लिंक के रूप में की जा सकती है। किसी point-to-point लिंक पर पैकेट को रूट करने के लिए, होस्ट को केवल सही गंतव्य पता लगाना और पैकेट को प्रसारित करना होता है। (यह OSI मॉडल की लेयर 3 पर होता है।) किसी shared-medium लिंक पर पैकेट को रूट करने के लिए, होस्ट को पहले साझा माध्यम पर एक वर्चुअल point-to-point सर्किट बनाना होता है। Ethernet/IP नेटवर्क में, यह OSI मॉडल की लेयर 2 पर ARP द्वारा किया जाता है। अनिवार्य रूप से, यदि आप एक ARP पैकेट प्रसारित कर सकते हैं, तो आप दूसरे होस्ट से कह सकते हैं "अरे, मैं यहाँ हूँ" और वह आप पर विश्वास करेगा। (जब यह अनुचित तरीके से किया जाता है तो इसे ARP कैश पॉइज़निंग कहा जाता है।) फिर आप अपने पैकेटों पर उपयुक्त Ethernet स्रोत और गंतव्य पते लगाकर संवाद कर सकते हैं।

एक सामान्य नोड कभी भी 127.0.0.1 के गंतव्य पते वाला पैकेट प्रसारित नहीं करेगा, क्योंकि RFC 1122 के कारण। यदि किसी सामान्य नोड को 127.0.0.1 के गंतव्य पते वाला पैकेट प्राप्त होता है, तो वह उसे अनदेखा (ड्रॉप) कर देगा, फिर से RFC 1122 के कारण। net.ipv4.conf.all.route_localnet=1 सेट करना उसे बदल देता है — यह 127.0.0.1 पैकेटों को भेजने और प्राप्त करने की अनुमति देता है जैसे कि वे विशेष न हों।

इसलिए, यदि किसी हमलावर के पास net.ipv4.conf.all.route_localnet=1 वाले लक्ष्य नोड से स्थानीय कनेक्शन है, तो हमलावर उसे 127.0.0.1 गंतव्य पते वाला पैकेट भेज सकता है, और वह लक्ष्य नोड उसी के अनुसार प्रतिक्रिया देगा जैसे कि 127.0.0.1 पूरी तरह से सामान्य पता हो। आज किसी लक्ष्य नोड से स्थानीय कनेक्शन रखने के दो सबसे सामान्य तरीके हैं: लक्ष्य के समान Ethernet नेटवर्क (ब्रॉडकास्ट डोमेन) पर होना, या लक्ष्य पर चल रहा कंटेनर होना।

ध्यान दें कि सामान्य रूप से कॉन्फ़िगर होने पर, Linux हमलावर नोड को 127.0.0.1 के लिए नियत सामान्य पैकेट प्रसारित करने की अनुमति नहीं देगा। इसे हमलावर के Linux नोड को पुनः कॉन्फ़िगर करके (यदि उनके पास रूट एक्सेस है), या raw सॉकेट का उपयोग करके पैकेट जालसाज़ी करके दूर किया जा सकता है। Raw सॉकेटों के लिए केवल Linux कर्नेल क्षमता CAP_NET_RAW की आवश्यकता होती है, जो डिफ़ॉल्ट रूप से गैर-विशेषाधिकार प्राप्त (unprivileged) कंटेनरों को दी जाती है। इसका मतलब है कि एक हमलावर-नियंत्रित गैर-विशेषाधिकार प्राप्त कंटेनर CVE-2020-8558 का शोषण करने में सक्षम है।

मूल्यांकन

संक्षेप में, यदि आप kube-proxy का उपयोग कर रहे हैं या net.ipv4.conf.*.route_localnet के साथ कुछ चतुर काम कर रहे हैं, तो आप उजागर हैं। आपको यह निर्धारित करने के लिए कुछ समय थ्रेट मॉडलिंग में बिताना चाहिए कि वह जोखिम आपके लिए कितना जोखिम भरा है, और एक उपयुक्त शमन रणनीति की योजना बनानी चाहिए।

मूल रूप से, net.ipv4.conf.all.route_localnet=1 सेट वाला प्रत्येक Linux होस्ट भेद्य है। वह भेद्यता किसी हमलावर के लिए दिलचस्प है या नहीं, यह कई कारकों पर निर्भर करता है:

1. क्या होस्ट हमलावर के लिए सुलभ है?
2. क्या पैकेट फ़िल्टर किए गए हैं?
3. क्या localhost से बंधी कोई दिलचस्प सेवाएं हैं?

CVE-2020-8558 का मूल्यांकन करने के लिए, आपको विभिन्न क्षमताओं वाले हमलावरों की कल्पना करनी होगी, और इन सवालों का उत्तर उन हमलावरों के दृष्टिकोण से देना होगा। (एडम शॉस्टैक की पुस्तक "Threat Modeling: Designing for Security" इस प्रक्रिया का विस्तार से वर्णन करती है।) दो प्रासंगिक हमलावर जिन पर आपको निश्चित रूप से विचार करना चाहिए: एक हमलावर जिसका नोड आपके Ethernet नेटवर्क पर है, और एक हमलावर जो आपके होस्ट पर गैर-विशेषाधिकार प्राप्त पॉड में कोड चला सकता है। आपके वातावरण और आवश्यकताओं के आधार पर, अन्य दिलचस्प हमलावर भी हो सकते हैं जिन पर आपको विचार करना चाहिए।

उदाहरण के लिए, यहाँ एक आंशिक रूप से हल किया गया उदाहरण है:

होस्ट निश्चित रूप से दोनों हमलावरों के लिए सुलभ है; हमने प्रत्येक मामले में यह मान लिया है।

पैकेट फ़िल्टर किए जा सकते हैं या नहीं भी। आपको जांच करनी होगी। कई क्लाउड वातावरणों और सख्ती से प्रबंधित on-prem नेटवर्कों में, पैकेट तब ब्लॉक किए जाते हैं जब IP गंतव्य नेटवर्क द्वारा अपेक्षित Ethernet गंतव्य से मेल नहीं खाता। यह अकेले ही नोड-वाले हमलावर के लिए game-over हो सकता है। यदि आपके सभी नोड्स में उपयुक्त स्थानीय फ़ायरवॉल नियम हैं (जैसे कि अपडेटेड kubelet द्वारा प्रदान किए गए), तो यह दोनों हमलावरों को विफल कर देगा।