(Bad Pods) – Pods ruins: escalonamento de privilégios de pod do Kubernetes

 

Quais são os riscos associados à criação de pod excessivamente permissiva no Kubernetes? A resposta varia com base em quais namespaces do host e contextos de segurança são permitidos. Nesta postagem, descreverei oito configurações de pod inseguras e os métodos correspondentes para realizar o escalonamento de privilégios. Este artigo e o repositório que o acompanha foram criados para ajudar os testadores de invasão e administradores a entender melhor os cenários comuns de configuração incorreta.

Se você é um administrador, espero que esta postagem lhe dê confiança para aplicar controles restritivos em torno da criação de pod por padrão. Eu também espero que isso ajude você a considerar o isolamento de quaisquer pods que precisam de acesso aos recursos do host para um namespace que só pode ser acessado por administradores usando o princípio do menor privilégio.

Se você é um testador de invasão, espero que esta postagem forneça algumas ideias sobre como demonstrar o impacto de uma política de segurança de pod excessivamente permissiva. E espero que o repositório forneça alguns manifestos fáceis de usar e etapas acionáveis ​​para atingir esses objetivos.

Sumário executivo:

Um dos fundamentos da segurança da informação é o “princípio do menor privilégio”. Isso significa que cada usuário, processo do sistema ou aplicativo precisa operar usando o conjunto mínimo de privilégios necessários para realizar uma tarefa. Quando os privilégios são configurados onde excedem em muito o que é necessário, os invasores podem aproveitar essas situações para acessar dados confidenciais, comprometer sistemas ou escalar esses privilégios para conduzir o movimento lateral em uma rede.
O Kubernetes e outras novas tecnologias “DevOps” são complexas para implementar de maneira adequada e geralmente são implantadas incorretamente ou configuradas com mais permissões do que o necessário. A lição, como demonstramos em nossa pesquisa de “pods ruins”, é que, se você estiver usando o Kubernetes em sua infraestrutura, precisará descobrir com sua equipe de desenvolvimento como eles estão configurando e fortalecendo esse ambiente.

HARDENING PODS: QUANTO ARRISCADO PODE SER UM ÚNICO ATRIBUTO?

Quando se trata de práticas recomendadas de segurança do Kubernetes, cada lista de verificação que vale a pena menciona que você deseja usar o princípio do menor privilégio ao provisionar pods. Mas como podemos aplicar controles de segurança granulares e como avaliamos o risco de cada atributo?

Um administrador do Kubernetes pode aplicar o princípio do menor privilégio usando controladores de admissão. Por exemplo, há um controlador Kubernetes integrado chamado PodSecurityPolicy e também um controlador de admissão de terceiros conhecido chamado OPA Gatekeeper . Os controladores de admissão permitem que você negue a entrada de um pod no cluster se ele tiver mais permissões do que a política permite.

No entanto, embora os controles existam para definir e aplicar a política, as implicações de segurança do mundo real de permitir cada atributo específico nem sempre são compreendidas e, com frequência, a criação de pods não é tão bloqueada quanto deveria ser.

Como um testador de penetração, você pode ter acesso para criar pods em um cluster onde não há aplicação de política. É o que gosto de chamar de “modo fácil”. Use este manifesto de Rory McCune ( @raesene ), este comando de Duffie Cooley ( @mauilion ) ou o plugin node-shell krew e você terá a execução de código privilegiado totalmente interativo no host subjacente. Não existe nada mais fácil do que isso!

Mas e se você pode criar um pod com apenas, hostNetworkhostPIDhostIPChostPath, ou privileged? O que você pode fazer em cada caso? Vamos dar uma olhada!

Pods ruins do Kubernetes

 

BAD PODS – ATRIBUTOS E SEU PIOR CASO DE IMPACTO NA SEGURANÇA

Os pods abaixo são ordenados livremente do maior para o menor impacto de segurança. Observe que os caminhos de ataque genéricos que podem afetar qualquer pod do Kubernetes (por exemplo, verificar se o pod pode acessar o serviço de metadados do provedor de nuvem ou identificar o RBAC do Kubernetes configurado incorretamente) são abordados no Pod ruim nº 8: nada permitido .

O BAD PODS FORMAÇÃO

Pods

Bad Pod # 1: tudo permitido

Bad Pod # 2: Privileged e 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

Pod ruim # 8: nada permitido

BAD POD # 1: TUDO PERMITIDO

BAD POD # 1: TUDO PERMITIDO

Qual o pior que pode acontecer?

Vários caminhos para o comprometimento total do cluster

Quão?

O pod que você cria monta o sistema de arquivos do host no pod. Você terá mais sorte se puder programar seu pod em um nó de plano de controle usando o seletor nodeName em seu manifesto. Em seguida, entre execno pod e chroot no diretório onde montou o sistema de arquivos do host. Agora você tem root no nó que executa seu pod.

  • Ler segredos deetcd  – Se você puder executar seu pod em um nó de plano de controle usando o nodeNameseletor na especificação do pod, poderá ter acesso fácil ao etcdbanco de dados, que contém a configuração do cluster, incluindo todos os segredos.
  • Procure tokens de conta de serviço com privilégios – mesmo que você só possa programar seu pod no nó de trabalho, também pode acessar qualquer segredo montado em qualquer pod do nó em que está. Em um cluster de produção, mesmo em um nó de trabalho, geralmente há pelo menos um pod com um token montado vinculado a uma conta de serviço vinculada a um clusterrolebinding, que dá acesso para fazer coisas como criar pods ou visualizar segredos em todos os namespaces

Alguns padrões de escalonamento de privilégios adicionais são descritos no   documento README com link abaixo e também em  Bad Pod # 4: hostPath .

 

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/everything-allowed

Referências e leituras adicionais

BAD POD # 2: PRIVILEGIADO E HOSTPID

BAD POD # 2: PRIVILEGIADO E HOSTPID

Qual o pior que pode acontecer?

Vários caminhos para o comprometimento total do cluster

Quão?

Nesse cenário, a única coisa que muda no pod de tudo permitido é como você obtém acesso root ao host. Em vez de chrootir para o sistema de arquivos do host, você pode usar nsenterpara obter um shell raiz no nó que está executando seu pod.

Por que isso funciona?

  • Privilegiado – O privileged: truecontexto de segurança no nível do contêiner destrói quase todas as paredes que os contêineres deveriam fornecer; no entanto, o namespace PID é uma das poucas paredes que permanecem. Sem hostPIDnsenter funcionaria apenas para inserir os namespaces de um processo em execução no contêiner. Para obter mais exemplos sobre o que você pode fazer se tiver privileged: true, consulte o próximo exemplo Bad Pod # 3: Privileged Only .

  • Privilegiado +hostPID – Quando hostPID: true e privileged: truesão definidos, o pod pode ver todos os processos no host e você pode entrar no init sistema (PID 1) no host. A partir daí, você pode executar seu shell no nó.

Depois de ter feito root no host, os caminhos de escalonamento de privilégios são todos iguais aos descritos em Pod ruim nº 1: tudo permitido .

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/priv-and-hostpid

Referências e leituras adicionais

BAD POD # 3: PRIVILEGIADO SOMENTE

BAD POD # 3: PRIVILEGIADO SOMENTE

Qual o pior que pode acontecer?

Vários caminhos para o comprometimento total do cluster

Quão?

Se você tiver privileged: true, há dois caminhos que você pode seguir:

  • Monte o sistema de arquivos do host – no modo privilegiado, /devo host pode ser acessado em seu pod. Você pode montar o disco que contém o sistema de arquivos do host em seu pod usando o mountcomando. Na minha experiência, isso dá a você uma visão limitada do sistema de arquivos. Alguns arquivos e, portanto, caminhos privesc, não são acessíveis a partir de seu pod privilegiado, a menos que você escalone para um shell completo no nó. Dito isso, é fácil o suficiente para que você monte o dispositivo e veja o que você pode ver.

  • Explorar cgroup programas auxiliares do modo de usuário – Sua melhor aposta é obter acesso root interativo no nó, mas você deve pular alguns obstáculos primeiro. Você pode usar o exploit PoC undock.sh de Felix Wilhelm para executar um comando por vez ou pode usar a versão de Brandon Edwards e Nick Freeman de sua palestra A Compendium of Container Escapes , que força o host a se conectar de volta ao ouvinte no pod por uma atualização fácil para acesso root interativo no host. Outra opção é usar o módulo Metasploit Docker Privileged Container Escape , que usa o mesmo exploit para atualizar um shell recebido de um contêiner para um shell no host.

Qualquer que seja a opção escolhida, os caminhos de escalonamento de privilégios do Kubernetes são basicamente os mesmos do pod ruim nº 1: tudo permitido .

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/priv

Referências e leituras adicionais

 

BAD POD # 4: SOMENTE HOSTPATH

BAD POD # 4: SOMENTE HOSTPATH

Qual o pior que pode acontecer?

Vários caminhos para o comprometimento total do cluster

Quão?

Nesse caso, mesmo se você não tiver acesso ao processo do host ou aos namespaces da rede, se os administradores não limitarem o que você pode montar, você pode montar todo o sistema de arquivos do host em seu pod, dando-lhe acesso de leitura / gravação no sistema de arquivos do host. Isso permite que você execute a maioria dos mesmos caminhos de escalonamento de privilégios descritos acima. Existem tantos caminhos disponíveis que Ian Coldwater e Duffie Cooley deram uma palestra Black Hat 2019 incrível sobre o assunto, intitulada “ O caminho menos percorrido: abusando dos padrões do Kubernetes! 

Aqui estão alguns caminhos de escalonamento privilegiados que se aplicam sempre que você tem acesso ao sistema de arquivos de um nó do Kubernetes:

  • Procure por kubeconfig arquivos no sistema de arquivos host – Se você tiver sorte, encontrará uma cluster-adminconfiguração com acesso total a tudo.

  • Acessar as fichas de todos os pods no nó – Use algo como kubectl auth can-i --listou o acesso de matriz para ver se alguma das vagens têm fichas que lhe dão mais permissões do que você tem atualmente. Procure por tokens que tenham permissões para obter segredos ou criar pods, implantações, etc. kube-system, ou que permitam a criação de clusterrolebindings.

  • Adicione sua chave SSH – Se você tiver acesso de rede ao SSH para o nó, poderá adicionar sua chave pública ao nó e SSH a ele para acesso totalmente interativo.

  • Crack hash senhas – Crack hashes in /etc/shadow; veja se você pode usá-los para acessar outros nós.

 

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/hostpath

Referências e leituras adicionais

BAD POD # 5: SOMENTE HOSTPID

BAD POD # 5: SOMENTE HOSTPID

Qual o pior que pode acontecer?

O aplicativo ou a credencial do cluster vazam se um aplicativo do cluster estiver configurado incorretamente. Negação de serviço via encerramento do processo.

Quão?

Não há um caminho claro para obter root somente no nó hostPID, mas ainda existem algumas boas oportunidades de pós-exploração.

  • Visualize processos no host – ao executar a ps partir de um pod que já possui hostPID: true, você vê todos os processos em execução no host, incluindo os processos em execução em cada pod.

  • Procure por senhas, tokens, chaves, etc. – Se tiver sorte, você encontrará credenciais e poderá usá-las para escalar privilégios no cluster, escalar privilégios para serviços suportados pelo cluster ou escalar privilégios para serviços que comunicar-se com aplicativos hospedados em cluster. É um tiro no escuro, mas você pode encontrar um token de conta de serviço do Kubernetes ou algum outro material de autenticação que permitirá que você acesse outros namespaces e, eventualmente, escalar até o administrador do cluster.

  • Eliminar processos – você também pode eliminar qualquer processo no nó (apresentando um risco de negação de serviço). Por causa desse risco, porém, eu desaconselharia em um teste de penetração!

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/hostpid

BAD POD # 6: SOMENTE HOSTNETWORK

BAD POD # 6: SOMENTE HOSTNETWORK

Qual o pior que pode acontecer?

Caminho potencial para o comprometimento do cluster

Quão?

Se você apenas tiver feito isso hostNetwork: true, não poderá obter a execução de código privilegiado no host diretamente, mas se cruzar os dedos, ainda poderá encontrar um caminho para o administrador do cluster. Existem três caminhos de escalonamento possíveis:

  • Tráfego farejador – você pode usar tcpdumppara farejar tráfego não criptografado em qualquer interface no host. Você pode ter sorte e encontrar tokens de conta de serviço ou outras informações confidenciais que são transmitidas por canais não criptografados.

  • Serviços de acesso vinculados ao host local – você também pode acessar serviços que escutam apenas na interface de loopback do host ou que são bloqueados por políticas de rede. Esses serviços podem se tornar um caminho de escalonamento de privilégios produtivo.

  • Ignorar política de rede – se uma política de rede restritiva for aplicada ao namespace, a implantação de um pod com hostNetwork: truepermite que você ignore as restrições. Isso funciona porque você está vinculado às interfaces de rede do host e não aos pods.

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/hostnetwork

BAD POD # 7: SOMENTE HOSTIPC

BAD POD # 7: SOMENTE HOSTIPC

Qual o pior que pode acontecer?

Capacidade de acessar dados usados ​​por quaisquer pods que também usam o namespace IPC do host

Quão?

Se algum processo no host ou qualquer processo em um pod usar os mecanismos de comunicação entre processos do host (memória compartilhada, matrizes de semáforo, filas de mensagens, etc.), você poderá ler / gravar nesses mesmos mecanismos. O primeiro lugar que você deseja verificar é se /dev/shmele é compartilhado entre qualquer pod hostIPC: truee o host. Você também vai querer verificar os outros mecanismos IPC com ipcs.

  • Inspecione / dev / shm – Procure quaisquer arquivos neste local de memória compartilhada.

  • Inspecionar instalações IPC existentes – você pode verificar se alguma instalação IPC está sendo usada /usr/bin/ipcs.

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/hostipc

 

BAD POD # 8: NADA PERMITIDO

BAD POD # 8: NADA PERMITIDO

Qual o pior que pode acontecer?

Vários caminhos potenciais para o comprometimento total do cluster

Quão?

Para fechar nossa linha de pods ruins, existem vários caminhos de ataque que devem ser investigados sempre que você criar um pod ou simplesmente ter acesso a um pod, mesmo que não haja atributos de segurança habilitados. Aqui estão algumas coisas que você deve procurar sempre que tiver acesso a um pod do Kubernetes:

  • Metadados de nuvem acessíveis – se o pod estiver hospedado em nuvem, tente acessar o serviço de metadados de nuvem. Você pode obter acesso às credenciais de IAM associadas ao nó ou até mesmo apenas encontrar uma credencial de IAM de nuvem criada especificamente para esse pod. Em ambos os casos, este pode ser o seu caminho para escalar no cluster, no ambiente de nuvem ou em ambos.

  • Contas de serviço excessivamente permissivas – se a conta de serviço padrão do namespace estiver montada /var/run/secrets/kubernetes.io/serviceaccount/token em seu pod e for excessivamente permissiva, use esse token para escalonar ainda mais seus privilégios no cluster.

  • Componentes do Kubernetes configurados incorretamente – se o apiserver ou os kubelets foram anonymous-authdefinidos comotrue e não há controles de política de rede que o impeçam, você pode interagir com eles diretamente sem autenticação.

  • Explorações de kernel, mecanismo de contêiner ou Kubernetes – uma exploração sem patch no kernel subjacente, no mecanismo de contêiner ou no Kubernetes pode permitir o escape do contêiner ou o acesso ao cluster do Kubernetes sem nenhuma permissão adicional.

  • Procure por serviços vulneráveis – seu pod provavelmente terá uma visão diferente dos serviços de rede em execução no cluster do que você pode ver na máquina usada para criar o pod. Você pode caçar serviços e aplicativos vulneráveis ​​através do proxy do tráfego através do pod.

Exemplos de uso e exploração

https://github.com/BishopFox/badPods/tree/main/manifests/nothing-allowed

Referências e leituras adicionais

CONCLUSÃO

Além do exemplo Bad Pod # 8: Nothing Allowed , todos os caminhos de escalonamento de privilégios cobertos nesta postagem do blog (e o respectivo repositório ) podem ser mitigados com políticas de segurança de pod restritivas.

Além disso, existem muitos outros controles de segurança de defesa em profundidade disponíveis para administradores do Kubernetes que podem reduzir o impacto ou impedir completamente certos caminhos de ataque, mesmo quando um invasor tem acesso a alguns ou todos os namespaces e recursos do host (por exemplo, desativando o montagem automática de tokens de conta de serviço ou exigir que todos os pods sejam executados como não-root, aplicando MustRunAsNonRoot=trueallowPrivilegeEscalation=false). Como sempre acontece com o teste de penetração, sua milhagem pode variar.

Os administradores às vezes têm dificuldade em defender as práticas recomendadas de segurança sem exemplos que demonstrem as implicações de segurança de configurações arriscadas. Espero que os exemplos apresentados nesta postagem e os manifestos contidos no repositório de pods ruins ajudem você a aplicar o princípio do menor privilégio quando se trata da criação de pods do Kubernetes em sua organização.

Curso - Engenharia Reversa na Forense Digital

Aqui você compreenderá a utilização da Engenharia Reversa aplicada em Forense Digital, bem como a Análise de Malware.

O curso aborda diversos conceitos de forma prática. O estudo é baseado, em sua maioria, no .NET e .NET Core, pois é uma tecnologia que está sempre em evolução, sendo adicionada inclusive em Linux e MAC, ou seja, com o .NET Core, agora é multiplataforma.

Analisando este ambiente, podemos entender que é de extrema importância e urgente necessidade aprender a dissecar malwares desenvolvidos em alguma linguagem do .NET e .NET Core, com C#, VB, etc…

Conheça o curso CFID

Conheça o curso Computação Forense e Investigação Digital.

Este curso tem como objetivo apresentar os conceitos da Computação Forense e métodos de Investigação Digital, sendo baseado no conteúdo apresentado nas certificações mais conhecidas do mercado.

Hospedagem de site

digitalocean, excelente custo benefício.

Clique abaixo e aproveite!