Attacking Kubernetes from inside a Pod
Atacando o Kubernetes de dentro de um Pod
Fuga do Pod
Se tiver sorte, pode conseguir escapar para o nó:
Escapando do pod
Para tentar escapar dos pods, você pode precisar elevar privilégios primeiro, algumas técnicas para fazer isso:
Você pode verificar essas fugas do Docker para tentar escapar de um pod comprometido:
Abusando dos Privilégios do Kubernetes
Como explicado na seção sobre enumeração do Kubernetes:
Kubernetes EnumerationNormalmente, os pods são executados com um token de conta de serviço dentro deles. Esta conta de serviço pode ter alguns privilégios anexados que você poderia abusar para mover-se para outros pods ou até mesmo escapar para os nós configurados dentro do cluster. Veja como em:
Abusing Roles/ClusterRoles in KubernetesAbusando dos Privilégios na Nuvem
Se o pod é executado dentro de um ambiente de nuvem, você pode ser capaz de vazar um token do endpoint de metadados e elevar privilégios usando-o.
Pesquisar serviços de rede vulneráveis
Como você está dentro do ambiente do Kubernetes, se não conseguir elevar privilégios abusando dos privilégios atuais dos pods e não conseguir escapar do contêiner, você deve procurar serviços potencialmente vulneráveis.
Serviços
Para este propósito, você pode tentar obter todos os serviços do ambiente Kubernetes:
Por padrão, o Kubernetes usa um esquema de rede plana, o que significa que qualquer pod/serviço dentro do cluster pode se comunicar com outros. Os namespaces dentro do cluster não possuem restrições de segurança de rede por padrão. Qualquer pessoa no namespace pode se comunicar com outros namespaces.
Escaneamento
O seguinte script Bash (retirado de um workshop do Kubernetes) irá instalar e escanear os intervalos de IP do cluster Kubernetes:
Dê uma olhada na seguinte página para aprender como você poderia atacar serviços específicos do Kubernetes para comprometer outros pods/todo o ambiente:
Pentesting Kubernetes ServicesSniffing
No caso do pod comprometido estar executando algum serviço sensível onde outros pods precisam autenticar, você pode ser capaz de obter as credenciais enviadas pelos outros pods farejando comunicações locais.
Network Spoofing
Por padrão, técnicas como ARP spoofing (e graças a isso DNS Spoofing) funcionam na rede do Kubernetes. Então, dentro de um pod, se você tiver a capacidade NET_RAW (que está lá por padrão), você poderá enviar pacotes de rede personalizados e realizar ataques de MitM via ARP Spoofing para todos os pods em execução no mesmo nó. Além disso, se o pod malicioso estiver em execução no mesmo nó que o Servidor DNS, você poderá realizar um ataque de DNS Spoofing para todos os pods no cluster.
Kubernetes Network AttacksNode DoS
Não há especificação de recursos nos manifestos do Kubernetes e limites não aplicados para os contêineres. Como atacante, podemos consumir todos os recursos onde o pod/deployment está em execução e privar outros recursos, causando um DoS para o ambiente.
Isso pode ser feito com uma ferramenta como stress-ng:
Você pode ver a diferença enquanto executa stress-ng
e depois
Pós-Exploração do Node
Se você conseguiu escapar do contêiner, encontrará algumas coisas interessantes no node:
O processo de Container Runtime (Docker)
Mais pods/contêineres em execução no node que você pode abusar como este (mais tokens)
Todo o sistema de arquivos e o SO em geral
O serviço Kube-Proxy ouvindo
O serviço Kubelet ouvindo. Verifique os arquivos de configuração:
Diretório:
/var/lib/kubelet/
/var/lib/kubelet/kubeconfig
/var/lib/kubelet/kubelet.conf
/var/lib/kubelet/config.yaml
/var/lib/kubelet/kubeadm-flags.env
/etc/kubernetes/kubelet-kubeconfig
Outros arquivos comuns do Kubernetes:
$HOME/.kube/config
- Configuração do Usuário/etc/kubernetes/kubelet.conf
- Configuração Regular/etc/kubernetes/bootstrap-kubelet.conf
- Configuração de Inicialização/etc/kubernetes/manifests/etcd.yaml
- Configuração do etcd/etc/kubernetes/pki
- Chave do Kubernetes
Encontrar o kubeconfig do node
Se você não conseguir encontrar o arquivo kubeconfig em um dos caminhos comentados anteriormente, verifique o argumento --kubeconfig
do processo kubelet:
Roubar Segredos
O script can-they.sh irá automaticamente obter os tokens de outros pods e verificar se eles têm a permissão que você está procurando (em vez de você verificar um por um):
DaemonSets Privilegiados
Um DaemonSet é um pod que será executado em todos os nós do cluster. Portanto, se um DaemonSet for configurado com uma conta de serviço privilegiada, em TODOS os nós você será capaz de encontrar o token dessa conta de serviço privilegiada que você poderia abusar.
O exploit é o mesmo da seção anterior, mas agora você não depende da sorte.
Pivot para a Nuvem
Se o cluster for gerenciado por um serviço de nuvem, geralmente o Nó terá um acesso diferente ao endpoint de metadados do que o Pod. Portanto, tente acessar o endpoint de metadados a partir do nó (ou de um pod com hostNetwork para True):
Kubernetes Pivoting to CloudsRoubar etcd
Se você puder especificar o nodeName do Nó que executará o contêiner, obtenha um shell dentro de um nó de plano de controle e obtenha o banco de dados etcd:
Os nós de control-plane têm a função de mestre e em clusters gerenciados na nuvem você não poderá executar nada neles.
Ler segredos do etcd
Se você puder executar seu pod em um nó de control-plane usando o seletor nodeName
na especificação do pod, você pode ter acesso fácil ao banco de dados etcd
, que contém toda a configuração do cluster, incluindo todos os segredos.
Abaixo está uma maneira rápida e suja de pegar segredos do etcd
se ele estiver sendo executado no nó de control-plane em que você está. Se você deseja uma solução mais elegante que inicie um pod com a utilidade do cliente etcd
etcdctl
e use as credenciais do nó de control-plane para se conectar ao etcd onde quer que ele esteja sendo executado, confira este exemplo de manifesto de @mauilion.
Verifique se o etcd
está sendo executado no nó de control-plane e veja onde o banco de dados está (Isso é em um cluster criado com kubeadm
)
Atacando o Kubernetes de Dentro de um Pod
Ao executar um pod comprometido em um cluster Kubernetes, um invasor pode explorar várias técnicas para escalar seus privilégios e comprometer outros recursos no cluster. Algumas técnicas comuns incluem:
Montagem de Volumes do Host: Montar o diretório raiz do host dentro do pod pode permitir que um invasor acesse outros pods e segredos sensíveis.
Execução de Comandos Privilegiados: A execução de comandos com privilégios elevados dentro de um pod comprometido pode ajudar um invasor a obter controle total sobre o cluster.
Exploração de Vulnerabilidades: Aproveitar vulnerabilidades conhecidas no Kubernetes ou em aplicações em execução no cluster para obter acesso não autorizado.
É crucial implementar práticas de segurança sólidas, como limitar as permissões dos pods e monitorar de perto o tráfego de rede, para proteger o cluster Kubernetes contra ataques internos.
Visualizar os dados no banco de dados etcd:
Extrair os tokens do banco de dados e mostrar o nome da conta de serviço
Mesmo comando, mas com alguns greps para retornar apenas o token padrão no namespace kube-system
Persistência de Pods Estáticos/Refletidos
Pods Estáticos são gerenciados diretamente pelo daemon kubelet em um nó específico, sem que o servidor de API os observe. Ao contrário dos Pods gerenciados pelo plano de controle (por exemplo, um Deployment); em vez disso, o kubelet observa cada Pod estático (e o reinicia se falhar).
Portanto, os Pods estáticos estão sempre vinculados a um Kubelet em um nó específico.
O kubelet tenta automaticamente criar um Pod espelho no servidor de API do Kubernetes para cada Pod está do. Isso significa que os Pods em execução em um nó são visíveis no servidor de API, mas não podem ser controlados a partir dele. Os nomes dos Pods terão um sufixo com o nome do nó com um hífen inicial.
O spec
de um Pod estático não pode se referir a outros objetos de API (por exemplo, ServiceAccount, ConfigMap, Secret, etc. Portanto, você não pode abusar desse comportamento para lançar um pod com uma ServiceAccount arbitrária no nó atual para comprometer o cluster. Mas você poderia usar isso para executar pods em namespaces diferentes (caso seja útil por algum motivo).
Se você estiver dentro do nó host, pode fazer com que ele crie um pod estático dentro dele mesmo. Isso é bastante útil porque pode permitir que você crie um pod em um namespace diferente, como kube-system.
Para criar um pod estático, a [̈ documentação é de grande ajuda. Basicamente, você precisa de 2 coisas:
Configurar o parâmetro
--pod-manifest-path=/etc/kubernetes/manifests
no serviço kubelet, ou no config kubelet (staticPodPath) e reiniciar o serviçoCriar a definição no **arquivo de def historians. is of Real
.
of of of of of of of of of of .
Excluir pods + nós não escalonáveis
Se um atacante comprometeu um nó e ele pode excluir pods de outros nós e impedir que outros nós executem pods, os pods serão reiniciados no nó comprometido e ele poderá roubar os tokens executados neles. Para mais informações siga estes links.
Ferramentas Automáticas
Last updated