Pentesting Kubernetes Services
Last updated
Last updated
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Kubernetes usa vários serviços de rede específicos que você pode encontrar expostos à Internet ou em uma rede interna uma vez que você tenha comprometido um pod.
Uma maneira pode ser procurar por Identity LIKE "k8s.%.com"
em crt.sh para encontrar subdomínios relacionados ao kubernetes. Outra maneira pode ser pesquisar "k8s.%.com"
no github e procurar por arquivos YAML contendo a string.
Pode ser útil para você entender como o Kubernetes pode expor serviços publicamente para encontrá-los:
Exposing Services in KubernetesAs seguintes portas podem estar abertas em um cluster Kubernetes:
443/TCP
kube-apiserver
Porta da API do Kubernetes
2379/TCP
etcd
6666/TCP
etcd
etcd
4194/TCP
cAdvisor
Métricas do contêiner
6443/TCP
kube-apiserver
Porta da API do Kubernetes
8443/TCP
kube-apiserver
Porta da API do Minikube
8080/TCP
kube-apiserver
Porta da API insegura
10250/TCP
kubelet
API HTTPS que permite acesso em modo total
10255/TCP
kubelet
Porta HTTP somente leitura não autenticada: pods, pods em execução e estado do nó
10256/TCP
kube-proxy
Servidor de verificação de saúde do Kube Proxy
9099/TCP
calico-felix
Servidor de verificação de saúde para Calico
6782-4/TCP
weave
Métricas e endpoints
30000-32767/TCP
NodePort
Proxy para os serviços
44134/TCP
Tiller
Serviço Helm escutando
Este é o serviço API Kubernetes com o qual os administradores geralmente se comunicam usando a ferramenta kubectl
.
Portas comuns: 6443 e 443, mas também 8443 no minikube e 8080 como inseguro.
Verifique a página a seguir para aprender como obter dados sensíveis e realizar ações sensíveis conversando com este serviço:
Kubernetes EnumerationEste serviço é executado em cada nó do cluster. É o serviço que controlará os pods dentro do nó. Ele se comunica com o kube-apiserver.
Se você encontrar este serviço exposto, pode ter encontrado um RCE não autenticado.
Se a resposta for Unauthorized
, então é necessário autenticação.
Se você puder listar nós, pode obter uma lista de endpoints de kubelets com:
Você pode abusar deste serviço para escalar privilégios dentro do Kubernetes:
Serviço útil para coletar métricas.
Quando uma porta é exposta em todos os nós via NodePort, a mesma porta é aberta em todos os nós, proxyando o tráfego para o Service declarado. Por padrão, essa porta estará na faixa 30000-32767. Portanto, novos serviços não verificados podem estar acessíveis através dessas portas.
O acesso anônimo aos endpoints da API kube-apiserver não é permitido. Mas você pode verificar alguns endpoints:
O ETCD armazena os segredos do cluster, arquivos de configuração e mais dados sensíveis. Por padrão, o ETCD não pode ser acessado anonimamente, mas é sempre bom verificar.
Se o ETCD puder ser acessado anonimamente, você pode precisar usar o etcdctl ferramenta. O seguinte comando irá obter todas as chaves armazenadas:
A documentação do Kubelet explica que, por padrão, o acesso anônimo ao serviço é permitido:
Permite solicitações anônimas ao servidor Kubelet. Solicitações que não são rejeitadas por outro método de autenticação são tratadas como solicitações anônimas. Solicitações anônimas têm um nome de usuário de
system:anonymous
e um nome de grupo desystem:unauthenticated
Para entender melhor como funciona a autenticação e autorização da API Kubelet, consulte esta página:
Kubelet Authentication & AuthorizationA API do serviço Kubelet não está documentada, mas o código-fonte pode ser encontrado aqui e encontrar os endpoints expostos é tão fácil quanto executar:
Todos eles parecem interessantes.
Você pode usar a ferramenta Kubeletctl para interagir com Kubelets e seus endpoints.
Este endpoint lista pods e seus contêineres:
Este endpoint permite executar código dentro de qualquer contêiner com muita facilidade:
Para evitar esse ataque, o serviço kubelet deve ser executado com --anonymous-auth false
e o serviço deve ser segregado em nível de rede.
Quando uma porta de leitura do kubelet está exposta, torna-se possível que informações sejam recuperadas da API por partes não autorizadas. A exposição dessa porta pode levar à divulgação de vários elementos de configuração do cluster. Embora as informações, incluindo nomes de pods, locais de arquivos internos e outras configurações, possam não ser críticas, sua exposição ainda representa um risco à segurança e deve ser evitada.
Um exemplo de como essa vulnerabilidade pode ser explorada envolve um atacante remoto acessando uma URL específica. Ao navegar para http://<external-IP>:10255/pods
, o atacante pode potencialmente recuperar informações sensíveis do kubelet:
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)