Bad Pods

Une collection de manifests qui créent des pods avec différents privilèges élevés. Démontrez rapidement l'impact de l'autorisation d'attributs de pods sensibles pour la sécurité comme hostNetwork, hostPID, hostPath, hostIPC et privileged.

Pour plus de contexte, consultez notre article de blog : Bad Pods: Kubernetes Pod Privilege Escalation.

Sommaire

• La sélection des Bad Pods
• Prérequis
• Organisation
• Utilisation
  • Approche générale
  • Exemples d'utilisation
    • Créer les huit Bad Pods à partir du dépôt local cloné
    • Créer les huit Bad Pods depuis GitHub
    • Créer les huit Bad Pods reverse shell
    • Créer les huit types de ressources avec le pod everything-allowed
    • Créer un cronjob avec le pod hostNetwork
    • Créer un deployment avec le pod priv-and-hostpid
    • Créer un reverse shell avec le pod privileged
• Remerciements
• Références et lectures complémentaires

La sélection des Bad Pods

Chaque lien ci-dessous fournit des informations d'utilisation détaillées et des recommandations de post-exploitation.

• Bad Pod n°1 : Tout est autorisé
• Bad Pod n°2 : Privileged et hostPid
• Bad Pod n°3 : Privileged uniquement
• Bad Pod n°4 : hostPath uniquement
• Bad Pod n°5 : hostPid uniquement
• Bad Pod n°6 : hostNetwork uniquement
• Bad Pod n°7 : hostIPC uniquement
• Bad Pod n°8 : Rien n'est autorisé

Pour plus d'informations générales sur les prérequis, l'organisation du dépôt et les schémas d'utilisation courants, voir les sections ci-dessous.

Prérequis

1. Accès à un cluster
2. Permission RBAC pour créer l'un des types de ressources suivants dans au moins un namespace :
   • CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet
3. Permission RBAC pour exécuter une commande (exec) dans des pods, ou une politique réseau qui permet à un reverse shell depuis un pod de vous atteindre.
4. Aucune pod security policy appliquée, ou une politique permettant de créer des pods avec un ou plusieurs attributs sensibles pour la sécurité.

Organisation

• 128 manifests autonomes et prêts à l'emploi. Pourquoi autant ?
  • 8 Bad Pods (hostpid, hostnetwork, everything-allowed, etc.)
  • 8 types de ressources capables de créer des pods (pod, deployment, replicaset, statefulset, etc.)
  • 2 façons d'accéder aux pods créés (exec et 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...

Huit façons de créer un pod

Comme le souligne Eviatar Gerzi (@g3rzi) dans l'article Eight Ways to Create a Pod, il existe 8 contrôleurs différents capables de créer un pod, ou un ensemble de pods. Vous n'êtes peut-être pas autorisé à créer des pods, mais vous pouvez peut-être créer un autre type de ressource qui en créera un ou plusieurs. Pour chaque type de badPod, des manifests correspondant aux huit types de ressources sont fournis.

Mais attendez, ça se corse ! En plus des huit contrôleurs Kubernetes actuels capables de créer des pods, il existe des contrôleurs de tiers qui peuvent également créer des pods s'ils sont appliqués au cluster. Gardez un œil sur eux en consultant kubectl api-resources.

Reverse shells

Bien que fréquente, il n'est pas toujours possible d'exécuter des commandes (exec) dans les pods que vous pouvez créer. Pour aider dans ces situations, une version de chaque manifest est incluse, utilisant l'image ncat dockerhub de Rory McCune (@raesene). Une fois créé, le pod établira un rappel chiffré vers votre listener.

Utilisation

Chaque ressource du répertoire manifests cible un attribut spécifique ou une combinaison d'attributs qui exposent le cluster à un risque lorsqu'ils sont autorisés.

Approche générale

Option 1 : Approche méthodique

1. Évaluer le RBAC - Déterminer quels types de ressources vous pouvez créer
2. Évaluer la politique d'admission - Déterminer lesquels des Bad Pods vous pourrez créer
3. Créer les ressources - En fonction de ce qui est autorisé, utiliser le type de badPod et le type de ressource spécifiques et créer vos ressources
4. Post-exploitation - Évaluer les étapes de post-exploitation décrites dans le README pour ce type
   • Tout est autorisé
   • Privileged et hostPid
   • Privileged uniquement
   • hostPath uniquement
   • hostPid uniquement
   • hostNetwork uniquement
   • hostIPC uniquement
   • Rien n'est autorisé