原文首发在:奇安信攻防社区 https://forum.butian.net/share/2638 作者:凝 前言: 我认为docker容器逃逸也算是提权的一种手法,要更好的理解容器逃逸的手法,应该知道从本质上看容器内的进程只是一个受限的普通 Linux 进程,而容器逃逸的过程我们完全可以将其理解... 前言: 我认为docker容器逃逸也算是提权的一种手法,要更好的理解容器逃逸的手法,应该知道从本质上看容器内的进程只是一个受限的普通 Linux 进程,而容器逃逸的过程我们完全可以将其理解为在一个受限进程中进行一些操作来获取未受限的完整权限 privileged 特权容器的权限其实有很多,所以也有很多不同的逃逸方式,挂载设备读写宿主机文件是特权容器最常见的逃逸方式之一 如何判断当前容器是以Privileged 特权模式启动的呢? main(void) { int *a = NULL; *a = 1; return 0; } gcc ning.c -o ning chmod 777 ning 紧接着我们在攻击机上起监听
,要更好的理解容器逃逸的手法,应该知道从本质上看容器内的进程只是一个受限的普通 Linux 进程,而容器逃逸的过程我们完全可以将其理解...前言:我认为docker容器逃逸也算是提权的一种手法,要更好的理解容器逃逸的手法 限制权限的进程获取更多权限,当清晰的理解了这一点,接下来的容器逃逸学习将会易如反掌容器逃逸环境搭建作者这里选择的是Ubuntu-18.04和Ubuntu22.04,推荐使用Ubuntu18.04首先安装 docker容器的环境,我们便要尝试容器逃逸Docker配置不当导致的容器逃逸这里我们再次提到NameSpace和cgroupsLinux 命名空间(NameSpace):实现文件系统、网络、进程、主机名等方面的隔离 privileged 特权容器的权限其实有很多,所以也有很多不同的逃逸方式,挂载设备读写宿主机文件是特权容器最常见的逃逸方式之一如何判断当前容器是以Privileged 特权模式启动的呢? stdio.h>int main(void) { int *a = NULL; *a = 1; return 0;}gcc ning.c -o ningchmod 777 ning紧接着我们在攻击机上起监听于此同时
随着容器化技术普及,容器逃逸攻击已成为云原生环境的核心威胁。 本文基于腾讯云容器安全服务(TCSS)的能力,系统阐述容器逃逸攻击的防御策略,通过技术解析与实战案例结合的方式,为企业提供可落地的安全建设方案。 一、容器逃逸攻击:云原生时代的隐形杀手容器逃逸攻击是指攻击者通过漏洞利用或配置缺陷,突破容器沙箱限制,获取宿主机权限的恶性行为。 CVE漏洞库(含CNVD定制规则)、木马病毒查杀、敏感信息检测 阻断带病镜像进入流水线 运行时防御 主机Agent+eBPF技术实现细粒度监控,实时拦截容器逃逸 限制容器特权模式 设置文件读写白名单 基线治理 导入CIS Kubernetes Benchmark模板 自动修复高风险配置项 周期性合规巡检 应急演练 模拟容器逃逸攻击场景 测试日志溯源完整性
Part01 简述docker容器逃逸什么是docker? 容器是完全使用沙箱机制,相互之间不会有任何接口。什么是Docker容器逃逸? Docker容器逃逸指的是攻击者通过劫持容器化业务逻辑或直接控制等方式,已经获得了容器内某种权限下的命令执行能力;攻击者利用这种命令执行能力,借助一些手段进而获得该容器所在的直接宿主机上某种权限下的命令执行能力 在特定网络条件下,攻击者可通过访问containerd-shimAPI,从而实现Docker容器逃逸。 成功接受到shellPart04 如何防止docker逃逸1、避免使用特权模式启动容器,或者限制容器所需的最小权限;2、避免将宿主机上的敏感文件或目录挂载到容器内部,或者使用只读模式挂载;3、避免将Docker
=0),这时候就有了逃逸的机会。 所谓容器逃逸,就是容器中的进程通过某种方式改写主机环境,从容器这个平行世界中“逃脱”,改变主世界。 在容器中它可能只是个“村长”,但由于它的 UID 与外面的“国王”相等,一旦逃逸发生,它就等同于拥有“国王”权限,可以对外发布更高权限的命令。 CVE-2019-5736: 改写 runc 容器逃逸 在 2019 年初,爆发了一个容器严重漏洞,运行 docker 的容器环境,普通用户可以通过特殊构建的镜像,运行后改写主机上的 runc,从而进一步进行入侵操作 CVE-2019-14271: 通过 docker-cp 容器逃逸 这个漏洞是指当运行 docker 的环境中调用docker cp时,如果访问的是一个恶意容器,容器中的用户就可以在主机中运行任意代码。
docker是目前主流的容器技术,今天我们来探讨一下docker逃逸的3种常见方式:内核漏洞引起的逃逸、相关程序漏洞引起的逃逸和docker配置不当引起的逃逸。 由于容器共享宿主机内核,可在容器中利用VDSO(Virtual Dynamic Shared Object,虚拟动态共享对象)内存空间中的clock_gettime() 函数对宿主机存在的脏牛漏洞发起攻击 攻击者可以通过特定的容器镜像或者exec操作获取到宿主机runc执行时的文件句柄并修改掉runc的二进制文件,从而获取到宿主机的root执行权限。 将该payload拷贝到docker容器中(此时可以模拟攻击者获取了docker容器权限,在容器中上传payload进行docker逃逸) ? 容器运行时安全:容器在运行时也会产生安全问题,包括有磁盘资源限制问题,容器逃逸问题,容器DoS攻击与流量限制问题等等。
作者 | Tina 微软在 Service Fabric (SF) 应用程序托管平台爆出了一个名为 FabricScape 的容器逃逸漏洞,攻击者可利用此漏洞将权限提升到 root,夺取主机节点的控制权 微软建议客户持续审查一切有权访问其主机集群的容器化工作负载(包括 Linux 与 Windows)。 微软表示,“默认情况下,SF 集群是单租户环境,因此应用程序之间没有隔离。
在这篇博文中,我将向大家展示访问我们的 Kubernetes 集群的攻击者如何进行容器逃逸:运行 Pod 以获得 root 权限,将 Pod 转义到主机上,并通过不可见的 Pod 和无文件执行来持续攻击 问题 在容器逃逸期间,攻击者打破了主机和容器之间的隔离边界,最终逃逸至 Kubernetes 控制平面或工作节点的地方。 在 Kubernetes 环境中应用安全最佳实践可以限制这些类型的攻击,但容器突破仍然是可能的,攻击者可以使用特权 Pod 或利用现有漏洞来获得特权。 让我们进入主机命名空间 在此示例中,我们使用具有主机命名空间配置的特权 Pod 来表示容器逃逸攻击。正如我们在此处演示的那样,这在强化的 Kubernetes 环境中是可能的。 请注意,有多种方法可以执行突破,例如,攻击者也可以利用漏洞获得特权并逃出容器沙箱。 攻击者执行容器逃逸的第一个也是最简单的步骤是使用特权 Pod 规范启动一个 Pod。
在这篇博文中,我将向大家展示访问我们的 Kubernetes 集群的攻击者如何进行容器逃逸:运行 Pod 以获得 root 权限,将 Pod 转义到主机上,并通过不可见的 Pod 和无文件执行来持续攻击 问题 在容器逃逸期间,攻击者打破了主机和容器之间的隔离边界,最终逃逸至 Kubernetes 控制平面或工作节点的地方。 在 Kubernetes 环境中应用安全最佳实践可以限制这些类型的攻击,但容器突破仍然是可能的,攻击者可以使用特权 Pod 或利用现有漏洞来获得特权。 让我们进入主机命名空间 在此示例中,我们使用具有主机命名空间配置的特权 Pod 来表示容器逃逸攻击。正如我们在此处演示的那样,这在强化的 Kubernetes 环境中是可能的。 请注意,有多种方法可以执行突破,例如,攻击者也可以利用漏洞获得特权并逃出容器沙箱。 攻击者执行容器逃逸的第一个也是最简单的步骤是使用特权 Pod 规范启动一个 Pod。
高危启动参数 privileged 特权模式 挂载敏感目录 相关启动参数存在的安全问题 3、Docker 软件设计引起的逃逸 Shocker攻击 runC容器逃逸漏洞(CVE-2019-5736) Docker 3.1 Shocker 攻击 在容器逃逸案例中,最为著名的是shocker攻击,其通过调用open_by_handle_at函数对宿主机文件系统进行暴力扫描,以获取宿主机的目标文件内容。 函数的能力,导致容器逃逸的发生。 3.2 runC容器逃逸漏洞(CVE-2019-5736) 漏洞简述: Docker 18.09.2之前的版本中使用了的runc版本小于1.0-rc6,因此允许攻击者重写宿主机上的runc 二进制文件 ---- 3.3 Docker cp命令可导致容器逃逸攻击漏洞(CVE-2019-14271) 漏洞描述: 当Docker宿主机使用cp命令时,会调用辅助进程docker-tar,该进程没有被容器化,
Docker 枚举、特权升级和容器逃逸 (DEEPCE) 为了使其与最大数量的容器兼容,DEEPCE 是纯编写的sh,没有依赖性。 枚举都不应该触及磁盘,但是大多数漏洞利用会创建新的容器,这将导致磁盘写入,并且一些漏洞利用会覆盖 runC,这可能具有破坏性,所以要小心! 可以使用以下单行之一将 DEEPCE 下载到主机或容器上。提示:下载到/dev/shm避免接触磁盘。 容器 ID 和名称(通过反向 DNS) 容器 IP / DNS 服务器 码头工人版本 有趣的坐骑 普通文件中的密码 环境变量 密码哈希 容器中存储的常见敏感文件 同一网络上的其他容器 端口扫描其他容器, 利用特权容器在主机操作系统上创建新的 root 用户: .
0x00 前言 runc是一个遵循oci标准的用来运行容器的命令行工具。runc的使用非常灵活,可以与各种容器工具和平台集成,如Docker、Kubernetes等。 0x01 漏洞描述 由于内部文件描述符泄漏,本地威胁者可以通过多种方式实现容器逃逸: 通过使新生成的容器进程(来自runc exec)在主机文件系统命名空间中拥有一个工作目录,或诱使特权用户运行恶意镜像并允许容器进程通过 这些攻击还可用于覆盖半任意主机二进制文件,从而实现容器逃逸。
开宗明义,本文将「容器逃逸」限定在一个较为狭窄的范围,并围绕此展开讨论: 「容器逃逸」指这样的一种过程和结果:首先,攻击者通过劫持容器化业务逻辑,或直接控制(CaaS等合法获得容器控制权的场景)等方式, 如果用户为不完全受控的容器提供了某些危险的配置参数,就为攻击者提供了一定程度的逃逸可能性。 例如,攻击者可以直接在容器内部挂载宿主机磁盘,然后将根目录切换过去: ? 至此,攻击者已经基本从容器内逃逸出来了。 在新容器内执行chroot将根目录切换到挂载的宿主机根目录。 具体交互如下图所示: ? 至此,攻击者已经基本从容器内逃逸出来了。 攻击者可以凭借此特点拓展容器逃逸的思路(一旦有新的内核漏洞产生,就可以考虑它是否能够用于容器逃逸),防守者则能够针对此特征进行防护(为宿主机内核打补丁就阻止了这种逃逸手段)和检测(内核漏洞利用有什么特点
漏洞情况近期,火山信安实验室监测发现,Container Toolkit 组件存在一个高危容器逃逸漏洞(CVE-2025-23266),攻击者可利用该漏洞突破容器隔离限制,获取宿主机的系统级权限,进而执行任意代码或窃取敏感数据 0x01漏洞利用方式漏洞源于 NVIDIA Container Toolkit 在处理 GPU 设备挂载时未对容器配置实施严格校验,攻击者可利用这一缺陷通过构造恶意容器镜像或动态篡改运行时参数(如 -- )与容器运行时交互过程中存在的竞态条件及缓冲区溢出漏洞,攻击者能够触发内核态内存越界写入,最终实现宿主系统内核代码的任意执行;此外,通过恶意修改 NVIDIA Container Runtime 配置文件 (如 libnvidia-container.conf)中的关键参数(如 device.allow 或 kernel.modules.load),攻击者可强制容器以非预期的高权限模式启动,最终达成完全的容器逃逸与宿主机提权 Kubernetes 中使用 NetworkPolicy 限制逃逸容器的网络访问来源自:广州盈基信息官网
有在关注容器逃逸漏洞,最近在github上发现了一款零依赖Docker/K8s渗透工具包,集成了多个漏洞PoC/EXP,可轻松逃脱容器并接管K8s集群。 集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式,插件化管理。 github项目地址: https://github.com/Xyntax/CDK 下面以最近发布的容器逃逸漏洞 CVE-2020-15257作为演示漏洞利用过程。 ---- 漏洞简述: 当在docker使用–net=host参数启动,与宿主机共享net namespace时,容器中的攻击者可以绕过访问权限访问 containerd 的控制API 进而导致权限提升。 (3)通过CDK执行exp,成功反弹shell,实现容器逃逸。
: 提权漏洞 CVSS评分: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H - 高风险 (8.6) 由于runc存在内部文件描述符泄露,本地攻击者可以通过多种方式进行容器逃逸 : runc将包括宿主机 /sys/fs/cgroup的几个文件描述符泄漏到runc init中,攻击者可以利用这一漏洞欺骗具有特权的用户执行恶意容器镜像,导致pid1进程在宿主机挂载命名空间中拥有一个工作目录 一旦容器进程执行了容器镜像中的可执行文件,可以绕过PR_SET_DUMPABLE保护,之后攻击者可以通过打开 /proc/$exec_pid/cwd 来访问主机文件系统。 利用此问题可能会导致容器逃逸到底层主机操作系统,无论是通过执行恶意映像还是使用恶意 Dockerfile 或上游映像构建映像(即使用时FROM方式) Affected Versions v1.0.0-rc93 ,以及感谢SUSE的Aleksa Sarai发现了如何复现(攻击2和3b)通过runc exec方向实现容器逃逸。
0X1 漏洞详情 Docker、containerd或者其他基于runc的容器运行时存在安全漏洞,攻击者可以通过特定的容器镜像或者exec操作可以获取到宿主机的runc执行时的文件句柄并修改掉runc的二进制文件 然后进入容器内: ? 到root目录下,运行run.sh脚本 ? kali下开启另一个终端进行端口监听: ? 退出容器然后再重新进入容器,漏洞被触发,shell反弹过来 ? ? 至此,漏洞复现完毕!
本文将沿着上文的思路,主要从Linux内核漏洞的角度对容器逃逸进行深度介绍,包括攻击原理、自动化利用和防御思路等内容。 攻击者利用内核漏洞可以达到本地提权的目的。容器技术本身依赖于Linux内核提供的Namespaces和Cgroups机制,利用内核漏洞,攻击者可以绕过Namespaces对资源的隔离,达到逃逸的目的。 基于以上的了解,本文提出了一套流程以辅助攻击者利用内核漏洞进行容器逃逸。同时,进一步思考利用Linux内核漏洞进行逃逸能否实现工程化利用,这其中的难点是什么。 该漏洞恰好位于user namespaces的实现中,攻击者在容器内读取到宿主机中的密码文件等敏感文件,间接实现了容器逃逸。 本文的重点在攻击,但也是想帮助防御者理解容器逃逸的攻击方法,毕竟,未知攻,焉知防?
它的核心思想是,为每一个容器运行一个独立虚拟机,从而避免其与宿主机共享内核。这样一来,即使攻击者在容器内部成功利用了内核漏洞攻破内核,他依然被限制在虚拟机内部,无法逃逸到宿主机上。 从上图可以得出结论,在不考虑其他因素的情况下,如果Kata Containers内部的攻击者想要逃逸到宿主机上,他必须至少经过两次逃逸——「容器逃逸」和「虚拟机逃逸」,才能达到目的。 其中,CVE-2020-2024主要会导致拒绝服务攻击,对逃逸帮助不大。逃逸主要依靠其他三个漏洞形成的利用链条来实现。 这个议题精彩又富有意义。 漏洞分析 如「简介」部分所述,从容器到宿主机的逃逸涉及三个漏洞的使用,由「容器逃逸」和「虚拟机逃逸」两部分组成。 在许多云场景下,容器镜像是攻击者可控的, 因此——他够将特定文件放在宿主机上的特定位置,从而实现虚拟机逃逸。
介绍 最近搞了个检测 Docker 容器逃逸的脚本,目前支持以下几种方法的检测: 处于特权模式 挂载了 Docker Socket 挂载了 Procfs 挂载了宿主机根目录 开启了 Docker 远程 container-escape-check 感觉还不错的师傅们可以点个小星星 对于检测的原理可以看我写的这篇文章:https://zone.huoxian.cn/d/990 使用 在 Docker 容器中一键运行 /container-escape-check.s 注意: 这个脚本需要在 Docker 容器中运行 这里的检测方法大多是基于我自己的经验,可能会存在检测误检或者漏检的情况,如果您发现了这种情况,欢迎提 Issue 由于有的逃逸方法需要根据目标 Docker 的版本去判断,这里我暂时还没想到从容器内部获取 Docker 版本的方法,因此脚本暂时还不支持这块儿的检测。 ---- 往期推荐 漏洞复现 | DirtyPipe CVE-2022-0847 Linux 内核提权漏洞复现 云安全 | 容器基础设施所面临的风险学习 云安全 | AWS S3 对象存储攻防 原文链接