GHSA-h27c-6xm3-mcqp: Kanister vulnerable to cluster-level privilege escalation

Details

The kanister has a deployment called default-kanister-operator, which is bound with a ClusterRole called edit via ClusterRoleBinding(https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49). The “edit” ClusterRole is one of Kubernetes default-created ClusterRole, and it have create/patch/udpate verbs of daemonset resources, create verb of serviceaccount/token resources, and impersonate verb of serviceaccounts resources. If a malicious user can access the worker node which has this component, he/she can:

For the create/patch/update verbs of daemonset resources, the malicious user can abuse it to create or modify a set of Pods to mount a high-privilege service account (e.g., the cluster-admin service account). After that, he/she can abuse the high-privilege SA token of created Pod to take over the whole cluster.

For the create verb of serviceaccount/token resources, a malicious user can abuse this permission to generate new Service Account tokens and use them to operate with high-privilege roles, such as cluster administrators. These tokens can be used to access and manipulate any resources within the cluster.

For the impersonate verb of serviceaccounts resources, a malicious user can impersonate high-privilege Service Accounts, thereby gaining access to roles such as cluster administrators. This enables the attacker to perform all actions that the high-privilege account can, including creating, modifying, and deleting critical resources within the cluster.

PoC

We have discussed in the “Details” section

Impact

Privilege escalation

References

• GHSA-h27c-6xm3-mcqp
• https://github.com/kanisterio/kanister/blob/master/helm/kanister-operator/templates/rbac.yaml#L49
• https://github.com/kanisterio/kanister/wiki/2023%E2%80%9024-Community-Meeting-Notes