《绿盟科技：2020云原生安全技术报告（87页）.pdf》由会员分享，可在线阅读，更多相关《绿盟科技：2020云原生安全技术报告（87页）.pdf（87页珍藏版）》请在三个皮匠报告上搜索。

1、上图可以进一步展开为：危险配置导致的容器逃逸;危险挂载导致的容器逃逸;相关程序漏洞导致的容器逃逸;内核漏洞导致的容器逃逸。危险配置导致的容器逃逸在这些年的迭代中，容器社区一直在努力将纵深防御、最小权限等理念和原则落地。然而，无论是细粒度权限控制还是其他安全机制，用户都可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性。最初，容器特权模式的出现是为了帮助开发者实现 Docker-in-Docker 特性 13。然而，在特权模式下运行不完全受控容器将给宿主机带来极大安全威胁。例如，攻击者可以直接在

2、容器内部挂载宿主机磁盘，然后将根目录切换过去，从而实现容器逃逸。危险挂载导致的容器逃逸在某些特定场景下，为了实现特定功能或方便操作(例如为了在容器内对容器进行管理将 Docker Socket 挂载到容器内)，用户会将外部敏感卷挂载入容器。随着容器技术应用的逐渐深化，挂载操作变得愈加广泛，由此而来的安全问题也呈现上升趋势。Docker Socket 是 Docker 守护进程监听的 Unix 域套接字，用来与守护进程通信，查询信息或下发命令。如果在攻击者可控的容器内挂载了该套接字文件(/var/run/docker.sock)，容器逃逸就相当容易了，除非有进一步的权限限制。一种逃逸方法是：(1

3、)在容器内安装 Docker 命令行客户端;(2)使用该客户端通过 Docker Socket 与 Docker 守护进程通信，发送命令创建并运行一个新的容器，将宿主机的根目录挂载到新创建的容器内部;(3)在新容器内执行 chroot 将根目录切换到挂载的宿主机根目录。相关程序漏洞导致的容器逃逸所谓相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。CVE-2019-5736 正是这样一个存在于 runC 的容器逃逸漏洞，它由波兰 CTF 战队 Dragon Sector 在35C3 CTF 赛后基于赛中一道沙盒逃逸题目获得的启发，对 runC 进行漏洞挖掘，成功发现的

4、一个能够覆盖宿主机 runC 程序的容器逃逸漏洞。该漏洞于 2019 年 2 月 11 日通过邮件列表披露，具体分析可参见“容器逃逸成真：从 CTF 解题到 CVE-2019-5736 漏洞挖掘分析”14。内核漏洞导致的容器逃逸Linux 内核漏洞的危害之大、影响范围之广，使得它在各种攻防话题下都占据非常重要的一席。近年来，Linux 系统曝出过无数内核漏洞，其中能够用来提权的也不少，脏牛(CVE-2016-5195)大概是其中最有名气的漏洞之一。事实上，脏牛漏洞也能用来进行容器逃逸，一种利用方法的核心思路是向 vDSO 内写入 shellcode 并劫持正常函数的调用过程。在成功触发漏洞后，

5、攻击者可以获得宿主机上反弹过来的 Shell，实现容器逃逸。其他作为一种轻量级虚拟化技术，传统容器与宿主机共享内核，这意味着系统内核权限提升漏洞往往也可用来实施容器逃逸。为了彻底解决这一问题，在轻量与安全性之间达到较好的平衡，安全容器应运而生。Kata Containers 是一种安全容器的具体实现，其他主流的安全容器还有 Google 推出的 gVisor 等。北美会议上，Yuval Avrahami 分享了利用多个漏洞成功从 Kata containers 逃逸的议题 15，安全容器首次被发现存在逃逸可能性。他使用发现的三个漏洞(CVE-2020-2023、CVE-2020-2025 和

6、CVE-2020-2026)组成漏洞利用链先后进行容器逃逸和虚拟机逃逸，成功从容器内部逃逸到宿主机上。3.1.3.资源耗尽型攻击同为虚拟化技术，容器与虚拟机既存在相似之处，也有显著不同。在资源限制方面，我们需要为即将创建的虚拟机设定明确的 CPU、内存及硬盘资源阈值，在虚拟机内部的进程看来，它真的处于一台被设定好的独立计算机之中。然而，容器运行时默认情况下并未对容器内进程在资源使用上做任何限制，以 Pod 为基本单位的容器编排管理系统也是类似的，Kubernetes 在默认情况下同样未对用户创建的 Pod 做任何 CPU、内存使用限制 16。限制的缺失使得云原生环境面临资源耗尽型攻击风险。攻击

7、者可能通过在一个容器内运行恶意程序，或针对一个容器服务发起拒绝服务攻击来占用大量宿主机资源，从而影响到宿主机或宿主机上其他容器的正常运行。3.2.微服务架构为云原生应用安全带来新的安全风险在如今应用的开发、测试、运维均追求敏捷开发的时代，微服务应运而生。但随着应用的微服务化升级，新的安全风险也不容忽视。首先，随着微服务的增多，暴露的端口数量也急剧增长，进而扩大了攻击面，且微服务间的网络流量多为东西向流量，网络安全防护维度发生了改变。其次，不同于单体应用只需解决用户或外部服务与应用的认证授权，微服务间的相互认证授权机制更为复杂，人为因素导致认证授权配置错误成为了一大未知风险。最后，微服务通信依赖于 API，随着业务规模的增大，微服务 API 数量激增，恶意的 API 操作可能会引发数据泄漏、越权访问、中间人攻击、注入攻击、拒绝服务等风险。