githubEditar
hacktheboxlinuxkubernetsrce

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

1

Reconnaissance

A varredura de portas revelou dois serviços principais: SSH (22) e a API Kubernetes (8443) do minikube.

2

Initial Access

O pod nginx foi identificado como vulnerável a RCE via kubelet. Acesso shell ao container foi obtido.

3

Credential Access

Os tokens de autenticação Kubernetes foram extraídos do pod comprometido através dos arquivos em /run/secrets/kubernetes.io/serviceaccount.

4

Lateral Movement

O token extraído permitiu interação com a API Kubernetes para criar novos pods no namespace default.

5

Privilege Escalation

Um novo pod foi criado com montagem hostPath do sistema de arquivos, permitindo acesso ao sistema host e obtenção das flags.


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 ms

Port 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.

circle-exclamation

Credenciais descobertas

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.

triangle-exclamation

Finding: Kubernetes RBAC Misconfiguration - Pod Creation Privilege

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:

circle-check

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:

circle-check

Atualizado