一道二次Docker逃逸题目详解#

1
docker pull docker:dind && docker save docker:dind -o docker-dind.tar
2
docker pull ubuntu:latest && docker save ubuntu:latest -o inception/ubuntu.tar
3
cd inception/internal && docker build -t internal-inception:latest . && cd ../..
4
docker save internal-inception:latest -o inception/internal-inception.tar

原理介绍#

1. 常见docker逃逸方式有：

• 内核漏洞利用：容器与宿主机共享内核，如果宿主机存在未修复的内核漏洞，攻击者可借此突破隔离。如Dirty COW（CVE-2016-5195），利用写时复制漏洞注入 Shellcode反弹宿主机Shell；以及CVE-2019-5736，通过覆盖宿主机runc二进制文件，在管理员执行docker exec时触发恶意代码，直接获取宿主机Root权限。
• 配置不当导致逃逸：这类逃逸源于不安全的容器配置，核心在于获得对宿主机Docker守护进程的直接控制权。常见包括：
  • Docker Remote API未授权暴露（攻击者可远程调用API创建挂载宿主机目录的恶意容器，通过写入计划任务或SSH公钥获取权限）；
  • 以—privileged特权模式启动的容器可访问所有宿主机设备，直接挂载并操作宿主机磁盘；
  • 挂载Docker Socket（/var/run/docker.sock）则让容器内获得了完整的 Docker CLI 控制权，同样可以通过创建新容器来挂载宿主机根目录完成逃逸。
• 不安全挂载逃逸（挂载宿主机敏感目录后利用内核机制或直接访问实现逃逸）如：
  • 挂载宿主机 /proc：修改 core_pattern 文件，在进程崩溃时触发宿主机执行恶意脚本。
  • 挂载宿主机根目录或 /dev：通过 chroot 切换根目录，或直接挂载宿主机磁盘分区读写任意文件。
• Capabilities 与权限滥用：容器虽未启用完整特权模式，但被授予危险 Linux Capabilities。
  • CAP_SYS_ADMIN：可挂载宿主机文件系统、加载内核模块，利用方式接近特权模式。
  • CAP_SYS_PTRACE + 共享 PID 命名空间：可向宿主机进程注入 Shellcode，实现横向提权。

解题过程#

1. 根据提示访问网页，页面提供了创建容器功能。
2. 创建后多等待几分钟后再进行ssh连接，下面是连接密码。
3. 连接上容器后进行信息收集，发现docker.sock挂载。
4. 用cat /proc/self/status | grep CapEff查看当前进程的有效Capabilities掩码值。
5. 执行ps aux，看到大量宿主机的进程，说明容器未做PID命名空间隔离。
6. 利用挂载的 docker.sock，在容器内执行docker exec -it <PID> /bin/bash，成功进入另一个正在运行的容器。
7. 对父容器进行信息收集，发现其CapEff拥有特权，且容器内可以执行docker命令（挂载docker.sock）。
8. 利用父容器的特权，执行docker run -it --privileged --pid=host --net=host -v /:/host ubuntu:latest bash启动新的特权容器，包含特权模式和宿主机根目录挂载点，在新容器内使用chroot /host /bin/bash尝试 chroot到宿主机根目录，搜寻一波拿到flag。

其它补充与收获总结#

1. 原理部分参考https://cloud.tencent.com/developer/article/2434574。
2. docker逃逸排查思路：

• uname -r看宿主机内核版本，是否有满足逃逸的内核漏洞。
• 扫 2375/2376 端口是否开放，有则直接远程调API创建挂载宿主机目录的容器。
• 看有没有/var/run/docker.sock挂载，有则在容器内装docker客户端控制宿主机。
• 查是否—privileged启动，有则直接挂载宿主机磁盘。
• mount或df看有没有/proc、/、/dev等宿主机目录挂进来，有则改core_pattern或chroot逃逸。
• cat /proc/self/status | grep CapEff看有没有CAP_SYS_ADMIN等高危权限，有则尝试挂载宿主机文件系统。
• 看是否共享了宿主机PID命名空间，有CAP_SYS_PTRACE就注入宿主机进程。

3. /var/run/docker.sock是Docker守护进程的Unix域套接字文件，用于接收Docker CLI和Docker API的请求。容器内如果挂载了这个文件，本质上就等于获得了宿主机Docker的完整控制权。
4. Linux Capabilities将 root 的完整权限拆分为多个细粒度的能力单元（如 CAP_SYS_ADMIN、CAP_SYS_PTRACE 等），/proc/self/status中的 CapEff 字段以十六进制掩码形式显示当前进程实际生效的所有Capabilities，通过对比掩码值，可以初步判断容器是否被授予了高危权限。