因全文整体内容较长,将文章拆分为多篇在本公众号发出,欢迎大家关注~
往期内容阅读:
九维团队-红队(突破)| 云安全-Docker逃逸手法(上)
九维团队-红队(突破)| 云安全-Docker逃逸手法(中)
4.3 逃逸方法三:Docker CP缺陷 CVE-2019-14271
漏洞描述:
当Docker宿主机需要从容器内复制文件到宿主机时,使用cp命令,会调用辅助进程docker-tar,但该进程没有被容器化,docker-tar不受cgroup或seccomp的限制,且会在运行时动态加载一些libnss.so库。黑客可以通过在容器中替换libnss.so等库,将代码注入到docker-tar中。
当Docker用户尝试从容器中拷贝文件时将会执行恶意代码,成功实现Docker逃逸,获得宿主机root权限。(高权限进程自身未容器化,却加载了不可控的动态链接库,通过修改容器内动态链接库来实现在宿主机上以root权限执行任意代码。)
在这两种情况下,攻击者就可以宿主机上的root代码执行权限。
-
容器运行含有恶意libnss_*.so库的镜像;
-
容器中含有被攻击者替换的libnss_*.so库。
部分细节说明:
当执行CP,从容器内复制文件到宿主机,docker-tar原理:docker cp命令在容器中打包和解包文件时,分别会调用docker-tar和docker-untar命令。为了防止这两个命令的写操作影响到宿主机,在执行具体操作前,进行了chroot。
根据文章《docker-tar,docker-untar源码分析》中介绍,这些函数是不受capbility,seccomp和LSM的限制的。会切换进程的根目录(执行chroot)到容器根目录,然后将需要复制的文件或目录打tar包传递给Docker daemon,Docker daemon负责将内容解包到用户指定的宿主机目标路径。
《docker-tar,docker-untar源码分析》原文链接:
https://ssst0n3.github.io/post/%E7%BD%91%E7%BB%9C%E5%AE%89%E5%85%A8/%E5%AE%89%E5%85%A8%E7%A0%94%E7%A9%B6/%E5%AE%B9%E5%99%A8%E5%AE%89%E5%85%A8/%E8%BF%9B%E7%A8%8B%E5%AE%B9%E5%99%A8/%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%AE%B9%E5%99%A8/docker/docker%E6%BA%90%E7%A0%81%E5%AE%A1%E8%AE%A1/docker%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90/docker-tardocker-untar%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90.html
*左右滑动查看更多
影响版本:
官方说是只有Docker 19.03.0,19.03.1以上以及18.09以下都不受影响。但实际18.09.9<=docker<19.03.8。
静态编译
-
不受影响
非静态编译
-
19.03.0 <= docker < 19.03.1 受影响
-
docker=18.09.9, 19.03.1 <= docker < 19.03.8 有条件受影响(在宿主机加载nsswitch共享库失败)
-
18.09.0 <= docker < 18.09.8 不受影响
docker=18.09.9, 19.03.1 <= docker < 19.03.8 有条件受影响。
* ubuntu18.04-docker19.03.5 [https://github.com/moby/moby/issues/39449# issuecomment-570729463](https://github.com/moby/moby/issues/39449# issuecomment-570729463)
* debian9.11-docker19.03.5 [https://github.com/moby/moby/issues/39449# issuecomment-572993986](https://github.com/moby/moby/issues/39449# issuecomment-572993986)
* docker19.03.5 [https://github.com/moby/moby/issues/39449# issuecomment-573635439](https://github.com/moby/moby/issues/39449# issuecomment-573635439)
* ubuntu16.04amd64-docker19.03.6 [https://github.com/moby/moby/issues/39449# issuecomment-587187043](https://github.com/moby/moby/issues/39449# issuecomment-587187043)
* Ubuntu16.04.4amd64-dockerce19.03.4 [https://github.com/moby/moby/issues/40211](https://github.com/moby/moby/issues/40211)
* Ubuntu16.04.6-docker19.03.5 [https://github.com/moby/moby/issues/40211# issuecomment-562973937](https://github.com/moby/moby/issues/40211# issuecomment-562973937)
* Ubuntu18.04.5-docker19.03.6 [https://github.com/moby/moby/pull/39612# issuecomment-848854698](https://github.com/moby/moby/pull/39612# issuecomment-848854698)
*左右滑动查看更多
漏洞利用:
虽然危害挺大,但因为这种逃逸在实际利用中的效果不大,需要特定场景才会触发逃逸效果—宿主机执行了cp复制目录,就不进行详细截图了,简单了解以下利用流程即可。
利用思路:
1、找出docker-tar具体会加载哪些容器内的动态链接库;
2、下载对应动态链接库源码,为其增加一个__attribute__((constructor))属性的函数run_at_link(该属性意味着在动态链接库被进程加载时,run_at_link函数会首先被执行),在run_at_link函数中放置我们希望docker-tar执行的攻击载荷(payload);编译生成动态链接文件;
3、编写辅助脚本”/breakout“,将辅助脚本和步骤二生成的恶意动态链接库放入恶意容器,等待用户执行docker cp命令,触发漏洞。
利用参考:
https://ssst0n3.github.io/post/网络安全/安全研究/容器安全/进程容器/服务器容器/docker/历史漏洞分析与复现/docker-software/plumbing/docker-cp/CVE-2019-14271/分析/CVE-2019-14271分析与复现.html
参考:
https://blog.csdn.net/qq_41667409/article/details/121557358
*左右滑动查看更多
4.4 其他一些不太常用的逃逸的方法
1、Docker Build时的命令注入漏洞(CVE-2019-13139)
漏洞描述 :
攻击者能够提供或操纵“docker build”命令的构建路径将能够获得命令执行。“docker build”处理远程 git URL 的方式存在问题,并导致命令注入到底层“git clone”命令中,导致代码在用户执行“docker build”命令的上下文中执行。
漏洞影响版本:
Docker 18.09.4之前的版本。
攻击流程:
可参照:
https://staaldraad.github.io/post/2019-07-16-cve-2019-13139-docker-build/
*左右滑动查看更多
2、Shocker攻击
漏洞描述:
从Docker容器逃逸并读取到主机某个目录的文件内容。Shocker攻击的关键是执行了系统调用open_by_handle_at函数,Linux手册中特别提到调用open_by_handle_at函数需要具备CAP_DAC_READ_SEARCH能力,而Docker1.0版本对Capability使用黑名单管理策略,并且没有限制CAP_DAC_READ_SEARCH能力,因而引发了容器逃逸的风险。
漏洞影响版本:
Docker版本 1.0, 存在于 Docker 1.0 之前的绝大多数版本(目前基本上不会存在了) 。
POC:
https://github.com/gabrtv/shocker
五、安全加固建议
根据前文所述的风险点,可以考虑主要在以下几方面进行安全加固:
一、保证镜像的安全
1)做到最小安装原则,选择来自可信源的官方或已经验证的最小化基础镜像(没有构建历史不下载),并只安装运行所需的最小依赖。对镜像签名子进行验证。
2)使用前,对镜像进行安全漏洞扫描、基线风险排查。删除镜像中遗留的 setuid 和 setgid 权限(suid、sgid)。
3)检查是否开了2375/2376docker管理端口,避免存在未授权访问漏洞,做好身份认证。设置ACL,只允许信任的IP端口连接对应端口。
二、保证容器的安全
1)做好容器权限限制,使用非ROOT用户启用服务,不建议以privileged(特权模式)启动Docker,通过capabilities机制进行定制化的权限分级。
2)做好容器间的网络访问边界隔离,宿主机下的docker容器之间默认网络互通,通过使用`-icc = false`参数禁止容器与容器间的通信,也可以通过`docker network create <network-name>` 新建网络来实现网络隔离。关于docker和宿主机通信的端口加上证书认证和加密。
3)做好容器资源隔离与限制,限制docker容器的网络带宽、磁盘I/O、cpu利用,例如配置 -memory参数来防止一个容器消耗所有主机资源的拒绝服务攻击。
三、Docker的历史遗留安全问题
1)更新Docker版本到19.03.1及更高版本——CVE-2019-14271、覆盖CVE-2019-5736。
2)检查runc版本是否升级到 1.0-rc6以上。
四、定期检查
定期检查服务器版本,打补丁包升级系统内核,避免服务器内核漏洞逃逸。
六、小结:
细致调节以获得最大的安全性
过了一遍docker逃逸的风险点,发现其实能够导致容器逃逸的手法还是非常多的(同时文中列举的漏洞也只是一部分,还有一些冷门洞)。在目前云安全的大环境下,Docker逃逸的风险所带来的问题还是非常大的。
个人觉得两个地方影响还是非常明显的。一方面是内核漏洞的直接逃逸,另一方面就是因为配置导致的逃逸——”错误配置可能远比安全漏洞更容易存在”。
参考资料及推荐阅读:
CVE-2019-5736 runc容器逃逸漏洞分析
https://x3fwy.bitcron.com/post/runc-malicious-container-escape
渗透测试之Docker逃逸
https://xz.aliyun.com/t/8558# toc-0
『杂项』Docker 逃逸方法汇总
https://mp.weixin.qq.com/s/FeOsaMgTMI0AwN7UzTjxAg
脏牛漏洞-Docker逃逸POC(dirtycow-vdso)代码分析
https://blog.csdn.net/enjoy5512/article/details/53196047
【云原生渗透】- containerd-shim容器逃逸漏洞(CVE-2020-15257)
https://zhuanlan.zhihu.com/p/471532280
host模式容器逃逸漏洞(CVE-2020-15257)技术分析
https://mp.weixin.qq.com/s/WmSaLPnG4o4Co1xRiYCOnQ
CVE-2019-14271分析与复现
https://ssst0n3.github.io/post/网络安全/安全研究/容器安全/进程容器/服务器容器/docker/历史漏洞分析与复现/docker-software/plumbing/docker-cp/CVE-2019-14271/分析/CVE-2019-14271分析与复现.html
CVE-2019-5736 runc容器逃逸漏洞分析
https://x3fwy.bitcron.com/post/runc-malicious-container-escape
Docker SYS_ADMIN 容器逃逸原理解析
https://www.freebuf.com/vuls/264843.html
Docker安全性与攻击面分析
https://zhuanlan.zhihu.com/p/152052618
原文始发于微信公众号(安恒信息安全服务):九维团队-红队(突破)| 云安全-Docker逃逸手法(下)
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论