云原生安全威胁分析报告

云原生安全威胁分析报告 厦门服云信息科技有限公司 1 序 2006年，亚马逊AWS把存储与计算能⼒通过S3和EC2以互联⽹的方式输送给广大⽤户，开启了云计算时代。云服务使得算⼒与数据资源像工业时代的电⼒资源一样，通过电⽹按需输送给千家万户。然而早期的云计算技术架构以虚拟机为主，资源损耗极大，就像由一大堆小型发电机堆砌的发电厂。云原生则是新一代云计算技术架构，采⽤了基于云计算特点的新理念与方法，包括容器、微服务、服务⽹格、DevOps等技术，好比运转现代化大型发电机的发电厂，将云计算资源充分发挥出了优势。2013年发布的Docker项目，2014年发布的Kubernetes项目，2015年成立的CNCF云原生基金会对云原生发展起到了重要作⽤。 然而，新兴威胁总是伴随着新兴技术而来，传统的IT与云安全解决方案对应新的云原生威胁捉襟见肘。CSA在云计算顶级威胁白皮书指出了云原生技术的重大新威胁，在云安全指南4.0中提出过对应措施，在CCM云安全标准中制定出相应的安全要求，在CNST云原生安全标准与认证中设置了设计与测评基线，并成立全球容器与微服务工作组、无服务工作组、云密钥管理工作组和大中华区云原生安全工作组持续进行云原生技术安全研究与标准制定。 云安全联盟大中华区理事单位安全狗发布的《云原生安全威胁分析报告》是业内对云原生安全威胁全面的分析，对广大云厂商和上云企业提供了极具价值的实践洞见,不仅覆盖容器化基础设施、容器编排平台、云原生应⽤以及无服务等方面云原生安全威胁，还提出了云原生漏洞风险检测模型“CCICA”，基于ATT&CK容器矩阵的产品检测能⼒模型方法论“AKDA”，各类云原生威胁检测技术，这项报告对于云原生生态的安全发展具有重要的意义。 从发展趋势看，更多企业将会广泛应⽤云原生技术，云原生应该基于开源、开放的技术标准，云原生安全应该具有包括安全检测的内生安全能⼒，这样云原生将为企业带来快速业务创新的更大价值，相信数字领域的所有安全工作者都 会从阅读本白皮书中受益。 ——国际云安全联盟大中华区 目录 云原生安全威胁分析报告厦门服云信息科技有限公司 一、前言4 二、云原生安全威胁分析4 （一）容器化基础设施的威胁风险4 （二）容器编排平台的风险分析7 （三）云原生应用的威胁风险8 （四）无服务的威胁风险9 （五）服务网格的威胁风险10 三、云原生安全近年威胁10 （一）近年云原生安全事件风险10 （二）近年云原生安全漏洞风险16 四、云原生威胁检测技术13 （一）容器镜像安全检测技术13 （二）容器运行时安全检测技术15 （三）容器网络安全检测技术16 （四）云原生可观测性17 （五）宿主机威胁检测技术19 （六）容器ATT&CK矩阵22 五、云原生漏洞风险检测模型23 （一）CCICA云原生安全模型介绍23 （二）CCICA云原生安全模型漏洞检测方法概述25 六、云原生入侵风险检测模型27 （一）AKDA模型28 （二）模拟红队攻击29 （三）攻防知识图谱31 （四）数据源32 （五）威胁检测算法32 （六）AKDA模型与ATT&CK之间的关系32 七、云原生威胁检测实战场景33 （一）镜像安全34 （二）应用安全36 （三）容器安全38 （四）主机安全42 八、云原生安全实践与技术展望45 （一）云原生安全实践45 （二）云原生未来展望46 参考资料50 一、前言 随着云计算技术的蓬勃发展，传统上云实践中的应用升级缓慢、架构臃肿、无法快速迭代等“痛点”日益明显。能够有效解决这些“痛点”的云原生技术正蓬勃发展，成为赋能业务创新的重要推动力，并已经应用到企业核心业务。然而，云原生技术在创造效益的同时，却也面临着严峻的安全问题。 本报告基于安全狗“云原生安全团队”近几年的研究成果，以及近年来对云原生安全领域的观察编制而成。我们期望通过我们对以“云原生威胁检测”为主要视角的总结分析，能够为各个行业/企业/单位对云原生安全技术开展后续的云原生安全建设提供进一步的参考建议。 本报告的主要内容如下： 第一部分，从容器化基础设施、容器编排平台、云原生应用以及无服务等方面分析云原生安全威胁； 第二部分，从云原生安全事件风险、云原生安全漏洞风险等方面介绍近年来一些重要的云原生安全威胁； 第三部分，从容器镜像、容器运行时、容器网络、云原生可观测性、宿主机威胁检测以及容器ATT&CK矩阵等角度介绍云原生威胁检测技术； 第四部分，介绍基于我司实践经验提出的五层云原生漏洞风险检测模型“CCICA”； 第五部分，介绍基于我司实践经验提出的一种基于ATT&CK容器矩阵的可应用于提取检测规则，提升产品检测能力的模型方法论“AKDA”； 第六部分，介绍我司基于CCICA、AKDA的理论基础的云原生威胁检测实战场景、案例； 第七部分，从云原生未来发展趋势、云原生安全未来发展趋势以及云原生攻防对抗未来发展趋势三个角度进行云原生安全实践与技术展望。 二、云原生安全威胁分析 云原生技术逐渐成为云计算市场发展的新趋势之一。随着越来越多的云原生应用落地和使用，其相关的安全风险与威胁也不断涌现。云原生安全事件频频发生也直接影响了整个云原生系统的安全性。以下章节将围绕云原生环境中存在的威胁展开分析。 （一）容器化基础设施的威胁风险 在实现云原生的主要技术中，容器作为支撑应用运行的重要载体为应用的运行提供了隔离和封装，因此成为云原生应用的基础设施底座。云原生架构的安全风险包含容器化基础设施自身的安全风险，容器化部署则成为云原生计算环境风险的输入源。 1．容器全生命周期的威胁风险 容器的秒级启动或消失的特性以及持续频繁的动态变化，极大程度地缩短了生命周期，但也增加了安全保护的难度和挑战。容器的安全问题，在容器全生命周期（创建、分发、运行、停止）的各个阶段都存在相应的风险和威胁隐患，如图2-1所示。 图2-1容器全生命周期的威胁风险 （1）容器镜像构建阶段存在的风险 随着容器技术的普及，容器镜像也成为了软件供应链中重要的一环。因此，当业务依赖的基础镜像存在安全漏洞或者包含恶意代码时，其潜在危害比黑客从外部发起攻击要严重得多。 ①镜像CVE漏洞利用 “镜像漏洞利用”指的是镜像本身存在漏洞时，依据镜像创建并运行的容器通常也会存在相同漏洞，镜像中存在的漏洞会被攻击者用以攻击容器的情况。这种行为往往会对容器造成严重影响。备受开发者青睐的Alpine镜像曾曝出过一个漏洞，编号为CVE-2019-5021。在3.3到3.9版本的Alpine镜像中，root用户密码被设置为空，攻击者在攻入容器后获得容器内部root权限的机会增大。 ②镜像投毒 镜像投毒是一个宽泛的话题。指的是攻击者通过某些方式，如上传镜像到公开仓库、入侵系统后上传镜像到受害者本地仓库以及修改镜像名称假冒正常镜像等，欺骗、诱导受害者使用攻击者指定的恶意镜像创建并运行容器，从而实现入侵或利用受害者的主机进行恶意活动的行为。 根据目的不同，常见的镜像投毒有三种类型：投放恶意挖矿镜像、投放恶意后门镜像和投放恶意exploit镜像。 投递恶意挖矿镜像。这种投毒行为主要是通过欺骗受害者在机器上部署容器的方式获得经济收益。2018年6月，一份研究报告指出，一个名为docker123321的账号向DockerHub上陆续上传了17个包含挖矿代码的恶意镜像。截至DockerHub官方移除这些镜像时，它们已经累计被下载超过500万次。据统计，黑客借助这一行为获得了市值约9万美元的门罗币。 投放恶意后门镜像。这种投毒行为的主要目的是控制容器。通常，受害者在机器上部署容器后，攻击者会收到容器反弹过来的Shell。在2017年9月，有用户在DockerHub的反馈页面中反馈前述docker123321账号上传的Tomcat镜像包含了后门程序。结合该账号上传的其他恶意镜像的挖矿行为可推测出攻击者在连接上述后门后会部署挖矿程序以此获得经济收益的可能性。 投放恶意exploit镜像。这种投毒行为是为了在受害者部署容器后尝试寻找宿主机上的各种漏洞来实现容器逃逸，以实现对受害者机器更强控制。从攻防对抗的角度来看，恶意exploit镜像只不过是一种攻击载荷投递方式，其特点在于具有隐蔽性和可能产生巨大的影响范围。试想，如果DockerHub上某一热门镜像包含了某个1day甚至0day漏洞的利用程序，理论上，攻击者将一下子获取上百万台计算机的控制权限。 （2）容器镜像分发阶段存在的风险 镜像的安全需要重点建设。镜像的安全性会直接影响容器安全，因为容器镜像在存储和使用的过程中，可能会被植入恶意程序或修改内容以此篡改。一旦使用被恶意篡改的镜像创建容器后，将会影响容器和应用程序的安全。 （3）容器运行时存在的风险 在容器运行时存在的安全问题中，“容器逃逸”是最具代表性的高风险安全问题。攻击者可通过利用漏洞“逃逸”出自身拥有的权限，实现对宿主机或者宿主机上其他容器的访问，同时带来进行时资源耗尽的风险。 ①容器逃逸 与其他虚拟化技术类似，逃逸是最为严重的安全风险。无论是Docker容器、还是Kata类安全容器，都暴露过各类逃逸漏洞。逃逸风险对于容器化的云原生场景是一个不可避免的风险面，因为其直接危害了底层宿主机和整个云计算系统的安全。根据层次的不同，可以进一步展开为：危险配置导致的容器逃逸、危险挂载导致的容器逃逸、相关程序漏洞导致的容器逃逸、内核漏洞导致的容器逃逸、安全容器逃逸风险。 危险配置导致的容器逃逸。用户可以通过修改容器环境配置或在运行容器时指定参数来缩小或扩大约束。如果用户为不完全受控的容器提供了某些危险的配置参数，就为攻击者提供了一定程度的逃逸可能性，主要包括未授权访问带来的容器逃逸风险，特权模式运行带来的容器逃逸风险。 危险挂载导致的容器逃逸。将宿主机上的敏感文件或目录挂载到容器内部，尤其是那些不完全受控的容器内部，往往会带来安全问题。在某些特定场景下，为了实现特定功能或方便操作，人们会选择将外部敏感卷挂载入容器。随着应用的逐渐深化，挂载操作变得愈加广泛，由此而来的安全问题也呈现上升趋势。例如：挂载DockerSocket引入的容器逃逸风险、挂载宿主机procfs引入的容器逃逸风险等。 相关程序漏洞导致的容器逃逸。所谓相关程序漏洞，指的是那些参与到容器生态中的服务端、客户端程序自身存在的漏洞。CVE-2019-5736正是这样一个存在于runC的容器逃逸漏洞，它由波兰CTF战队DragonSector在35C3CTF赛后基于赛中一道沙盒逃逸题目获得的启发，对runC进行漏洞挖掘，成功发现能够覆盖宿主机runC程序的容器逃逸漏洞。 内核漏洞导致的容器逃逸。Linux内核漏洞的危害之大、影响范围之广，使得它在各种攻防话题下都占有一席之地。近年来，Linux系统曝出过无数内核漏洞，其中能够用来提权的也不少，脏牛（CVE-2016-5195）大概是其中最有名气的漏洞之一。事实上，脏牛漏洞也能用来进行容器逃逸，一种利用方法的核心思路是向vDSO内写入shellcode并劫持正常函数的调用过程。在成功触发漏洞后，攻击者可以获得宿主机上反弹过来的Shell，实现容器逃逸。 安全容器逃逸风险。无论是理论上，还是实践中，安全容器都具有非常高的安全性。然而，在2020年BlackHat北美会议上，YuvalAvrahami分享了利用多个漏洞成功从Katacontainers逃逸的议题，安全容器首次被发现存在逃逸可能性，他使用发现的三个漏洞（CVE-2020-2023、CVE-2020-2025和CVE-2020-2026）组成漏洞利用链先后进行容器逃逸和虚拟机逃逸，成功从容器内部逃逸到宿主机上。 ②资源耗尽 容器在运行时默认情况下并未对容器内进程在资源使用上做任何限制，以Pod为基本单位的容器编排管理系统也是类似的。Kubernetes在默认情况下同样未对用户创建的Pod做任何CPU、内存用限制。限制的缺失使得云原生环境面临资源耗尽型攻击风险。 （4）容器网