Bad Pods

Набор манифестов, создающих поды с различными повышенными привилегиями. Позволяет быстро продемонстрировать влияние разрешения таких чувствительных с точки зрения безопасности атрибутов подов, как hostNetwork, hostPID, hostPath, hostIPC и privileged.

Дополнительную информацию см. в нашем блоге: Bad Pods: Kubernetes Pod Privilege Escalation.

Содержание

• Состав Bad Pods
• Предварительные требования
• Структура
• Использование
  • Общий подход
  • Примеры использования
    • Создание всех восьми Bad Pods из локального клона репозитория
    • Создание всех восьми Bad Pods из GitHub
    • Создание всех восьми Bad Pods с reverse shell
    • Создание всех восьми типов ресурсов с помощью пода everything-allowed
    • Создание cronjob с подом hostNetwork
    • Создание deployment с подом priv-and-hostpid
    • Создание reverse shell с помощью привилегированного пода

Состав Bad Pods

Каждая ссылка ниже содержит подробную информацию об использовании и рекомендации по пост-эксплуатации.

• Bad Pod #1: Everything allowed
• Bad Pod #2: Privileged and hostPid
• Bad Pod #3: Privileged only
• Bad Pod #4: hostPath only
• Bad Pod #5: hostPid only
• Bad Pod #6: hostNetwork only
• Bad Pod #7: hostIPC only
• Bad Pod #8: Nothing allowed

Более общую информацию о предварительных требованиях, структуре репозитория и типовых сценариях использования см. в разделах ниже.

Предварительные требования

1. Доступ к кластеру
2. Разрешение RBAC на создание одного из следующих типов ресурсов как минимум в одном namespace:
   • CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet
3. Разрешение RBAC на выполнение exec в поды или сетевая политика, позволяющая reverse shell из пода соединиться с вами.
4. Отсутствие принудительного применения pod security policy или политика, разрешающая создание подов с одним или несколькими чувствительными с точки зрения безопасности атрибутами

Структура

• 128 самодостаточных, готовых к использованию манифестов. Почему так много?
  • 8 Bad Pods (hostpid, hostnetwork, everything-allowed и т.д.)
  • 8 типов ресурсов, которые могут создавать поды (pod, deployment, replicaset, statefulset и т.д.)
  • 2 способа доступа к созданным подам (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...

Существует восемь способов создать под

Как отмечает Eviatar Gerzi (@g3rzi) в статье Восемь способов создать под, существует 8 различных контроллеров, которые могут создать под или набор подов. Возможно, у вас нет прав на создание подов, но, вероятно, вы можете создать другой тип ресурса, который создаст один или несколько подов. Для каждого типа badPod существуют манифесты, соответствующие всем восьми типам ресурсов.

Но подождите, это ещё не всё! Помимо восьми текущих контроллеров Kubernetes, которые могут создавать поды, существуют сторонние контроллеры, которые также могут создавать поды, если они применены к кластеру. Следить за ними можно с помощью команды kubectl api-resources.

Reverse shells

Хотя это распространённая практика, не всегда можно выполнить exec в поды, которые вы создаёте. Чтобы помочь в таких ситуациях, включена версия каждого манифеста, использующая образ ncat из dockerhub от Rory McCune (@raesene). При создании под выполнит зашифрованный обратный вызов вашему слушателю.

Использование

Каждый ресурс в каталоге manifests нацелен на определённый атрибут или комбинацию атрибутов, которые при разрешении подвергают кластер риску.

Общий подход

Вариант 1: Методичный подход

1. Оцените RBAC — определите, какие типы ресурсов вы можете создавать
2. Оцените Admission Policy — определите, какие из Bad Pods вы сможете создать
3. Создайте ресурсы — исходя из разрешённого, используйте конкретный тип badPod и тип ресурса и создайте свои ресурсы
4. Пост-эксплуатация — оцените шаги пост-эксплуатации, описанные в README для данного типа
   • Everything allowed
   • Privileged and hostPid
   • Privileged only
   • hostPath only
   • hostPid only
   • hostNetwork only
   • hostIPC only
   • Nothing allowed