A potential risk in spiderpool that could lead to takeover of the cluster

[HouqiyuA]

What would you like to be added?

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:

In this Kubernetes project, there exists a ClusterRole that has been granted list secrets high-risk permissions. These permissions allow the role to list confidential information across the cluster. An attacker could impersonate the ServiceAccount bound to this ClusterRole and use its high-risk permissions to list secrets information across the cluster. By combining the permissions of other roles, an attacker can 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

Why is this needed?

None

How to implement it (if possible)?

None

Additional context

None

[cyclinder]

Hi @HouqiyuA, thanks for the report!

Currently, spiderpool's RBAC permissions are configured in a minimal privilege design, in other words, it does not have full control over the cluster, it only has the permissions needed by the spiderpool components to access cluster resources. If an attacker steals our token, they shouldn't be able to take over the cluster completely, right?

In response to your method 1, I would say: "It's ok but not good". We don't want to gain full control of the cluster.

For method 2:

Sorry, I'm unfamiliar with this, Could you provide an example? thanks. this should be the case for most of the kubernetes projects in the community today (e.g. calico, cilium), and they should all have the same risks. I'm curious as to how they handle this.

[HouqiyuA]

I think the attacker stole the token for the spiderpool component and they can take over the cluster completely. The details: First I installed SpiderPool according to the official documentation of this project https://spidernet-io.github.io/spiderpool/v0.9/ and found that there is a clusterRole named spiderpool-admin in this project and that spiderpool- admin has been given access to `[get list watch]` `*. * `, which would mean that he would be able to perform `[get list watch]` operations on all resources in the cluster. I believe this granting this privilege is excessive and does not follow the principle of least privilege, and it is a potential vulnerability. [image: 0977ad57b0ad8214e54e8609f0a6b1d.png] I found that spiderpool-admin is bound to three ServiceAccount. [image: image-20240416135008540.png] So I stole the token of spiderpool-controller and utilized the poc https://github.com/HouqiyuA/k8s-rbac-poc that I developed to steal the token of the entire cluster, achieving a cluster-level privilege elevation that allows control of the entire cluster. [image: 1ae2775b-807e-4083-9a62-6a4bbda17779.png] [image: image-20240416140226782.png] Cyclinder ***@***.***> 于2024年4月16日周二 11:41写道：

…

Hi @HouqiyuA <https://github.com/HouqiyuA>, thanks for the report! Currently, spiderpool's RBAC permissions are configured in a minimal privilege design, in other words, it does not have full control over the cluster, it only has the permissions needed by the spiderpool components to access cluster resources. If an attacker steals our token, they shouldn't be able to take over the cluster completely, right? In response to your method 1, I would say: "It's ok but not good". We don't want to gain full control of the cluster. For method 2: Sorry, I'm unfamiliar with this, Could you provide an example? thanks. this should be the case for most of the kubernetes projects in the community today (e.g. calico, cilium), and they should all have the same risks. I'm curious as to how they handle this. — Reply to this email directly, view it on GitHub <#3361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBBY3LSK24VFWJ2XCRM7JBLY5SMV3AVCNFSM6AAAAABGHU67C2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJYGE3TEMRWGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cyclinder]

oh, you are right, I just noticed the spiderpool-admin has configured apiGroups: [*], this is unexpected. thanks for the catch!

we should remove this, Are you able to send a PR for this if you are interested in this?

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    meta.helm.sh/release-name: spiderpool
    meta.helm.sh/release-namespace: kube-system
  creationTimestamp: "2024-04-16T03:03:03Z"
  labels:
    app.kubernetes.io/managed-by: Helm
  name: spiderpool-admin
  resourceVersion: "1630"
  uid: 9802fdef-d582-40ca-96be-5fab2e5cbf1f
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - namespaces
  - nodes
  - pods
  - pods/status
  verbs:
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch

[HouqiyuA]

Yes, can you give me a cve? Cyclinder ***@***.***> 于2024年4月16日周二 15:48写道：

…

oh, you are right, I just noticed the spiderpool-admin has configured apiGroups: [*], this is unexpected. thanks for the catch! we should remove this, Are you able to send a PR for this if you are interested in this? apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: annotations: meta.helm.sh/release-name: spiderpool meta.helm.sh/release-namespace: kube-system creationTimestamp: "2024-04-16T03:03:03Z" labels: app.kubernetes.io/managed-by: Helm name: spiderpool-admin resourceVersion: "1630" uid: 9802fdef-d582-40ca-96be-5fab2e5cbf1f rules: - apiGroups: - "" resources: - configmaps - endpoints - namespaces - nodes - pods - pods/status verbs: - delete - deletecollection - get - list - patch - update - watch - apiGroups: - "" resources: - events verbs: - create - delete - get - list - patch - update - watch - apiGroups: - '*' resources: - '*' verbs: - get - list - watch — Reply to this email directly, view it on GitHub <#3361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBBY3LSSOMYROYQAQYZQXBTY5TJUHAVCNFSM6AAAAABGHU67C2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJYGQ2TIMBYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cyclinder]

can you give me a cve?

sorry, I can't understand this, what does your exact mean?

[HouqiyuA]

I'm sorry, maybe I didn't express what I meant. As a result of our team's efforts, we have discovered a vulnerability in your project that has been reported to you and approved by you! As a reward, we would like you to assign us a CVE ID for this vulnerability. A CVE ID helps the global security community and users better understand the severity of a vulnerability and the risks associated with it. It provides a unique identifier for the vulnerability, allowing it to be accurately documented and tracked in various security databases and tools. You can submit an application for a vulnerability to the CVE organization. We can provide the necessary support and assistance to ensure a smooth application process.

…

Message ID: ***@***.***>

[HouqiyuA]

oh, you are right, I just noticed the spiderpool-admin has configured apiGroups: [*], this is unexpected. thanks for the catch!

we should remove this, Are you able to send a PR for this if you are interested in this?

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    meta.helm.sh/release-name: spiderpool
    meta.helm.sh/release-namespace: kube-system
  creationTimestamp: "2024-04-16T03:03:03Z"
  labels:
    app.kubernetes.io/managed-by: Helm
  name: spiderpool-admin
  resourceVersion: "1630"
  uid: 9802fdef-d582-40ca-96be-5fab2e5cbf1f
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - namespaces
  - nodes
  - pods
  - pods/status
  verbs:
  - delete
  - deletecollection
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - get
  - list
  - watch

Has the issue been fixed? Can we be assigned a CVE number after fixing this issue?

[cyclinder]

Hi @HouqiyuA, Sorry for the slow response. The issue hasn't been fixed, Are you interested in fixing this? If not, I will send a PR for this. Thanks!

[HouqiyuA]

ok! I will send a PR to fix this problem soon, Can spiderteam reward our team after fixiing this problem? For example, apply for a CVE ID to our team for this problem? Thanks! Cyclinder ***@***.***> 于2024年4月30日周二 10:22写道：

…

Hi @HouqiyuA <https://github.com/HouqiyuA>, Sorry for the slow response. The issue hasn't been fixed, Are you interested in fixing this? If not, I will send a PR for this. Thanks! — Reply to this email directly, view it on GitHub <#3361 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BBBY3LRIM2GRJD2ECUWSOOLY7357FAVCNFSM6AAAAABGHU67C2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOBUGIYDOMRXGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>