SteamCloud
https://app.hackthebox.com/machines/SteamCloud
Summary
Máquina Linux de dificuldade fácil do HackTheBox que apresenta um cluster Kubernetes (minikube). A exploração começou com a identificação da API Kubernetes na porta 8443, que estava acessível mas exigia autenticação. Através da ferramenta kubeletctl, foi possível enumerar os pods e identificar que o pod nginx permitia execução de comandos (RCE). Com acesso ao container, os tokens de serviço do Kubernetes foram extraídos do diretório /run/secrets/kubernetes.io/serviceaccount. O token concedia permissões para criar pods no namespace default, permitindo a criação de um novo pod com montagem do sistema de arquivos do host (hostPath). Através dessa montagem, as flags foram obtidas e uma chave SSH foi adicionada para acesso persistente ao host.
MITRE Kill Chain
Reconnaissance
#attack/T1595 #attack/T1046
Host Discovery
A primeira ação para reconhecimento do alvo é testar a conectividade com ele, utilizando o comando ping. Ao enviar um pacote ICMP, é possível confirmar se a máquina alvo está acessível na rede.
No retorno, o TTL de 63 é uma indicação de que possivelmente estamos lidando com um sistema Linux. O TTL inicial para sistemas Linux geralmente é 64, e o valor observado no ping é reduzido conforme os pacotes atravessam roteadores na rede. Como o TTL está próximo de 64, é provável que o sistema alvo seja uma máquina Linux.
attacker> ping -c 1 10.10.11.133
PING 10.10.11.133 (10.10.11.133) 56(84) bytes of data.
64 bytes from 10.10.11.133: icmp_seq=1 ttl=63 time=175 ms
--- 10.10.11.133 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 174.623/174.623/174.623/0.000 msPort Scanning
#attack/T1046
Em seguida, uma varredura de portas foi executada no alvo para identificar quaisquer portas abertas que pudessem ser usadas para novos ataques. A ferramenta rustscan foi utilizada para verificar todas as portas (1-65535) no alvo. A varredura revelou duas portas abertas com serviços relevantes:
22/tcp: SSH (OpenSSH 7.9p1 Debian 10+deb10u2)
8443/tcp: API Kubernetes (minikube)
A porta 8443 revelou ser a API do Kubernetes (minikube), retornando erros de acesso anónimo quando consultada diretamente.
Web Enumeration
#attack/T1593 #attack/T1592
Ao investigar o serviço, descobriu-se que era a API do minikube. Para interagir com ela, a ferramenta kubeletctl foi instalada.
Pods Enumeration
A ferramenta kubeletctl permite enumerar os pods em execução no cluster Kubernetes através do Kubelet. A enumeração revelou vários pods em execução:
O pod nginx está no namespace default, diferentemente dos outros pods que estão no namespace kube-system.
RCE Discovery
A funcionalidade de scan RCE da ferramenta kubeletctl foi utilizada para identificar pods que permitem execução de comandos:
Dois pods foram identificados como vulneráveis a RCE: kube-proxy-qk4zw e nginx.
Initial Access
#attack/T1078 #attack/T1610
O pod nginx foi selecionado para exploração. A ferramenta kubeletctl permite executar comandos diretamente no container através da API do Kubelet.
O comando retornou root, confirmando que havia acesso ao container como root. Em seguida, uma shell interativa foi obtida:
O container estava a executar com o IP 172.17.0.3 dentro da rede do cluster Kubernetes.
Credential Access
#attack/T1552
Após obter acesso ao container nginx, o diretório /run/secrets/kubernetes.io/serviceaccount foi inspecionado. Este diretório contém os tokens e certificados usados pelo Kubernetes para autenticação automática dos pods:
Este diretório contém três ficheiros essenciais:
ca.crt: Certificado da Autoridade Certificadora do cluster
namespace: Namespace onde o pod está a executar (default)
token: Token de autenticação JWT do ServiceAccount
Os ficheiros ca.crt e token foram copiados para a máquina atacante para posterior utilização com a ferramenta kubectl.
Credenciais descobertas
ServiceAccount Token: Extraído do pod nginx
CA Certificate: Extraído do pod nginx
Namespace: default
Com estes artefatos, é possível interagir com a API Kubernetes para enumerar e manipular recursos dentro das permissões do ServiceAccount.
Kubernetes Exploitation
#attack/T1200 #attack/T1610
Os ficheiros ca.crt e token extraídos foram utilizados para autenticar junto da API Kubernetes através da ferramenta kubectl.
Permission Enumeration
O comando auth can-i --list foi utilizado para verificar as permissões do ServiceAccount atual:
A saída revela que o ServiceAccount tem permissões para criar pods no namespace default. Esta é uma capacidade crítica que pode ser abusada para escalação de privilégios.
Finding: Kubernetes RBAC Misconfiguration - Pod Creation Privilege
Affected Asset: Kubernetes Cluster (minikube) - Namespace: default
Severity: High
Vulnerability Type: Kubernetes RBAC Misconfiguration / Privilege Escalation
CVE: N/A
Reproduction Steps:
Identificar pods vulneráveis a RCE: kubeletctl -s <TARGET> scan rce
Executar comando no pod: kubeletctl -s <TARGET> -p <POD> -c <CONTAINER> exec "whoami"
Extrair tokens do diretório: /run/secrets/kubernetes.io/serviceaccount/
Verificar permissões: kubectl auth can-i --list
Criar pod malicioso com montagem hostPath: kubectl apply -f malicious-pod.yaml
Executar shell no novo pod e aceder ao sistema host
Remediation: Restringir permissões de ServiceAccount. Evitar atribuir permissões create a pods sem necessidade. Implementar Network Policies para limitar comunicação entre pods. Não expor tokens de ServiceAccount em pods que não necessitam de acesso à API Kubernetes.
Pod Configuration
A configuração do pod nginx existente foi obtida para servir de base:
O pod foi modificado para incluir uma montagem hostPath que mapeia o sistema de ficheiros do nó (host) para dentro do container:
Pod Creation
O novo pod foi criado no cluster:
A criação foi confirmada enumerando os pods:
Privilege Escalation
#attack/T1068
O pod brunopod foi verificado quanto à capacidade de execução de comandos:
O pod brunopod permitiu execução de comandos. Através da montagem hostPath (/), foi possível aceder ao sistema de ficheiros do nó (host):
As flags foram encontradas nos diretórios /home/user e /root do host:
Flag de utilizador capturada: aa5d1e2d35ae461ef8a6289a9d67d5d7
Persistence
Para obter acesso persistente ao host, uma chave SSH foi adicionada ao diretório .ssh do root:
Uma chave SSH foi gerada na máquina atacante:
O acesso SSH ao host foi obtido:
Escalação de privilégios bem-sucedida. Comprometimento total do sistema alcançado.

Atualizado