Bad Pods

Eine Sammlung von Manifests, die Pods mit unterschiedlichen erhöhten Privilegien erstellen. Demonstriert schnell die Auswirkungen, wenn sicherheitsrelevante Pod-Attribute wie hostNetwork, hostPID, hostPath, hostIPC und privileged erlaubt sind.

Weitere Hintergrundinformationen findest du in unserem Blogbeitrag: Bad Pods: Kubernetes Pod Privilege Escalation.

Inhaltsverzeichnis

• Die Bad-Pods-Übersicht
• Voraussetzungen
• Organisation
• Verwendung
  • Übergeordnetes Vorgehen
  • Verwendungsbeispiele
    • Alle acht Bad Pods aus dem geklonten lokalen Repository erstellen
    • Alle acht Bad Pods von GitHub erstellen
    • Alle acht Reverse-Shell-badPods erstellen
    • Alle acht Ressourcentypen mit dem everything-allowed-Pod erstellen
    • Einen CronJob mit dem hostNetwork-Pod erstellen
    • Ein Deployment mit dem priv-and-hostpid-Pod erstellen
    • Eine Reverse Shell mit dem privilegierten Pod erstellen
• Danksagungen
• Referenzen und weiterführende Literatur

Die Bad-Pods-Übersicht

Jeder Link unten enthält detaillierte Nutzungsinformationen und Empfehlungen für die Post-Exploitation.

• Bad Pod #1: Alles erlaubt
• Bad Pod #2: Privilegiert und hostPid
• Bad Pod #3: Nur privilegiert
• Bad Pod #4: Nur hostPath
• Bad Pod #5: Nur hostPid
• Bad Pod #6: Nur hostNetwork
• Bad Pod #7: Nur hostIPC
• Bad Pod #8: Nichts erlaubt

Weitere allgemeine Informationen zu Voraussetzungen, Repository-Struktur und gängigen Nutzungsmustern findest du in den folgenden Abschnitten.

Voraussetzungen

1. Zugriff auf einen Cluster
2. RBAC-Berechtigung, um mindestens einen der folgenden Ressourcentypen in mindestens einem Namespace zu erstellen:
   • CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet
3. RBAC-Berechtigung, um in Pods exec-en zu können, oder eine Netzwerkrichtlinie, die eine Reverse-Shell von einem Pod zu dir erlaubt.
4. Keine Durchsetzung einer Pod Security Policy oder eine Richtlinie, die das Erstellen von Pods mit einem oder mehreren sicherheitsrelevanten Attributen erlaubt

Organisation

• 128 eigenständige, gebrauchsfertige Manifests. Warum so viele?
  • 8 Bad Pods (hostpid, hostnetwork, everything-allowed, usw.)
  • 8 Ressourcentypen, die Pods erstellen können (pod, deployment, replicaset, statefulset, usw.)
  • 2 Möglichkeiten, auf die erstellten Pods zuzugreifen (exec & 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...

Es gibt acht Möglichkeiten, einen Pod zu erstellen

Wie Eviatar Gerzi (@g3rzi) in dem Beitrag Eight Ways to Create a Pod betont, gibt es 8 verschiedene Controller, die einen Pod oder eine Gruppe von Pods erstellen können. Du bist vielleicht nicht berechtigt, Pods zu erstellen, aber vielleicht kannst du einen anderen Ressourcentyp erstellen, der einen oder mehrere Pods erstellt. Für jeden badPod-Typ gibt es Manifests, die allen acht Ressourcentypen entsprechen.

Aber warte, es wird noch schlimmer! Zusätzlich zu den acht aktuellen Kubernetes-Controllern, die Pods erstellen können, gibt es Drittanbieter-Controller, die ebenfalls Pods erstellen können, wenn sie auf den Cluster angewendet werden. Halte Ausschau nach ihnen, indem du dir kubectl api-resources ansiehst.

Reverse-Shells

Obwohl es üblich ist, ist es nicht immer der Fall, dass du in Pods exec-en kannst, die du erstellen kannst. Um in solchen Situationen zu helfen, ist eine Version jedes Manifests enthalten, die Rory McCunes (@raesene) ncat-Docker-Hub-Image verwendet. Nach der Erstellung nimmt der Pod eine verschlüsselte Verbindung zu deinem Listener auf.

Verwendung

Jede Ressource im Verzeichnis manifests zielt auf ein bestimmtes Attribut oder eine Kombination von Attributen ab, die den Cluster einem Risiko aussetzen, wenn sie erlaubt sind.

Übergeordnetes Vorgehen

Option 1: Methodischer Ansatz

1. RBAC bewerten - Ermittle, welche Ressourcentypen du erstellen kannst
2. Admission Policy bewerten - Ermittle, welche der Bad Pods du erstellen kannst
3. Ressourcen erstellen - Erstelle auf Basis dessen, was erlaubt ist, deine Ressourcen mit dem jeweiligen badPod-Typ und Ressourcentyp
4. Post-Exploitation - Bewerte die im README für diesen Typ beschriebenen Post-Exploitation-Schritte
   • Alles erlaubt
   • Privilegiert und hostPid
   • Nur privilegiert
   • Nur hostPath
   • Nur hostPid
   • Nur hostNetwork
   • Nur hostIPC
   • Nichts erlaubt