移花接木：看CVE-2020-8559如何逆袭获取集群权限

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序把安全装进口袋

移花接木：看CVE-2020-8559如何逆袭获取集群权限

2021-11-11 13:41:28

所属地北京

专题：云原生攻防标签：云原生安全云原生攻防 Kubernetes

摘要：CVE-2020-8559是一个针对Kubernetes的权限提升漏洞，本文将对该漏洞进行分析并进行漏洞复现，最后给出修复建议与总结思考。

简介

CVE-2020-8559是一个针对Kubernetes的权限提升漏洞，攻击者可以截取某些发送至节点kubelet的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点的权限提升，CVSS 3.x评分为6.8[1]。版本在v1.6-v1.15之间以及v1.16.13、v1.17.9和v1.18.6之前的版本均受影响。该漏洞由Tim Allclair提交[2]。

目前网上暂无针对该漏洞的详实资料，但笔者在探寻针对Kubernetes的渗透路线时，发现通过该漏洞可以直接获取集群的控制权限，它的危害可能由于评分不高的缘故被大大低估。因此希望通过此篇文章，让大家了解它的危害并感受其利用过程。以上简单的漏洞说明可能难以理解，下面笔者将给出理解该漏洞所需的背景知识，然后对漏洞进行分析、复现，最后给出相关修复建议以及总结与思考。

背景知识

图1[3]

API Server

API Server提供了Kubernetes各类资源对象(Pod，RC, Service等)的增删改查及watch等HTTP REST API接口，成为集群中各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。除此之外，它还具有代理转发的功能，将外界对于部分API的调用转发到后端实际执行这些API功能的组件上。例如，常用的对Pod执行exec的操作，就是API Server作为代理，将请求转发到了对应节点的kubelet上，由该kubelet执行具体命令。

kubelet

Kubelet 是 Kubernetes 工作节点上的一个代理组件，运行在每个节点上。它定期从API Server组件接收新的或修改的Pod规范，并确保Pod及其容器在期望规范下运行。同时该组件作为工作节点的监控组件，向API Server汇报主机的运行状况。

漏洞分析

该漏洞是由于Kubernetes API Server和kubelet的请求遵循HTTP重定向，当kubelet进程响应/exec、/attach、/portforward等动作时附带了HTTP 302重定向和Location头，Kubernetes API Server或Kubectl命令将会使用原始请求的凭证，为Location头中的任何内容提出新请求。图2可以帮助我们更好地理解：

图2

正常情况下，当Node节点上的Pod被执行/exec、/attach等操作时，会经历图2中①②③的步骤。

图3

如图3所示，在实际利用CVE-2020-8559的过程中，当攻击者获取了Node节点的root权限时，可以通过修改kubelet拦截来自API Server转发的请求，然后在其中加入恶意的302请求，kubelet在向API Server返回/exec等动作执行的结果时会发起新的请求，新的请求会沿用原始请求的凭证，走向图3中④⑤⑥的流程，kubelet在接收到API Server转发过来的请求之后便会直接执行，即使该kubelet在Master节点，如此便可通过API Server转发的方式控制集群，达到权限提升的效果。话不多说，下面我们将通过实践来感受整个利用链的效果。

漏洞复现

环境准备

场景涉及Master和Node节点的搭建，为了方便，我们借助开源靶场工具Metarget[4]来部署漏洞环境。在即将作为Master节点的主机上下载Metarget，然后执行以下命令：

./metarget cnv install cve-2020-8559 --domestic --verbose

安装完成之后会在metarget/tools/目录下生成install_k8s_worker.sh文件，将该文件复制到作为Node节点的主机上（与Master节点网络可连通），然后执行 bash install_k8s_worker.sh，即可完成Master节点和Node节点的部署：

图4

然后在Master节点上安装一个正常运行的pod：./metarget cnv install no-vuln-ubuntu

图5

图6

因为Kubernetes集群的机制，该pod会自动运行在Node节点上。

漏洞利用

假设我们通过一定手段已经获取了Node节点的root权限，为了拦截对kubelet的某些请求，我们需要替换Node节点上的kubelet(以下漏洞利用手段参考github[5])。

步骤一——厉兵秣马

本次搭建的环境中Kubernetes版本为v1.17.1，因此先下载相同版本的Kubernetes源码：

git clone --branch v1.17.1 --single-branch https://github.com/kubernetes/kubernetes.git

编辑kubernetes/pkg/kubelet/server/server.go文件中的ServeHTTP()函数，如下所示：

注意其中修改的内容：

（本次漏洞利用的目标为获取Master节点上API Server的ca.crt凭证）

host为Master节点IP和API server运行的端口

namespace、pod、container 根据Master节点运行的pod具体情况填写

command字段为执行的命令，此处的利用场景为读取API Server的相关凭证文件，需要执行的命令应为cat /etc/kubernetes/pki/ca.crt，但此条命令涉及参数，因此在构造API请求时需要通过command拼接的形式。

编辑完成之后保存并退出，运行以下命令进行编译：

cd kubernetes/ （kubernetes源码根目录）

GO111MODULE=on go mod download （golang版本要求支持mod参数.）

cd kubernetes/cmd/kubelet

go build

步骤二——移花接木

将编译好的kubelet上传至Node节点，找到正在运行的kubelet进程：ps aux | grep kubelet

将原kubelet进程结束：kill $pid

备份原kubelet文件（备份是个好习惯）：cp /usr/bin/kubelet /usr/bin/kubelet.bak

覆盖原kubelet文件：cp -f kubernetes/cmd/kubelet/kubelet /usr/bin/kubelet

确认kubelet是否重启（kubelet会自动重启，可多次重复kill操作，确认启动时间为最新）：ps aux | grep kubelet

步骤三——直捣黄龙

在Master节点上执行以下命令：

kubectl exec no-vuln-ubuntu -n metarget -- hostname

当向位于Node节点上的pod执行exec操作时，按照图3的流程，API Server会将该请求转发给Node节点上的kubelet执行，此时Node节点上的kubelet已经被我们替换，/exec的请求触发了我们新增的302重定向请求，导致Node节点的kubelet向API server发起了我们构造的恶意请求，并且沿用了原始请求的凭证（因为该请求是从API server转发过来的，所以认证已经通过），最终成功读取了/etc/kubernetes/pki/ca.crt文件。同理，我们可以读取其他敏感凭证，以此来获取到API Server的控制权。

图7

注意事项

通过以上利用过程可以发现，此漏洞的利用需要满足两个条件：

获取到Node节点的root权限，因此可以替换kubelet
拥有运行在Node节点上任意个pod的exec、attach、portforward等权限

漏洞修复

查看CVE-2020-8559的补丁[6]，部分代码如图8、图9所示：

图8

图9

可以30x等重定向请求做处理，建立了一个后端用来处理升级请求，禁止了将重定向请求返回给客户端执行，即阻止了图3中步骤④。

为了防范此漏洞的利用，除更新补丁之外，在集群部署时也应遵循权限最小化原则，使得Node节点的root权限难以获取，pod的相关权限也尽可能收敛，阻碍攻击者漏洞利用链的形成。

同时，为了监控此漏洞的利用，可以通过审计Kubernetes日志，当以下资源模型请求的响应代码在300-399之间，很有可能存在相关漏洞利用行为：

pods/exec
pods/attach
pods/portforward
任何资源的（如pods/proxy、services/proxy）

总结与思考

CVE-2020-8559是为数不多的针对Kubernetes集群的权限提升漏洞，和CVSS3.x评分9.8的CVE-2018-1002105[7]相同之处在于，两者都是API Server与kubelet之间处理请求的问题。不同的是，当Kubernetes开启认证机制时，利用CVE-2018-1002105需要掌握某个pod的token凭证，便于通过API Server的认证和kubelet建立通道，且当通道建立时，该kubelet只能对所在节点的pod执行命令，只有当所在节点为Master节点时，才能控制API Server，真正实现控制集群的效果。而在实际环境中，Master节点一般不会部署业务pod，仅运行一些核心组件，如kube-apiserver,etcd等，所以攻击者利用的pod很有可能并不在Master节点，因此CVE-2018-1002105的危害性有限。而CVE-2020-8559虽然评分相对较低，但当攻击者通过容器逃逸到宿主机环境时，一般为主机的root权限，已满足利用条件之一，若当前权限不满足条件二，只能像前文描述的过程那样等待集群管理员在Master上对Node节点的pod执行exec/attach等操作；若当前权限满足条件二，则可以优于CVE-2018-1002105，在Node节点上跨节点实现对集群的真正控制。同时随着近年来云原生漏洞的增多，容器逃逸的手段也变得丰富起来，从容器环境逃逸到宿主机环境的可能性变得更高，利用CVE-2020-8559的可能性也随之提高，依此来看，CVE-2020-8559在对集群的危害方面完成了逆袭。

希望读者能通过此文章理解该漏洞的危害，作为集群管理人员，应培养及时更新补丁的好习惯；作为云安全从业者，也应认真考虑如何检测并阻断漏洞利用行为，共同建设安全的云原生环境。

最后，由绿盟科技星云实验室编写的《云原生安全：攻防实践与体系构建》一书已上线京东自营，本书从容器基础设施、编排系统和微服务多层面完整地讲解了云原生的风险、攻防和安全架构，干货多多，欢迎大家购买阅读并参与讨论！