Bad Pods

Una colección de manifiestos que crean pods con diferentes privilegios elevados. Demuestra rápidamente el impacto de permitir atributos de pod sensibles a la seguridad como hostNetwork, hostPID, hostPath, hostIPC y privileged.

Para obtener más información, consulte nuestra publicación de blog: Bad Pods: Escalada de privilegios en pods de Kubernetes.

Contenido

• La alineación de Bad Pods
• Requisitos previos
• Organización
• Uso
  • Enfoque de alto nivel
  • Ejemplos de uso
    • Crear los ocho Bad Pods desde el repositorio local clonado
    • Crear los ocho Bad Pods desde Github
    • Crear los ocho Bad Pods de reverse shell
    • Crear los ocho tipos de recursos usando el pod everything-allowed
    • Crear un cronjob con el pod hostNetwork
    • Crear un deployment con el pod priv-and-hostpid
    • Crear una reverse shell usando el pod privilegiado

La alineación de los Bad Pods

Cada enlace a continuación proporciona información detallada de uso y recomendaciones de post-explotación.

• Bad Pod #1: Todo permitido
• Bad Pod #2: Privilegiado y hostPid
• Bad Pod #3: Solo privilegiado
• Bad Pod #4: Solo hostPath
• Bad Pod #5: Solo hostPid
• Bad Pod #6: Solo hostNetwork
• Bad Pod #7: Solo hostIPC
• Bad Pod #8: Nada permitido

Para obtener información más general sobre los requisitos previos, la organización del repositorio y los patrones de uso comunes, consulte las secciones siguientes.

Requisitos previos

1. Acceso a un clúster
2. Permiso RBAC para crear uno de los siguientes tipos de recursos en al menos un namespace:
   • CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet
3. Permiso RBAC para ejecutar (exec) dentro de pods o una política de red que permita que una reverse shell desde un pod llegue hasta usted.
4. Que no haya una política de seguridad de pods (pod security policy) aplicada, o que exista una política que permita crear pods con uno o más atributos sensibles a la seguridad.

Organización

• 128 manifiestos autónomos y listos para usar. ¿Por qué tantos?
  • 8 Bad Pods (hostpid, hostnetwork, everything-allowed, etc.)
  • 8 tipos de recursos que pueden crear pods (pod, deployment, replicaset, statefulset, etc.)
  • 2 formas de acceder a los pods creados (exec y reverse shell)

├── manifests
│   ├── everything-allowed
│   │   ├── cronjob
│   │   │   ├── everything-allowed-exec-cronjob.yaml
│   │   │   └── everything-allowed-revshell-cronjob.yaml
│   │   ├── daemonset
│   │   │   ├── everything-allowed-exec-daemonset.yaml
│   │   │   └── everything-allowed-revshell-daemonset.yaml
│   │   ├── deployment
│   │   │   ├── everything-allowed-exec-deployment.yaml
│   │   │   └── everything-allowed-revshell-deployment.yaml
│   │   ├── job
│   │   │   ├── everything-allowed-exec-job.yaml
│   │   │   └── everything-allowed-revshell-job.yaml
│   │   ├── pod
│   │   │   ├── everything-allowed-exec-pod.yaml
│   │   │   └── everything-allowed-revshell-pod.yaml
│   │   ├── replicaset
│   │   │   ├── everything-allowed-exec-replicaset.yaml
│   │   │   └── everything-allowed-revshell-replicaset.yaml
│   │   ├── replicationcontroller
│   │   │   ├── everything-allowed-exec-replicationcontroller.yaml
│   │   │   └── everything-allowed-revshell-replicationcontroller.yaml
│   │   └── statefulset
│   │       ├── everything-allowed-exec-statefulset.yaml
│   │       └── everything-allowed-revshell-statefulset.yaml
│   ├── hostipc
│   │   ├── cronjob
│   │   │   ├── hostipc-exec-cronjob.yaml
│   │   │   └── hostipc-revshell-cronjob.yaml
│   │   ├── daemonset
│   │   │   ├── hostipc-exec-daemonset.yaml
│   │   │   └── hostipc-revshell-daemonset.yaml
...omitted for brevity...

Hay ocho formas de crear un pod

Como señala Eviatar Gerzi (@g3rzi) en el artículo Eight Ways to Create a Pod, hay 8 controladores diferentes que pueden crear un pod o un conjunto de pods. Puede que no esté autorizado para crear pods, pero quizá pueda crear otro tipo de recurso que cree uno o más pods. Para cada tipo de badPod, existen manifiestos que corresponden a los ocho tipos de recursos.

Pero espera, ¡aún hay más! Además de los ocho controladores actuales de Kubernetes que pueden crear pods, hay controladores de terceros que también pueden crear pods si se aplican al clúster. Esté atento a ellos revisando kubectl api-resources.

Shells inversas

Aunque es común, no siempre se puede ejecutar (exec) dentro de los pods que se crean. Para ayudar en esas situaciones, se incluye una versión de cada manifiesto que utiliza la imagen ncat de dockerhub de Rory McCune (@raesene). Al crearse, el pod realizará una llamada cifrada de vuelta a su listener.

Uso

Cada recurso en el directorio manifests apunta a un atributo específico o a una combinación de atributos que exponen al clúster a riesgo cuando se permiten.

Enfoque de alto nivel

Opción 1: Enfoque metódico

1. Evalúe el RBAC - Determine qué tipos de recursos puede crear
2. Evalúe la política de admisión - Determine cuáles de los Bad Pods podrá crear
3. Cree los recursos - Según lo que esté permitido, use el tipo de badPod y el tipo de recurso específicos y cree sus recursos
4. Post-explotación - Evalúe los pasos de post-explotación descritos en el README para ese tipo
   • Todo permitido
   • Privilegiado y hostPid
   • Solo privilegiado
   • Solo hostPath
   • Solo hostPid
   • Solo hostNetwork
   • Solo hostIPC
   • Nada permitido