【报告解读系列一】容器镜像的脆弱性分析

容器镜像是容器环境的重要组成部分,作为整个容器生命周期的源头,其安全性应引起用户的广泛关注。本文针对Docker镜像,对其进行深入的脆弱性分析。

1.容器镜像概述

镜像是容器运行的基础,容器服务引擎可以使用不同的镜像启动相应的容器实例。在容器实例出现异常后,能迅速通过删除实例、启动新的容器实例来恢复服务,这些灵活、敏捷的操作,均需要以容器镜像作为支撑技术。

与虚拟机所用的系统镜像不同,容器镜像不仅没有Linux系统内核,同时在格式上也有很大的区别。虚拟机镜像是将一个完整的操作系统封装成一个镜像文件,而容器镜像不是一个文件,是分层存储的文件系统。

图1 容器镜像结构

上图是Docker镜像分层存储的示意图,从图中可以看出,每个镜像都是由一系列的“镜像层”组成。当需要修改镜像内的某个文件时,只会对最上方的读写层进行改动,不会覆盖下层已有文件系统的内容。当提交这个修改生成新的镜像时,保存的内容仅为最上层可读写文件系统中被更新过的文件,这样就实现了在不同的容器镜像间共享镜像层的效果。

容器镜像通常会通过镜像仓库(Registry)进行存储和管理。根据Registry服务的提供者、镜像存储位置、访问控制等因素,可以将其分为公共仓库和私有仓库。

因此,对于镜像的来源,无非就是这两种渠道:或者是通过公共的镜像仓库获取,比如Docker官方的Docker Hub、或者是国内的网易163、中科大(USTC)、daocloud、阿里云等;或者是用户自己维护一个私有仓库,比如采用Harbor,团队所有成员将相关的镜像上传至私有仓库,供其他成员使用。

对于开发者来说,公共仓库获取镜像的便利性,使其成为很多开发者获取镜像的重要途径。从Docker Hub显示的数字来看,Nginx、Redis、Tomcat等常用应用的镜像下载量,均在千万以上的数量级。中国信通院2018年3月份发布的《开源治理白皮书》[1]中提到,截至2014年底,容器镜像下载量高达1亿,到2017年初,这一数量超过80亿。

2.开源软件风险分析

提及容器镜像,不得不提的就是开源软件,根据Gartner的调查显示,99%的组织在其IT系统中使用了开源软件,同时开源软件在服务器操作系统、云计算、Web等领域都有比较广泛的应用。而从Docker Hub中可以看到,几乎所有常用的开源软件,均可以在公共仓库中找到相应的Docker镜像,比如TensorFlow、Kafka、Pytorch、Zepplin等。

图2 Docker Hub中的TensorFlow镜像检索

回到安全的角度来看,容器镜像作为开源软件使用的一个载体,要解决容器镜像的安全问题,那么开源软件所面临的安全风险,是必然要考虑的一个问题。

比如:(1)确认已经解决已知的安全漏洞(包括自研代码和引用的第三方代码),如软件注入漏洞等。如仍然存在显著漏洞,应予以修补,避免开放被使用后影响公众安全;(2)确认开源代码和文档中是否存在泄漏用户隐私和商业秘密的情况;(3)确认是否泄漏了秘钥、账号、密码、测试IP地址、端口、测试用例等敏感信息;(4)确认是否包含挖矿程序、后门程序、病毒、木马等恶意代码。

开源软件存在的安全问题中,安全漏洞是一个重要的问题,根据NVD数据统计,截至2017年2月,全球开源软件相关的已知安全漏洞已超过28000个。截至2017年2月,美国国土安全部累计检测各种开源软件7000多个,发现大量安全缺陷。系统信息泄露、密码管理、资源注入、跨站请求伪造、跨站脚本、HTTP消息头注入、SQL注入、跨界访问、命令注入、内存泄露等是开源软件主要的安全风险。

图3 开源软件项目缺陷总数

开源软件带来的安全风险[2],近年来频繁的被揭露出来。例如,2017年,Equifax指责开源Apache Struts被用于网络攻击,导致了1.43亿条记录的泄露。同一年,Black Duck Software的研究人员通过对企业中1,000种常用应用程序的审计发现,96%的企业使用开源软件,60%以上包含由于这些组件造成的安全漏洞。一些被发现的漏洞已存在超过了四年之久。

2017年11月,Uber发布声明,承认2016年曾遭黑客攻击并导致数据大规模泄露。根据这份声明,两名黑客通过第三方云服务对Uber实施了攻击,获取了5700万名用户数据,包括司机的姓名和驾照号码,用户的姓名、邮箱和手机号。调查发现,Uber数据泄露的原因竟然是工程师将解锁数据库的安全密钥存储在GitHub的一个可以公开访问的页面。

3.镜像脆弱性分析

对于容器镜像的安全性来说,开源软件的安全风险仅仅是容器镜像脆弱性的一个子集。下面本文将详细介绍容器镜像所面临的脆弱性问题。

3.1 镜像来源

3.1.1 公共镜像的安全威胁

从用户角度来看,容器镜像在获取途径上,我们将其分为“从公共仓库获取”以及“从私有仓库获取”两种,那么对于从公共仓库获取的镜像,最重要的两个脆弱性问题:一方面是镜像中软件的安全漏洞问题;另一方面是镜像内的挖矿程序、后门程序、病毒、木马等恶意程序。

容器的镜像,从某种意义上来看,其实就是系统软件或者是应用软件的一种交付形式,那么从安全的角度来看,软件漏洞将是给软件带来安全风险的最直接也是最重要因素,因此讨论容器镜像的安全,首要考虑的因素就是镜像中软件漏洞的管理。

有关研究报告[3]显示,Docker Hub中超过30%的官方镜像包含高危漏洞,接近70%的镜像有着高危或中危漏洞。

笔者从Docker Hub中选择评价和下载量较高的10个镜像,对其最新版本(latest)采用Clair工具进行了扫描分析。从结果可以看出,如此高频率使用的镜像,绝大多数均存在高危漏洞,有的镜像高危漏洞数量甚至达到数十个之多。

图4 Docker Hub中部分镜像漏洞情况统计

当然,笔者这里对于公共仓库中镜像的漏洞统计,只是采用开源的工具,直接对镜像的漏洞进行了一个简单的扫描分析。对于这样的结果,并不代表公共仓库的镜像真的就危险到不可以使用。当然也不能排除扫描工具在漏洞处理上存在的一些问题。

 

由于公共仓库是对所有用户开放的,任何用户都可以从仓库中获取现有的容器镜像,当然也可以将自己制作的镜像上传至公共仓库,供其它用户使用。如果有黑客在制作镜像时植入木马、后门等恶意软件,并将恶意镜像上传至Docker Hub等公共仓库,那么用户的容器环境从一开始就已经不安全了,后续更没有什么安全可言。

比如Docker对镜像不安全的处理管道,Docker支持三种压缩算法,分别是gzip、bzip2、xz。gzip和bzip2使用Go的标准库,所以相对安全;xz由于没有使用原生的Go去实现,又由于其使用由C编写的XZ Utils开源项目,所以存在C程序恶意写入的可能,一旦被写入会导致执行任意代码漏洞,而只要有一个漏洞,执行docker pull拉取镜像时就有可能导致整个系统沦陷。

2018年6月,就有安全厂商发现17个受到感染的Docker容器镜像[4],镜像中包含了可用于挖掘加密货币的程序,更危险的是,这些镜像的下载次数已经高达500万次。

对于特定某文件,一般可以使用杀毒软件进行扫描以确定该文件是否安全,但是目前的杀毒软件并没有能够很好支持镜像的扫描。用户想确认下载的镜像是否安全,只能仔细检查下载的源是否有后门(比如运行镜像,然后在里面安装杀毒软件扫描),并且确认请求指向官方源。

3.1.2 私有镜像的安全威胁

对于私有仓库中的镜像,通常是用户自己制作上传生成的,那么其脆弱性一方面包括软件代码本身的脆弱性,另一方就是配置的风险。

软件代码的脆弱性,不仅需要在开发过程中尽可能遵循SDL(安全开发生命周期),在开发完成后,同样需要进行代码审计、渗透测试等安全检查,保证应用的镜像在生成之前,已经解决所有已知的代码漏洞。

在制作镜像的过程中,镜像内是否包含了账号密码等信息、是否包含了秘钥文件信息、是否暴露其它敏感信息、是否运行了禁止运行的命令等问题,在镜像入库之前,也是要重点进行检测的。

另外,用户在使用容器的时候,很自然地会和虚拟机进行类比,比如怎么进入容器内进行调试、sshd怎么配置等。要正确的使用容器,一定要有容器化的思维,正确的认识容器。特别是在微服务体系中,容器的本质就是一个或少数进程以及运行进程所需要的各种依赖,即运行时环境的最小集。因此,在镜像制作过程,一定要尽可能的只运行必要的服务,只暴露出必要的端口。

如果在容器中运行了SSH、TELNET等服务,不仅不会增加该微服务的功能,反而会带来一系列的安全威胁以及增加安全运维的复杂度。比如SSH服务的访问策略和安全合规性管理、各种容器的秘钥以及密码管理、SSH服务安全升级等。

3.2 镜像传输

容器镜像在下载和上传时需保证完整性和秘密性,以下建议有助于抵御如中间人攻击等威胁:

(1)数字签名。上传者主动给要上传的镜像签名,下载者获取镜像时先验证签名再使用,防止其被恶意篡改。

(2)用户访问控制。敏感系统和部署工具(注册中心、编排工具等)应该具备有效地限制和监控用户访问权限的机制。

(3)尽可能使用支持HTTPS的镜像仓库。为避免引入可疑镜像,用户谨慎使用–insecure-registry选项连接来源不可靠的HTTP镜像仓库。

4. 镜像脆弱性评估示例

当前,针对容器镜像的脆弱性问题,一些容器安全的厂商以及开源项目,均提供了相应的检测能力,下表[5]中对几个常见的扫描工具从功能、开源等几个方面进行了对比分析。

对于镜像的脆弱性检测,其中涉及到几个核心的环节。检测工具需要获取当前的所有漏洞信息,通常会从主流的漏洞平台获取,比如NVD。

获取待检测镜像,并针对镜像的每一层进行解析,获取到镜像中所有的软件包以及对应的版本信息。

这样,根据软件包的版本信息以及漏洞库信息,就可以对容器镜像内的应用软件进行CVE的检测了。

在对容器镜像进行解析的时候,不仅可以获取到相应软件包的版本信息,同时还能精确的分析到镜像内的所有文件。这样假如存在“/etc/ssh/ssh_host_dsa_key”、“/home/user/.ssh/id_rsa”这样的敏感秘钥信息,可以对其进行告警。

下面,我们使用Clair(latest)针对Ubuntu 14.04进行扫描测试,并尝试进行漏洞修复。

首先对Ubuntu:14.04镜像进行扫描(clairctl analyze registry.securityapp.store/library/ubuntu:14.04 –log-level Debug),扫描过程如下图所示。

经过逐层的分析,扫描结果如下图。

使用clairctl将所报漏洞以报表(html格式)的形式输出(clairctl report -l registry.securityapp.store/library/ubuntu:14.04 –log-level debug),过程如下图所示。

使用docker cp(docker cp fda246b5625c:/reports/html/analysis-registry.securityapp.store-library-ubuntu-14.04.html /tmp/)将html文件输出至本地后,用浏览器打开报表。

由上图可以看出,报告中已经将高、中、低以及可忽略的漏洞友好的分类显示出来,其中高危漏洞1个,中危漏洞50个,低危漏洞78个,可忽略漏洞24个。此处我们将高危漏洞找出,具体漏洞如下图所示。

点击漏洞链接可知目前官方的Ubuntu 14.04 LTS(Trusty Tahr)已发布了release版本2.19-0ubuntu6.14,修复了此漏洞。

接下来,我们将含有漏洞的镜像运行为容器(docker run -dt –name ubuntu-test-clair registry.securityapp.store/library/ubuntu:14.04),并且进入容器内部(docker exec -it 9bcf21a481d0 /bin/bash),过滤查看容器内含有漏洞的软件包信息,看到漏洞版本号为2.19-0ubuntu6.13。

然后对这两个软件包进行升级,待升级成功后,再次查看包的版本信息,已升级为最新版本2.19-0ubuntu6.14,如下图所示。

将这个容器打包为一个新的镜像(docker commit 9bcf21a481d0 ubuntu-fixed-clair),并上传是镜像仓库(docker tag ubuntu-fixed-clair:latest registry.securityapp.store/test/ubuntu-fixed-clair:latestdocker push registry.securityapp.store/test/ubuntu-fixed-clair:latest)。

通过Clair扫描这个漏洞修复后的镜像(clairctl analyze -l registry.securityapp.store/test/ubuntu-fixed-clair:latest –log-level debug),扫描结果如下图所示。

从扫描结果可以看出,之前含有高危漏洞的Ubuntu 14.04镜像经过手动修复漏洞并重新打包为新的镜像后,之前的高危漏洞已不存在。

 

参考文献

[1] 开源治理白皮书(2018), http://www.caict.ac.cn/kxyj/qwfb/ztbg/201804/P020180323313495961952.pdf

[2] 2018 Open Source Security and Risk Analysis, https://www.synopsys.com/content/dam/synopsys/sig-assets/reports/2018-ossra.pdf

[3] Over 30% of Official Images in Docker Hub Contain High Priority Security Vulnerabilities, https://www.banyanops.com/blog/analyzing-docker-hub/

[4] Tainted, crypto-mining containers pulled from Docker Hub, https://techcrunch.com/2018/06/15/tainted-crypto-mining-containers-pulled-from-docker-hub/

[5] https://www.meetup.com/Cloud-Native-days-china/events/251975991/

 

报告下载

点击此链接,下载《2018绿盟科技容器安全技术报告》完整版。

https://blog.nsfocus.net/global-threat-analysis-container-safety

添加好友,备注“进群”,加入容器安全技术交流群,通过后会拉您入群。

Spread the word. Share this post!

Meet The Author

Leave Comment