文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

基于业务场景的容器逃逸技术

2024-12-01 02:25

关注

导读

​近年来,容器凭借能在任意环境中运行、开销低、秒级启动、镜像占用小等优势,越来越受世界各种行业追捧。例如Google从Gmail到YouTube和Google搜索,几乎所有产品都在容器中运行,每个星期都要启动超过20亿个容器;京东构建了全球最大的容器集群,其内部99%都做了容器化,当前已有20万的容器集群规模,保证了京东618和双11大促销。

但容器早期发展主要考虑易用性和功能实现,对安全考虑不是很充分,存在方方面面的安全隐患。随着容器化的重要性与日俱增,容器安全的重要性也在不断提高。作为一项依然处于发展阶段的新技术,容器的安全性在不断地提高,也在不断地受到挑战。在其面临的所有安全问题当中,逃逸问题稳居首位——它直接影响到了承载容器的底层基础设施的机密性、完整性和可用性,危害了底层宿主机和整个云计算系统的安全。本文针对容器逃逸技术做全面的讲解。

1、容器安全风险

在容器时代,安全面临新旧威胁的双重挑战。一方面,传统的攻击手段依然有效,如注入漏洞、暴力破解、权限提升等。另一方面,新的攻击方式层出不穷,包括容器逃逸、投毒镜像、集群管理漏洞等,让人防不胜防。

1.1 容器作为轻量的虚拟化技术面临的主要安全风险

图1 虚拟机 vs 容器


从图中可以看出:

1.2 从容器生命周期看容器的关键安全风险

图2 Docker容器典型使用流程

Docker作为容器引擎的代表,从它的使用流程可以看出,容器安全风险贯彻容器构建、部署、运行整个生命周期。例如,在构建阶段,可能会遇到的软件供应链攻击,包括基础镜像污染、CI工具攻击、制品库漏洞攻击等。在部署阶段也可能面临针对云原生基础设施平台攻击,包括开源组件编排工具、安全合规检查等。在运行时阶段,还可能面临针对云原生应用的攻击,包括逃逸攻击、安全隔离、注入漏洞、弱口令等。

容器的生命周期短,动态变化快,超过50%容器从上线到下架的整个生命周期不超过1天。快速检测和响应容器入侵事件,把损失降到最低,成为了一大安全难题。

1.3 历年容器安全漏洞情况表明,容器逃逸占比最高、影响较大

在容器集群中,若攻陷一个容器,就可以横向移动到其它容器上,或者逃逸到node节点上进行持久化,控制整个节点。下一步,攻击者还可以通过漏洞利用或者调用API SERVER控制整个集群。容器的攻击价值高,俨然成为攻击者眼中“香饽饽”。

从下图的历年容器安全问题分布及容器运行时入侵事件统计分布可以看出,容器逃逸是用户最关注的安全问题,同时也是业务场景中遇到最多的安全问题。


图3 容器安全问题分布


图4 2021年容器运行时入侵事件统计分布

2、容器逃逸技术及原理

容器逃逸,是指“流氓”容器尝试突破正常隔离环境限制,借助一些手段获得容器所在的直接宿主机、宿主机上的其他容器或集群内其他主机、其他容器的某种权限下的命令执行能力,进行恶意攻击或执行越权访问的行为。如下图所示,容器逃逸漏洞可能打穿容器节点,甚至整个集群。

图5 从攻击方视角看容器逃逸攻击路径

容器逃逸的前提是已经获得了容器内某种权限下的命令执行能力,然后捅破隔离。容器的隔离技术不是新发明的,它借助Linux资源隔离的核心技术namespace来实现。

图6 应用层容器逃逸原理分析

从图6可以得知,Linux内核先天性隔离性不足,尽管目前namespace已经提供了非常多的资源隔离类型如PID、mount、network、UTS、IPC、user等,但除namespace外其它内核资源并未隔离或隔离不充分,其中包括一些系统的关键性目录(如/sys、/proc等),这些关键性的目录可能会泄露主机上一些关键信息,让攻击者利用这些信息对宿主机发起攻击,使得容器逃逸到宿主机。

特权模式在6.0版本的时候被引入Docker,其核心作用是允许容器内的root拥有宿主机的root权限。使用特权模式启动容器后(docker run --privileged),Docker容器被允许访问宿主机上的所有设备、可以获取大量设备文件的访问权限、可以执行mount命令进行挂载。当Docker管理员可通过mount命令将宿主机磁盘设备挂载进容器内部,即可获取对整个宿主机的文件读写权限,也可以通过写入计划任务等方式在宿主机执行命令,成功逃逸。

Linux内核自版本2.2引入了Capabilities机制,将传统的root用户的特权划分为30+个不同的单元,进行精细化管理。但如果Capabilities设置不正确,就会让攻击者有机可乘,实现权限提升。例如当容器以--cap-add=SYSADMIN启动,Container进程就被允许执行mount、umount等一系列系统管理命令,如果攻击者此时再将外部设备目录挂载在容器中就会发生Docker逃逸。可见,capabilities控制不当同样会引入容器逃逸,当前业界已识别SYSADMIN、DAC_READ_SEARCH、SYS_MODULE、SYS_PTRACE引入了逃逸漏洞。

3、基于业务的容器逃逸场景分析

基于大量业界容器安全CVE漏洞的研究,对产品业务场景中运行态的容器安全薄弱环节进行了分类,识别出容器逃逸主要分布在应用层、服务层和系统层。

图7 在产品业务场景中识别的容器逃逸问题

应用层的逃逸,主要体现在特权模式与配置不当,如利用特权模式逃逸、借助Capability逃逸。为了方便容器与宿主机进行数据交换,几乎所有主流的解决方案都会提供挂载宿主机目录到容器的功能,由此而来的容器逃逸问题也呈上升趋势,当容器以读写形式挂载宿主机上的敏感文件或目录如docker.sock、主机procfs时,从容器中逃逸出去易如反掌,手段也多种多样。

除了应用本身的脆弱性引入的攻击外,服务层集群、容器运行时本身的脆弱性问题也不容忽视。例如攻击者借助k8s的8080、6443未授权访问,可通过容器访问K8S master api进行恶意调用;参与到容器生态中的服务端、客户端程序自身存在的漏洞如runc、Containerd组件漏洞,同样可被容器利用从而获取宿主机的控制权。

此外,从系统层面来看,Docker直接共享宿主机的内核,所以当宿主机内核存在安全漏洞时会一并影响Docker的安全,导致可能会造成Docker逃逸。例如著名的脏牛漏洞CVE-2016-5195是Linux内核中的权限提升漏洞,通过它可实现Docker容器逃逸,获得root权限的shell。

4、解决容器逃逸的方案

4.1 Docker自身安全性改进

容器发展早期,容器内的root等同于宿主机上的root,若容器被攻破或容器本身存在恶意程序时,在容器内就可以获取到宿主机的root权限。Docker 1.10版本,引入User Namespace技术进行用户隔离,可将容器内的root用户映射到宿主机上的非root用户,大大减轻了容器逃逸的风险。容器社区持续在努力将纵深防御、最小权限等理念和原则落地,因此建议尽可能使用最新版Docker。且使用最新版本docker,已知的CVE漏洞都已修复,如更新Docker版本到19.03.1及更高版本,不再受CVE-2019-14271、CVE-2019-5736等漏洞影响。

4.2 安全配置及挂载

应用层大多容器相关漏洞,均由不安全配置或挂载引入。无论是细粒度权限控制还是其他安全机制,用户都可以通过修改容器环境配置或在运行容器时指定参数来调整。建议docker容器或k8s pod启动时,做到:

4.3 加强内核安全和管理

尽量安装最新补丁的主机内核版本,如Linux内核版本>=2.6.22解决了CVE-2016-5195(脏牛),Linux内核版本>=4.14解决了CVE-2017–1000405(大脏牛)。

4.4 使用安全加固组件

Linux的SELinux、AppArmor、GRSecurity组件都是Docker官方推荐的安全加固组件,这三个组件可以限制容器对主机的内核或其他资源的访问控制权限。下面说明下这些安全加固组件:

4.5 使用安全容器

容器有着轻便快速启动的优点,虚拟机有着安全隔离的优点,安全容器可以兼顾两者的优点,做到既轻量又安全。

安全容器与普通容器的主要区别在于,安全容器中的每个容器都运行在一个单独的微型虚拟机中,拥有独立的操作系统和内核,并且有虚拟机般的安全隔离性。

安全容器目前推荐的主流技术方案是Kata Containers,它并不包含一个完整的操作系统,只有一个精简版的Guest Kernel运行着容器本身的应用,可以通过使用共享内存来进一步减少内存的开销。另外,它还实现了OCI规范,可以直接使用Docker的镜像启动Kata容器,具有开销更小、秒级启动、安全隔离等许多优点。

图8 普通容器与安全容器对比

5、后记

正如前文所述,容器已经成为黑客的重点攻击目标,而应用层的容器逃逸漏洞占比最高。容器在应用层的安全很大程度上取决于其配置的安全性,我们在业务场景中尤为重要的就是Capabilities的赋予,一定要做到权限最小化,丢弃没有用到的特权。借助Capabilities逃逸只是冰山一角,还有大量逃逸场景待进一步研究。尽管有些Capabilities当前还没有被恶意利用,但无法确保后续不会成为攻击者逃逸的手段,因此务必做到维持业务必须的最小权限。

权限过多,难免疏忽。权限最小化的同时也要参考业界最佳实践:启用user namespace进行用户隔离并且以非root运行,这就好比使用预编译语句防御SQL注入,从根源上防御,切断所有的攻击路径,尽管这个方案可能对现有业务部署方案有大量的改动,但仍然应该成为容器防御的最终目标之一。

当前Docker的隔离性还远达不到虚拟机的水平,应该避免把Docker容器当成虚拟机来使用,除非在虚拟机里部署容器,否则建议Docker容器里只跑可信应用。

来源:移动Labs内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯