Kubernetes Enumeration
Kubernetes Tokens
Se você tiver acesso comprometido a uma máquina, o usuário pode ter acesso a alguma plataforma Kubernetes. O token geralmente está localizado em um arquivo apontado pela variável de ambiente KUBECONFIG
ou dentro de ~/.kube
.
Nesta pasta, você pode encontrar arquivos de configuração com tokens e configurações para se conectar ao servidor API. Nesta pasta, você também pode encontrar uma pasta de cache com informações previamente recuperadas.
Se você comprometeu um pod dentro de um ambiente kubernetes, há outros lugares onde você pode encontrar tokens e informações sobre o ambiente K8 atual:
Service Account Tokens
Antes de continuar, se você não sabe o que é um serviço no Kubernetes, eu sugeriria que você seguísse este link e lesse pelo menos as informações sobre a arquitetura do Kubernetes.
Retirado da documentação:
“Quando você cria um pod, se não especificar uma conta de serviço, ela é automaticamente atribuída à conta de serviço padrão no mesmo namespace.”
ServiceAccount é um objeto gerenciado pelo Kubernetes e usado para fornecer uma identidade para processos que são executados em um pod. Cada conta de serviço tem um segredo relacionado a ela e esse segredo contém um token portador. Este é um JSON Web Token (JWT), um método para representar reivindicações de forma segura entre duas partes.
Geralmente um dos diretórios:
/run/secrets/kubernetes.io/serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount
/secrets/kubernetes.io/serviceaccount
contém os arquivos:
ca.crt: É o certificado CA para verificar as comunicações do kubernetes
namespace: Indica o namespace atual
token: Contém o token de serviço do pod atual.
Agora que você tem o token, pode encontrar o servidor API dentro da variável de ambiente KUBECONFIG
. Para mais informações, execute (env | set) | grep -i "kuber|kube
"
O token da conta de serviço está sendo assinado pela chave que reside no arquivo sa.key e validado por sa.pub.
Localização padrão no Kubernetes:
/etc/kubernetes/pki
Localização padrão no Minikube:
/var/lib/localkube/certs
Hot Pods
Hot pods são pods que contêm um token de conta de serviço privilegiado. Um token de conta de serviço privilegiado é um token que tem permissão para realizar tarefas privilegiadas, como listar segredos, criar pods, etc.
RBAC
Se você não sabe o que é RBAC, leia esta seção.
GUI Applications
k9s: Uma GUI que enumera um cluster kubernetes a partir do terminal. Confira os comandos em https://k9scli.io/topics/commands/. Escreva
:namespace
e selecione tudo para então pesquisar recursos em todos os namespaces.k8slens: Oferece alguns dias de teste gratuito: https://k8slens.dev/
Enumeration CheatSheet
Para enumerar um ambiente K8s, você precisa de alguns itens:
Um token de autenticação válido. Na seção anterior, vimos onde procurar um token de usuário e um token de conta de serviço.
O endereço (https://host:port) do API do Kubernetes. Isso pode ser geralmente encontrado nas variáveis de ambiente e/ou no arquivo de configuração kube.
Opcional: O ca.crt para verificar o servidor API. Isso pode ser encontrado nos mesmos lugares onde o token pode ser encontrado. Isso é útil para verificar o certificado do servidor API, mas usando
--insecure-skip-tls-verify
comkubectl
ou-k
comcurl
, você não precisará disso.
Com esses detalhes, você pode enumerar kubernetes. Se a API por algum motivo for acessível através da Internet, você pode simplesmente baixar essas informações e enumerar a plataforma a partir de sua máquina.
No entanto, geralmente o servidor API está dentro de uma rede interna, portanto, você precisará criar um túnel através da máquina comprometida para acessá-lo a partir de sua máquina, ou pode fazer upload do kubectl binário, ou usar curl/wget/qualquer coisa
para realizar solicitações HTTP brutas ao servidor API.
Differences between list
and get
verbs
list
and get
verbsCom permissões get
, você pode acessar informações de ativos específicos (opção describe
em kubectl
) API:
Se você tiver a permissão list
, você está autorizado a executar solicitações de API para listar um tipo de ativo (opção get
no kubectl
):
Se você tiver a permissão watch
, você está autorizado a executar solicitações de API para monitorar ativos:
Eles abrem uma conexão de streaming que retorna o manifesto completo de um Deployment sempre que ele muda (ou quando um novo é criado).
Os seguintes comandos kubectl
indicam apenas como listar os objetos. Se você quiser acessar os dados, precisa usar describe
em vez de get
Usando curl
De dentro de um pod, você pode usar várias variáveis de ambiente:
Por padrão, o pod pode acessar o kube-api server no nome de domínio kubernetes.default.svc
e você pode ver a rede kube em /etc/resolv.config
pois aqui você encontrará o endereço do servidor DNS do kubernetes (o ".1" do mesmo intervalo é o endpoint do kube-api).
Usando kubectl
Tendo o token e o endereço do servidor API, você usa kubectl ou curl para acessá-lo conforme indicado aqui:
Por padrão, o APISERVER está se comunicando com o esquema https://
se não houver
https://
na URL, você pode receber um erro como Bad Request.
Você pode encontrar um cheatsheet oficial do kubectl aqui. O objetivo das seções a seguir é apresentar de forma ordenada diferentes opções para enumerar e entender o novo K8s ao qual você obteve acesso.
Para encontrar a solicitação HTTP que o kubectl
envia, você pode usar o parâmetro -v=8
MitM kubectl - Proxyfying kubectl
Configuração Atual
Se você conseguiu roubar as credenciais de alguns usuários, pode configurá-las localmente usando algo como:
Obter Recursos Suportados
Com essas informações, você saberá todos os serviços que pode listar
Obter Privilégios Atuais
Outra maneira de verificar seus privilégios é usando a ferramenta: https://github.com/corneliusweig/rakkess****
Você pode aprender mais sobre Kubernetes RBAC em:
Kubernetes Role-Based Access Control(RBAC)Uma vez que você saiba quais privilégios você tem, verifique a página a seguir para descobrir se você pode abusar deles para escalar privilégios:
Abusing Roles/ClusterRoles in KubernetesObter outros papéis
Obter namespaces
Kubernetes suporta múltiplos clusters virtuais suportados pelo mesmo cluster físico. Esses clusters virtuais são chamados de namespaces.
Obter segredos
Se você pode ler segredos, pode usar as seguintes linhas para obter os privilégios relacionados a cada token:
Obter Contas de Serviço
Como discutido no início desta página, quando um pod é executado, uma conta de serviço é geralmente atribuída a ele. Portanto, listar as contas de serviço, suas permissões e onde estão sendo executadas pode permitir que um usuário escale privilégios.
Obter Implantações
As implantações especificam os componentes que precisam ser executados.
Obter Pods
Os Pods são os contêineres reais que irão executar.
Obter Serviços
Os serviços do Kubernetes são usados para expor um serviço em uma porta e IP específicos (que atuarão como balanceador de carga para os pods que estão realmente oferecendo o serviço). Isso é interessante para saber onde você pode encontrar outros serviços para tentar atacar.
Obter nós
Obtenha todos os nós configurados dentro do cluster.
Obter DaemonSets
DaemonSets permite garantir que um pod específico esteja em execução em todos os nós do cluster (ou nos selecionados). Se você excluir o DaemonSet, os pods gerenciados por ele também serão removidos.
Obter cronjob
Os cron jobs permitem agendar, usando uma sintaxe semelhante ao crontab, o lançamento de um pod que realizará alguma ação.
Obter configMap
configMap sempre contém muitas informações e arquivos de configuração que fornecem para os aplicativos que rodam no kubernetes. Normalmente, você pode encontrar muitas senhas, segredos e tokens que são usados para conectar e validar a outros serviços internos/externos.
Obter Políticas de Rede / Políticas de Rede Cilium
Obter Tudo / Todos
Obter todos os recursos gerenciados pelo helm
Obter consumos de Pods
Escapando do pod
Se você conseguir criar novos pods, pode ser capaz de escapar deles para o nó. Para fazer isso, você precisa criar um novo pod usando um arquivo yaml, mudar para o pod criado e, em seguida, chroot no sistema do nó. Você pode usar pods já existentes como referência para o arquivo yaml, uma vez que eles exibem imagens e caminhos existentes.
se você precisar criar um pod em um nó específico, pode usar o seguinte comando para obter rótulos no nó
k get nodes --show-labels
Comumente, kubernetes.io/hostname e node-role.kubernetes.io/master são todos bons rótulos para seleção.
Então você cria seu arquivo attack.yaml
Depois disso, você cria o pod
Agora você pode alternar para o pod criado da seguinte forma
E finalmente você chroot no sistema do nó
Informações obtidas de: Kubernetes Namespace Breakout usando Insecure Host Path Volume — Parte 1 Atacando e Defendendo Kubernetes: Bust-A-Kube – Episódio 1
Referências
Last updated