Bad Pods

Uma coleção de manifestos que criam pods com diferentes privilégios elevados. Demonstre rapidamente o impacto de permitir atributos de pods sensíveis à segurança, como hostNetwork, hostPID, hostPath, hostIPC e privileged.

Para obter mais contexto, veja nosso post no blog: Bad Pods: Kubernetes Pod Privilege Escalation.

Conteúdo

• A formação dos Bad Pods
• Pré-requisitos
• Organização
• Uso
  • Abordagem de alto nível
  • Exemplos de uso
    • Criar todos os oito Bad Pods a partir do repositório local clonado
    • Criar todos os oito Bad Pods a partir do Github
    • Criar todos os oito Bad Pods com reverse shell
    • Criar todos os oito tipos de recursos usando o pod everything-allowed
    • Criar um cronjob com o pod hostNetwork
    • Criar um deployment com o pod priv-and-hostpid
    • Criar um reverse shell usando o pod privilegiado
• Agradecimentos
• Referências e leituras complementares

A formação dos Bad Pods

Cada link abaixo fornece informações detalhadas de uso e recomendações de pós-exploração.

• Bad Pod #1: Tudo permitido
• Bad Pod #2: Privilegiado e hostPid
• Bad Pod #3: Somente privilegiado
• Bad Pod #4: Somente hostPath
• Bad Pod #5: Somente hostPid
• Bad Pod #6: Somente hostNetwork
• Bad Pod #7: Somente hostIPC
• Bad Pod #8: Nada permitido

Para informações mais gerais sobre pré-requisitos, organização do repositório e padrões comuns de uso, veja as seções abaixo.

Pré-requisitos

1. Acesso a um cluster
2. Permissão RBAC para criar um dos seguintes tipos de recurso em pelo menos um namespace:
   • CronJob, DeamonSet, Deployment, Job, Pod, ReplicaSet, ReplicationController, StatefulSet
3. Permissão RBAC para fazer exec em pods ou uma política de rede que permita um reverse shell a partir de um pod até você.
4. Nenhuma política de segurança de pod em vigor, ou uma política que permita criar pods com um ou mais atributos sensíveis à segurança

Organização

• 128 manifestos autocontidos e prontos para uso. Por que tantos?
  • 8 Bad Pods (hostpid, hostnetwork, everything-allowed, etc.)
  • 8 tipos de recursos que podem criar pods (pod, deployment, replicaset, statefulset, etc.)
  • 2 formas de acessar os pods criados (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...

Existem oito maneiras de criar um pod

Como Eviatar Gerzi (@g3rzi) aponta no post Eight Ways to Create a Pod, existem 8 controladores diferentes que podem criar um pod, ou um conjunto de pods. Você pode não estar autorizado a criar pods, mas talvez possa criar outro tipo de recurso que criará um ou mais pods. Para cada tipo de badPod, existem manifestos que correspondem a todos os oito tipos de recursos.

Mas espere, fica pior! Além dos oito controladores Kubernetes atuais que podem criar pods, existem controladores de terceiros que também podem criar pods se forem aplicados ao cluster. Fique de olho neles consultando kubectl api-resources.

Reverse shells

Embora seja comum, nem sempre é possível fazer exec nos pods que você pode criar. Para ajudar nessas situações, uma versão de cada manifesto é incluída usando a imagem ncat do dockerhub de Rory McCune's (@raesene). Quando criado, o pod fará uma chamada criptografada de volta para o seu listener.

Uso

Cada recurso no diretório manifests tem como alvo um atributo específico ou uma combinação de atributos que expõem o cluster a risco quando permitidos.

Abordagem de alto nível

Opção 1: Abordagem metódica

1. Avalie o RBAC - Determine quais tipos de recurso você pode criar
2. Avalie a política de admissão - Determine quais dos Bad Pods você conseguirá criar
3. Crie os recursos - Com base no que é permitido, use o tipo de badPod e o tipo de recurso específicos e crie seus recursos
4. Pós-exploração - Avalie as etapas de pós-exploração descritas no README para aquele tipo
   • Tudo permitido
   • Privilegiado e hostPid
   • Somente privilegiado
   • Somente hostPath
   • Somente hostPid
   • Somente hostNetwork
   • Somente hostIPC
   • Nada permitido