A potential risk in hwameistor that could lead to takeover the cluster

[HouqiyuA]

Dear Team Members:

Greetings! Our team is very interested in your project and we recently identified a potential RBAC security risk while doing a security assessment of your project. Therefore, we would like to report it to you and provide you with the relevant details so that you can fix and improve it accordingly. I couldn't find a private email to report security risks, so I raised this issue. If there is anything inappropriate about it, I hope you can forgive me.
Details:

I found that the project has a cluster role named hwameistor-role and that hwameistor-role has been granted [*] *.(https://github.com/hwameistor/hwameistor/blob/main/helm/hwameistor/templates/clusterrole.yaml) This means that he can perform any operations on all resources in the cluster. I believe that granting such privileges is excessive, does not comply with the principle of least privilege, and is a potential vulnerability. An attacker could impersonate the service account bound to this ClusterRole and use its high-risk privileges to list confidential information across the cluster. By combining the permissions of other roles, an attacker could elevate the privileges and further take over the entire cluster.

we constructed the following attack vectors.

First, you need to get a token for the ServiceAccount that has this high-risk privilege. If you are already in a Pod and have this override, you can directly run the following command to get the token: cat /var/run/secrets/[kubernetes.io/serviceaccount/](http://kubernetes.io/serviceaccount/) token. If you are on a node other than a Pod, you can run the following command to get the kubectl describe secret .

Use the obtained token information to authenticate with the API server. By including the token in the request, you can be recognized as a legitimate user with a ServiceAccount and gain all privileges associated with the ServiceAccount. As a result, this ServiceAccount identity can be used to list all secrets in the cluster.

We give two ways to further utilize ServiceAccount Token with other privileges to take over the cluster:

Method 1: Elevation of Privilege by Utilizing ServiceAccount Token Bound to ClusterAdmin

Directly use a Token with the ClusterAdmin role permissions that has the authority to control the entire cluster. By authenticating with this token, you can gain full control of the cluster.

Method 2: Create Privileged Containers with ServiceAccount Token with create pods permission You can use this ServiceAccount Token to create a privileged container that mounts the root directory and schedules it to the master node in a taint-tolerant way, so that you can access and leak the master node's kubeconfig configuration file. In this way you can take over the entire cluster.

For the above attack chain we have developed exploit code and uploaded it to github: https://github.com/HouqiyuA/k8s-rbac-poc
Mitigation methods are explored:

Carefully evaluate the permissions required for each user or service account to ensure that it is following the principle of least privilege and to avoid over-authorization.

If list secrets is a required permission, consider using more granular RBAC rules. Role Binding can be used to grant list secrets permissions instead of ClusterRole, which restricts permissions to specific namespaces or resources rather than the entire cluster.

Isolate different applications into different namespaces and use namespace-level RBAC rules to restrict access. This reduces the risk of privilege leakage across namespaces

Looking forward to hearing from you and discussing this risk in more detail with us, thank you very much for your time and attention.

Best wishes.

HouqiyuA

[SSmallMonster]

@HouqiyuA Thanks for your feedback.

Indeed, this account could cause some issues. We will refine the granularity of the permission control in this part.

May I ask, how did you discover this problem? Was it by conducting batch scanning through scripts, or is it because you have some requirements for this project and are currently using it?

[HouqiyuA]

Yes！Our team designed and developed the corresponding tools. Recently,we conducted RBAC authorization evaluations for projects in the cncf open source community and reported these issues to them. By the way,Can hwameistor team reward our team after fixiing this problem? For example, apply for a CVE ID to our team for this problem or other ways? mingming.zhou ***@***.***> 于2024年4月29日周一 16:09写道：

…

@HouqiyuA <https://github.com/HouqiyuA> Thanks for your feedback. Indeed, this account could cause some issues. We will refine the granularity of the permission control in this part. May I ask, how did you discover this problem? Was it by conducting batch scanning through scripts, or is it because you have some requirements for this project and are currently using it? — Reply to this email directly, view it on GitHub <#1460 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBBY3LVBC6JL2JYXCVPR3I3Y7X52BAVCNFSM6AAAAABG52HFRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBSGEYTKMZSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>