CVE-2024-36538
📋 TL;DR
This vulnerability in Chaos Mesh v2.6.3 involves insecure permissions that allow attackers to access service account tokens. Attackers can use these tokens to escalate privileges and access sensitive data within Kubernetes clusters. Organizations running vulnerable Chaos Mesh versions in Kubernetes environments are affected.
💻 Affected Systems
- Chaos Mesh
📦 What is this software?
Chaos Mesh by Chaos Mesh
⚠️ Risk & Real-World Impact
Worst Case
Full cluster compromise allowing attackers to deploy malicious workloads, exfiltrate sensitive data, and disrupt critical services across the entire Kubernetes environment.
Likely Case
Privilege escalation within the cluster leading to unauthorized access to sensitive resources, potential data theft, and lateral movement to other workloads.
If Mitigated
Limited impact with proper network segmentation, RBAC restrictions, and monitoring preventing token misuse even if obtained.
🎯 Exploit Status
Exploitation requires initial access to the Kubernetes cluster but is straightforward once inside. Public proof-of-concept details are available in the referenced gists.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: v2.6.4 or later
Vendor Advisory: https://github.com/chaos-mesh/chaos-mesh/security/advisories
Restart Required: Yes
Instructions:
1. Backup current Chaos Mesh configuration. 2. Update Chaos Mesh to v2.6.4 or later using Helm: 'helm upgrade chaos-mesh chaos-mesh/chaos-mesh --namespace chaos-mesh --version 2.6.4'. 3. Verify all pods restart successfully. 4. Test chaos experiments to ensure functionality.
🔧 Temporary Workarounds
Restrict Service Account Permissions
linuxApply least-privilege RBAC to limit what the vulnerable service account can access
kubectl create clusterrole restricted-role --verb=get,list --resource=pods
kubectl create clusterrolebinding restricted-binding --clusterrole=restricted-role --serviceaccount=chaos-mesh:chaos-controller-manager
Network Policy Isolation
linuxIsolate Chaos Mesh components from sensitive workloads using network policies
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: chaos-mesh-isolation
namespace: chaos-mesh
spec:
podSelector: {}
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
name: chaos-mesh
egress:
- to:
- namespaceSelector:
matchLabels:
name: chaos-mesh
EOF
🧯 If You Can't Patch
- Implement strict network segmentation to isolate Chaos Mesh from critical workloads and sensitive data
- Deploy runtime security monitoring to detect and alert on suspicious token usage or privilege escalation attempts
🔍 How to Verify
Check if Vulnerable:
Check Chaos Mesh version: 'kubectl get deployment chaos-controller-manager -n chaos-mesh -o jsonpath="{.spec.template.spec.containers[0].image}" | grep -o '2\.6\.3'Check Version:
kubectl get deployment chaos-controller-manager -n chaos-mesh -o jsonpath="{.spec.template.spec.containers[0].image}"Verify Fix Applied:
Verify version is 2.6.4 or later: 'kubectl get deployment chaos-controller-manager -n chaos-mesh -o jsonpath="{.spec.template.spec.containers[0].image}"' and check for 2.6.4+📡 Detection & Monitoring
Log Indicators:
- Unauthorized service account token usage
- Unexpected privilege escalation attempts
- Suspicious API calls from Chaos Mesh service accounts
Network Indicators:
- Unusual outbound connections from Chaos Mesh pods to sensitive services
- Lateral movement attempts from Chaos Mesh namespace
SIEM Query:
source="kubernetes" (service_account="chaos-controller-manager" OR pod_name="chaos-controller-manager-*") AND (verb!="get" OR verb!="list" OR resource!="pods")