从云原生攻防之道看BAS安全验证新方向

type

status

date

slug

summary

前言

本文将深入探讨云安全知识及其在攻防两端的实际应用场景，并全面分析BAS技术在这些场景中的潜在应用。通过阅读本文，甲方安全人员将能够运用模拟攻击测试与修复技术，有效加固组织的安全防线，并根据测试结果精确调整安全控制策略和资源配置，从而显著提升安全管理的效率和成果。同时，对于云安全领域怀有浓厚兴趣的学习者或专业人士，本文将助您可以增强对云安全架构的理解，学习实施有效的云安全措施。对于BAS领域充满热情的学习者或专业人士，本文亦将引领您全面认识并熟悉BAS技术，进而提升在安全测试、安全运营以及风险评估等方面的专业技能和综合能力。

本文结构图:

0x2 引入

1.1 云原生安全风险

在当今的数字化时代，云计算平台如AWS、Google Cloud Platform（GCP）以及容器化技术如Kubernetes已成为企业和开发者部署应用和服务的首选基础架构。这些技术的广泛采用不仅带来了前所未有的灵活性和扩展性，也引入了新的安全挑战。随着越来越多的敏感数据和关键业务流程迁移到云端，云安全的重要性也日益凸显。

Wiz对200,000个云账号进行Kubernetes安全态势分析，发现85%的集群由云厂商托管，其中AWS的EKS最受欢迎。关于初始访问，公开集群占比为69%，且在所有暴露的Pods中，52%包含已知漏洞的容器镜像。横向移动和权限提升方面，8%的Pods拥有超出操作需求的RBAC权限，18%的Pod挂载了主机的敏感路径，约18%的Pod以Root权限运行。网络隔离方面，只有9%的集群使用了网络策略。影响层面，19%的Pod没有设置资源配额限制，15%的Pod拥有可以跳出集群的权限。安全控制和缓解措施方面，仅6%的集群未使用PSP、外部准入控制器或PSS。

随着企业与日俱进迁入云，不少大型企业为了满足合规等需求也在内部搭建了私有云、混合云。不同类型的客户根据其业务需求选择公有云、私有云或混合云，每种选择都面临着独特的安全挑战和考量。初创公司和中小企业倾向于使用公有云，因其成本效益和扩展性，但同时也必须依赖云服务提供商的安全实践，关注数据泄露和权限配置错误的风险。相比之下，金融、医疗和政府等行业，由于对数据隐私和合规性的高要求，通常选择私有云以获得更严格的数据控制和安全保护，但这也意味着他们需要自行承担更高的安全管理责任和成本。混合云用户，如追求灵活性同时又需保持关键数据控制的大型企业，面临着跨环境安全策略一致性和数据传输安全的挑战。尽管公有云和私有云用户在安全责任分担上存在差异，但所有客户都需实施加密、访问控制和恶意软件防护等基本安全措施，同时遵循最小权限原则，以保护敏感数据和资源。

1.2 云原生中的有效性验证

在云安全场景中，安全威胁层出不穷。BAS作为离朱-安全验证平台的技术之一，它会通过模拟潜在的攻击行为，帮助企业识别和应对特定的安全威胁。这种技术的核心优势在于其能够提前感知威胁风险，从而实现对企业的主动防护加固。Gartner在2017年定义了BAS技术类别，强调其通过不断模拟针对不同资产的攻击来验证安全防护的有效性。这种方法不仅有助于企业摆脱被动防御的“防御者陷阱”，还能够系统性地评估实战防护能力现状，从而体系化地了解自身的实战安全能力指标。

云原生BAS通过模拟真实攻击场景，帮助企业提前发现并修补潜在的安全漏洞，确保云环境的安全性，避免数据泄露和其他安全事故。该技术的引入，不仅改善了传统安全测试工具在云环境中的局限性，而且通过与现有安全架构的集成，实现了更全面和精准的安全保护。

2.3 小结

随着企业数字化向云原生转型，云计算市场被AWS、Azure等巨头主导，而企业的云架构多样化，涵盖混合云、私有云等，各具特点。混合云因其安全合规性和成本效益在国内外均受到青睐。云应用架构的演进促进了微服务和容器化技术，提高了应用的敏捷性和可靠性，但同时也带来了安全挑战。云安全已成为企业关注的焦点，包括保护数据完整性、防止未授权访问及网络攻击等。BAS技术通过模拟攻击行为，帮助识别弱点，提前防范潜在风险。

面对云安全攻击，企业需警惕网络层的账户利用、SSRF权限绕过、应用层的容器逃逸、域内横向、服务层的API欺骗等。必须采用全面的安全策略，最小化颗粒化账户控制，如实施端到端加密、强化认证、进行安全审计等，确保云环境安全可靠。而云服务提供商的安全能力也是企业选型时必须考量的重要因素。接下来探讨一下云安全的几个典型和拓展攻击面。

0x3 攻击

上面讲完了企业云安全的环境现状，那么我们会疑问网络安全攻防与企业云安全具体有哪些相交呢？接下来我们探究一下在实战中我们常常遇到的攻击场景。（PS：仅为个人经验在云原生攻击面上的见解，仍有很多攻击面待补充，还需各位老师考量和指导。）

3.1 AK/SK中的攻击面

随着云原生技术的快速发展，越来越多的组织将自己的业务进行上云操作，在上云的过程中，也会出现一些特殊的安全风险，其中危险性比较大的安全风险就是AK/SK攻击。在云上存在一个特殊的凭证，该凭证被各大云厂商称之为云凭证、SecretKey、访问密钥等，使用该凭证进行云上攻击被称之为AK/SK攻击，它的特点就是当你拥有一个具备权限的SecretKey时，可以使用该SecretKey对云上的存储桶、安全组、域名、容器、无服务函数等服务进行任意增删改查，甚至到服务器中执行命令，而不再依靠于服务器的SSH密码。如下是利用AK/SK的一些攻击手段：

3.2 Kubenets攻击面

Kubernetes的由来可以追溯到谷歌内部的Borg系统。Borg是一个大规模的内部集群管理系统，它运行着来自数千个不同应用程序的数十万个作业。Kubernetes最初源于谷歌内部的Borg，后来谷歌基于Borg系统，采用Go语言重写成了Kubernetes，去掉头尾正好8个字符。这个名字来源于希腊语，意为“舵手”或“领航员”，旨在成为容器编排领域的“舵手”，为容器化应用提供统一的部署、管理和调度服务。Kubernetes的设计目标是消除编排物理/虚拟计算、网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。此外，Kubernetes还支持水平自动伸缩，即根据需要自动增加或减少运行的应用实例的数量，以应对负载的变化。

3.2.1 API Server攻击

当我们获取到Admin Token时，可以操作API Server来控制集群。

也可以把Admin Token放置在~/.kube/config文件中，然后利用命令行工具进行后续操作：

3.2.2 Kubelet 10250端口攻击

Kubelet，作为Kubernetes的一个基础组件，Kubelet扮演着在每个节点上作为代理运行的角色，负责按照PodSpec（容器的运行规范）管理容器的生命周期。它确保定义在PodSpec中的容器正确运行，并且处于健康状态。由于Kubelet在容器上的作用，导致黑客会利用Kubelet上存在的漏洞对云进行攻击。这里介绍一中Kubelet的信息泄露攻击，10250端口是Kubelet API的HTTPS端口，该端口提供了Pod和Node的信息，如果该端口对外开放，攻击者可以利用公开API来获取敏感信息，甚至执行命令。

根据上述获取到的信息在容器中执行命令：

上述命令得到WebSocket地址，连接WebSocket得到命令结果：

当获取到Admin Token后，也可以利用该服务端口在Pod中执行命令：

3.3 Etcd 攻击面

3.3.1 2379端口攻击

Etcd的设计初衷是为了满足分布式系统中的数据一致性问题，通过采用raft协议作为一致性算法来解决多个节点数据一致性的问题，随着云计算技术的发展，传统的物理机运行Etcd的方式逐渐暴露出效率低下的问题。为了应对这一挑战，阿里巴巴等公司开始将Etcd运行环境迁移到云上，利用云服务如ECS、SSD或ESSD存储，从而实现Etcd集群的快速垂直和水平扩展，以及故障迁移的便利性2。这种全面上云的做法不仅提高了Etcd集群的可用性和扩展性，还显著降低了升级时间，使得etcd能够更加稳定地承载业务高峰期的需求。Etcd中存放着Kubernetes集群数据，如果可以成功访问该服务端口，则可以获取集群中的敏感信息，包括Kubernetes Secrets、Admin Token、AKID等。

带着Cert访问Etcd：

CI/CD（持续集成/持续部署）是一种软件开发实践，旨在通过自动化的方式频繁地将代码更改集成到共享仓库中，并确保可以快速、安全地将软件版本部署到生产环境。CI/CD流水线自动化了编码、构建、测试和部署的过程，旨在提高开发效率、降低部署风险并确保高质量的软件发布。以下是几个CI/CD攻击场景介绍：

提取组织使用的GitHub 密钥

供应链攻击：将恶意代码添加到组织使用的其他私有或公共存储库之一，或者通过注入恶意代码或利用第三方依赖中的安全漏洞，攻击者可以在软件构建或部署过程中篡改软件包，进而影响最终用户。

自动化工具的安全漏洞：CI/CD流程依赖于各种自动化工具和平台，这些工具本身的安全漏洞可能被利用来执行代码执行、提权或数据泄露等攻击。

3.5 Docker Swarm攻击面

Docker Swarm是Docker官方提供的容器编排工具，允许用户管理多个Docker主机上的容器，以集群的形式自动部署、扩展和管理容器应用程序。Swarm利用Docker API，为用户提供了一个简单而强大的平台，以实现容器的高可用性和负载均衡。然而，正如任何技术平台一样，Docker Swarm环境也可能面临特定的安全威胁和攻击场景。

如Dump Swarm Secrets、 Abuse Networks Features 、Swarm节点入侵、服务攻击、横向移动，如下是一些关于Docker Swarm攻击场景。

Docker Swarm管理节点：Docker Swarm获取拥有Token后可以管理该Token拥有的元数据权限。进而进行信息收集、权限维持、横向移动等攻击。

Docker Swarm提权Node如果用Promote权限或者滥用Promote权限对相应Docker进行提权

DUMP Docker Swarm Key 攻击者可能尝试利用密钥来执行恶意操作或进入集群网络。一个常见的攻击面是通过非法获取或"dump"（导出）Docker Swarm的加密密钥，这些密钥用于加密集群通信和数据。

如果攻击者能够获取到这些密钥，他们可以伪造节点身份，加入集群，或者拦截和解密集群内的通信。
泄露的密钥允许攻击者执行中间人攻击，监控和篡改敏感信息。
如果集群配置不当，例如管理界面暴露于公共网络，未经授权的用户可能通过网络接口访问密钥。
通过网络钓鱼或其他社会工程手段获得管理员凭证，进而访问密钥管理接口。

Swarm 获取日志信息查看 Docker 服务的实时日志是一种常见的运维操作，它对于监控和诊断服务的运行状态非常有用。然而，这种操作也可能带来一些潜在的安全风险，尤其是在不当的权限管理或配置不当的情况下。以下是这个命令可能带来的攻击面和相应的风险：

日志内容：服务日志可能包含敏感信息，如API密钥、数据库凭证或其他秘密信息。如果攻击者能够访问这些日志，他们可能会利用这些信息进行进一步的攻击。
日志注入：如果应用程序未能正确清理或验证其输出，攻击者可能通过注入恶意内容到日志中来欺骗查看日志的用户或触发日志处理系统的漏洞。
滥用权限导致信息泄露：拥有查看日志权限的用户可能会滥用这一权限来监控和收集不应该访问的信息。

3.6 内核型eBPF攻击面

利用eBPF进行容器逃逸是一种高级的网络安全技术，它允许攻击者在容器内部执行恶意操作，从而绕过传统的安全措施。eBPF（扩展性伯克利包过滤器）是一种强大的内核扩展，它提供了一种机制来监控和修改系统调用、网络包等。通过eBPF，攻击者可以在不被检测的情况下执行容器逃逸。

图为 eBPF Cross Container Attacks (CVE-2022-42150) 滥用过程

eBPF还能实现：eBPF 劫持 Kubelet 进行容器逃逸\利用HIDS使用的sys_bpf_admin账户进行容器逃逸\eBPF利用Static Pod进行容器逃逸\SYN后门等，知其安正在持续开发相关安全验证用例中。

3.7 云域攻击面

Consent Grant Attacks：

诱导高权限用户的同意授予攻击案例：Get-AzureADPSPermissions

滥用 Microsoft Entra Connect 同步服务帐户主要包含以下场景：

使用将目录角色分配给“混合标识管理员”以管理 Microsoft Entra Connect 配置来攻击管理帐户
滥用 Azure AD 用户“本地目录同步服务帐户”，该帐户将用于将对象从 Microsoft Entra Connect （AADC）服务器（本地 AD）同步到 Azure AD。
重播访问令牌：通过截获了设备上浏览器的请求令牌、截获合规设备上 PowerShell 等进程的流量等操作以获取对受害者账户或资源的未经授权的访问权限。

3.8 虚拟化攻击面

3.8.1 虚拟机中：

沙箱对抗场景：攻击者通过检测虚拟机环境的特征（如特定文件存在性、硬件指针行为、CPU温度或通过WMI访问BIOS信息）以及修改IDT、LDT、GDT等底层数据结构，来识别并规避沙箱环境，避免恶意行为被分析

PWN场景：

用户态PWN
内核态PWN

逃逸系列：

虚拟机逃逸：虚拟机逃逸指的是攻击者从虚拟机内部突破隔离机制，直接影响宿主机或其他虚拟机的行为，获得更广泛的系统访问权限。
QEMU逃逸：利用QEMU模拟器的漏洞，攻击者能够从受限的虚拟环境中逃逸出来，影响或控制宿主操作系统。

3.8.2 其他虚拟化的攻防面：

VMTools投毒：攻击者通过篡改或利用虚拟机工具（如VMware Tools）的漏洞，执行恶意代码或操作，破坏虚拟机的正常功能。

NAS系统存储虚拟化攻击：在网络附加存储（NAS）的虚拟化环境中，攻击者可能针对共享存储资源发起攻击，破坏数据完整性或可用性。示例：Blackhat 2023中《利用云攻击面入侵任意的NAS设备》攻击者通过分析群辉和西部数据两个 NAS 设备的漏洞，发现了设备接入验证不足并可以进行绕过的漏洞，配合团队发现的云中开放的成千上百万台NAS机器的GUID未授权获取和任意命令执行漏洞，攻击者可以远程入侵这些 NAS 设备，造成严重的安全风险。

Vmvare vSphere攻防、KVM、XEN、Vmware Esxi、Rhev Hypervisor、Hyper-v Server VirtualBox Paralles Desktop：对Vmware vSphere、KVM、XEN、Vmware Esxi、Rhev Hypervisor、Hyper-V Server、VirtualBox、Parallels Desktop等不同的Hypervisor进行批量用例测试，以发现特定于平台的安全漏洞和缺陷

硬件虚拟化攻防：在硬件虚拟化技术中，攻击者可能利用硬件辅助虚拟化功能（如Intel VT-x、AMD-V）的漏洞来执行攻击，影响虚拟化环境的安全性。

OpenStack攻防：针对OpenStack这一开源云计算平台，攻击者可能探索API、配置错误或组件之间的交互漏洞，以实施对云资源的未授权访问或干扰。

3.9 Terreform攻击面

Terraform 可以调用云厂商的 AK/SK 进行云服务资源的创建与获取 Tecent-Terreform-yaml支持local-exec参数执行命令权限等，如果参数可控我们可以利用该账户来执行我们的恶意代码，详见YAML如下图：

3.10 小结：

基于上述攻击面和手段，云安全防御策略需要围绕认证机制的加固、权限最小化原则、安全监控与响应、供应链安全、容器与虚拟化环境的安全加固等方面进行综合考量。具体包括但不限于：

加固认证机制：加强对AK/SK等敏感信息的保护，实施多因素认证等。可以通过IDaaS、访问控制RAM/IAM实现。

实施权限最小化：精细化权限管理，确保每个服务和用户仅拥有完成其任务所需的最少权限。可以通过CIEM (云基础设施实体管理)、CASB (云访问安全代理)等服务来实现。

安全监控与响应：建立全面的监控体系，对异常行为进行实时监控和快速响应。可以通过CWPP (云工作负载保护平台)等服务实时监控和安全策略管理，对服务器、虚拟机、容器等工作负载进行保护。

供应链安全：加强对第三方组件的审计和管理，确保CI/CD流程的安全性。这里可以通过IAC扫描检测云端代码和配置文件中的安全问题，例如在CI/CD流程中，审查Terraform、CloudFormation、Kubernetes配置，确保第三方组件的安全性。

容器与虚拟化安全加固：采取措施防止容器逃逸和虚拟化技术漏洞的利用。这里可以采用容器扫描、虚拟化技术监控来进行防护。

另外在云计算环境中，安全责任分担模型是云服务提供商（CSP）和云服务用户（客户）之间共享安全责任的框架。这个模型明确了哪些安全措施由云服务提供商负责，哪些需要用户来执行。理解这一模型对于确保云环境的安全至关重要。云服务提供商主要负责保护云计算基础设施的安全，这包括但不限于：物理安全、网络安全、硬件和软件的基础结构、虚拟化安全、运营安全等。用户的责任主要集中在自己部署在云上的数据和应用程序的安全，具体包括：数据安全、访问控制、操作安全、监控和响应。

那么接下来我会和大家探讨防御侧现有的一些服务和手段。

0x4 防御

现阶段的云安全产品体现了云计算环境日益复杂和多样化的安全需求，它们的设计和功能反映出对云工作负载的全面保护、跨平台集成能力以及自动化安全运维的趋势。以下是这些云安全产品共有的一些综合特点：全生命周期保护、自动化的安全运维、综合安全防护能力、合规与监管支持、实时监控与预警、多层次安全策略。下面是基于云安全产品上的不同防御视角的相关要素进行介绍。

(PS：仅为个人经验在云原生防御上的见解，仍有很多防御视角待补充，还需各位老师考量和指导。)

4.1 基础防御

4.1.1 基于责任分担模型的缓解方式

图片取自：微软的《云中责任分担模型》

加强合作：云服务用户应充分利用云服务提供商提供的安全工具和服务，如AWS的CloudTrail、Azure的Security Center等，以加强安全监控和事件响应能力。

定期安全评估：用户应定期进行安全评估，包括渗透测试和漏洞扫描，以发现和修复潜在的安全漏洞。

数据加密：用户应加密存储在云上的数据，并对数据传输使用SSL/TLS等安全协议。

多因素认证：实施多因素认证（MFA）增加账户的安全性。

安全意识培训：培训员工关于云安全最佳实践，提高对钓鱼攻击等社交工程攻击的意识。

遵循安全标准和合规性：遵守行业安全标准（如ISO 27001、GDPR）和云安全最佳实践。

4.1.2 密钥防御

采自：阿里云-AK和账密防泄漏最佳实践

防泄露层面：选择具有时效性的临时Token提供给产品使用，各大平台增加AK/SK特征检测规则，如Github的token-scan功能，自动化的对在Github上泄漏的AccessKey进行高效和精准地检测。

AK泄露检测：类似Chrome的浏览器密钥检测，利用平台自身收集的情报，规则匹配AK是否泄露至公网。

黑客利用检测：针对黑客利用AK/SK进行异常行为攻击时比如"创建云函数执行恶意代码"等情况进行特征匹配，采用打分机制来检测。

4.1.3 Severless防护：

Severless-WAF (AWS服务将WAF与API Gateway结合，通过AWS CloudFormation模板定义WAF规则来提供保护。另外，Imperva的Serverless Protection提供了一个额外的保护层，能够通过AWS Lambda层部署，实现类似WAF的效果)

4.1.4 IAC扫描：

(在Terraform、CloudFormation、Kubernetes、Serverless Framework和其他基础设施的构建期间，如需要配置YAML文件，根据字符串匹配等功能检测出云端代码安全问题。)。IAC扫描往往会包含各个公有云的IAC代码扫描、Kubernetes Mainfest、Dockerfile等文件的代码扫描，从文件中发现不安全的配置项，进而提醒用户进行修复，由于IAC文件往往采用声明式方法，编码方式相对固定，比传统的代码扫描更进一步，能有效在容器安全、云安全相关应用的构建期间进行检测,因此Paloalto等大厂均提供IAC代码一键修复的功能。

开源IAC扫描工具Checkov

4.1.5 容器扫描和镜像漏洞扫描：

容器扫描是一种安全实践，用于识别容器镜像中的漏洞和配置问题，确保容器化应用的安全。这一过程对云安全至关重要，比如在DevSecOps中的CI/CD环节会应用到镜像漏洞检测，因为它有助于防止恶意软件或攻击者利用这些漏洞来攻击云基础设施。

采取密钥防御手段,能有效检测AK/SK利用、Terrform利用等攻击行为或者相关密钥的泄露。

4.2 综合平台

4.2.1 CSPM（云安全态势管理）：

通过自动化工具对云环境进行持续监控和评估，确保云配置的安全性和合规性，及时发现并修复配置错误。CSPM正在日渐综合化，如Paloalt-CSPM通过机器学习增强的威胁检测、网络威胁检测、用户实体行为分析（UEBA）来补充传统安全策略，提高威胁发现的效率。最终，通过整合数据安全功能，CSPM为企业提供了一个综合的解决方案，在Kubernets攻击、CI/CD攻击、云域攻击上针对防护，以应对云原生环境中的复杂安全挑战。

此图取自Palo Alto Networks - 安全合规视角

此图取自Palo Alto Networks - 安全经理监管视角

4.2.2 CWPP（云工作负载保护平台）：

CWPP通常包括多种安全功能和工具，如防火墙、入侵检测系统（IDS）、入侵防御系统（IPS）、端点检测与响应（EDR）工具等，都是为了构建起云计算环境中的综合安全防线。通过这种分层的安全策略，企业能够对抗从基础设施到应用层的各种网络攻击和内部威胁，确保业务连续性和数据保密性。旨在保护云中的服务器、虚拟机、容器等工作负载，通过实时监控和安全策略管理减少安全威胁。

从图中可以看出，CWPP采用分层防御策略：

基础设施保护层：这层关注于基础的网络和主机层面的安全，通常涉及网络分割、主机基线安全配置、虚拟化平台安全控制和系统的漏洞管理。这层的安全措施是为了防止未授权访问，以及减少操作系统和物理硬件漏洞的攻击面。

平台保护层：关注于容器化和服务编排框架（如Kubernetes）的安全。在这一层，安全实践包括容器镜像扫描，容器运行时安全，以及编排系统的访问控制和配置管理。

应用和数据保护层：这层专注于应用程序代码的安全性和数据保护。这涉及应用层的安全审计，如代码静态分析和动态分析，以及数据加密和密钥管理策略，以确保敏感数据的机密性和完整性。

身份和访问管理层：这是最高层，涉及用户身份验证、授权和审计。它包括多因素身份验证，角色基础的访问控制（RBAC），以及权限最小化原则，以确保只有必要和授权的操作能被执行。

在实现CWPP策略时，组织通常会集成一系列的安全工具和服务，如下：

终端检测与响应（EDR）：监测和响应端点设备上的威胁活动。

主机入侵防御系统（HIPS）：在主机级别上防御未授权或恶意行为。

安全信息与事件管理（SIEM）：为了集中的可见性和事件响应，收集、分析和报告安全相关数据。

配置管理和漏洞评估：持续监控配置的变更和潜在的安全漏洞。

网络流量分析和防火墙：用于检测异常网络流量和限制网络访问。

API安全和Web应用防火墙（WAF）：保护API和Web应用程序免受攻击。

图中自下而上展示了从基础设施到数据和应用的多层防护机制，以及它们之间的关系。图底部是基础设施层，包含物理设备和虚拟化层。在这层中，安全措施包括但不限于网络隔离、主机防护、操作系统安全和对虚拟化基础设施的保护。接下来是平台层，涉及到容器和编排工具的安全，例如Kubernetes的安全策略和容器安全。再上一层是应用和数据层，这里的安全措施专注于保护存储在云中的数据，以及确保应用程序代码的安全，包括API安全和执行数据加密。最上层是用户身份和访问管理，这是确保只有授权用户能够访问和管理云资源的重要机制。

整个结构的侧面是风险程度，从底部的较低风险逐渐上升到顶部的高风险。这表示随着从基础架构到数据层的移动，需要对抗的威胁变得越来越复杂，对安全措施的需求也相应增高。

4.2.3 CIEM（云基础设施实体管理）：

专注于识别和管理云环境中的身份和访问权限，以确保最小权限原则，防止不当访问造成的风险。借助 CIEM 解决方案，安全团队可以管理云标识、授权，并强制执行对云基础设施和资源的最低特权访问原则。CIEM 解决方案可帮助企业减少云攻击面，并降低权限过多带来的访问风险。

这张图展示的是一个云基础设施权限管理（CIEM）系统的概念架构。从左侧的“NEW IDENTITIES”出发，不同类型的新身份（例如用户、服务账号等）通过集中的身份验证和权限分配系统，获得对不同云服务资源的访问权限。

这个系统的中心是一个权限数据存储和处理的服务，负责身份验证和权限的分配。它连接到多种云服务，例如存储、基础设施即服务（IaaS）、平台即服务（PaaS）、镜像和数据库，每个服务都通过多条线连接到中心，代表不同的访问权限。图中的不同颜色的线表示不同级别的访问权限或不同类型的权限，说明系统如何精确地管理和审计每种身份的权限。这反映了CIEM系统中权限发现、优化、异常检测和政策管理等功能。通过这样的系统，组织可以确保每个身份都仅具有其执行任务所需的最少权限，有助于减少安全风险并确保合规。

4.2.4 CASB（云访问安全代理）

而CASB则覆盖了SaaS、PaaS、IaaS三个区域，但是主要覆盖面积体现在SaaS上，CASB核心价值是解决深度可视化、数据安全、威胁防护、合规性这四类问题。

深度可视化—CASB提供了影子IT发现、组织机构云服务格局的统一视图以及从任何设备或位置访问云服务中数据的用户的详细信息。

数据安全性—CASB能够实施以数据为中心的安全策略，以防止基于数据分类、数据发现以及因监控敏感数据访问或提升权限等用户活动而进行有害活动。通常是通过审计、警报、阻止、隔离、删除和只读等控制措施来实施策略。DLP（数据丢失防护）功能很普遍，并且是仅次于可视化的最常用的一项控制措施。

威胁防护—CASB通过提供AAC来防止有害设备、用户和应用程序版本来访问云服务。可以根据登录期间和登录之后观察到的信号来更改云应用程序功能。CASB此类功能的其他示例包括通过嵌入式UEBA识别异常行为、威胁情报、网络沙箱以及恶意软件识别和缓解。

合规性—CASB可帮助组织机构证明，是组织机构在管理云服务的使用情况。CASB提供了信息来确定云风险偏好并确定云风险承受能力。通过各种可视化、控制和报告功能，CASB有助于满足数据驻留和法律合规性要求。

云访问安全代理（CASB）的两种工作模式：API模式和代理模式，这两种模式是在企业环境中保护数据并实现云服务的合规性管理的常用方法。

API模式

在API模式下，CASB通过与云服务提供商的API直接集成，来监视和控制数据的使用和安全。这里展示了三种不同的云服务：BOX、Office 365和Salesforce，它们都与CASB通过API连接。在这种模式下，CASB可以实现如下功能：

数据安全：监测和保护存储在云服务中的数据，例如通过数据丢失预防（DLP）策略。

威胁防护：通过分析用户活动和配置设置，检测并防止潜在的威胁。

合规性监管：确保云服务的使用符合行业标准和法规要求，例如GDPR。

身份管理：监控和管理用户身份和权限，以实现最小权限原则。

可见性和报告：提供关于数据访问和用户活动的详细报告。

代理模式

在代理模式下，CASB充当用户和云服务之间的中介。所有的流量都会经过CASB的代理服务器，这允许CASB实施实时的数据安全和合规性政策。与API模式不同，代理模式可以控制实时的会话和交易，因此它能够提供：

实时数据和威胁防护：通过拦截并分析传输中的数据来防止数据泄露和即时威胁。

访问控制：根据用户的角色和上下文实施访问策略，例如限制来自非信任设备的访问。

加密和标记：在数据传输到云服务之前对其进行加密，或者对敏感数据进行标记。

可见性：提供对所有通过CASB代理的流量的可见性，以监控和分析用户行为。

数据和应用防火墙：作为安全屏障，保护内部网络不受外部威胁的影响。

这张图中还可以看出，不同类型的设备（移动设备和企业设备）都可以通过这两种模式与CASB集成，从而确保企业内外的数据都受到保护。

小结：

了解了各种云安全技术（如CSPM、CWPP、CIEM、CASB）之后，我们明确了它们各自在云环境安全防护中的独特作用。这些技术覆盖了从云配置、工作负载保护、身份管理到访问控制等多个层面，为企业提供了一个全面的防护体系。然而，甲方在实施这些安全策略时仍面临诸多挑战，主要集中在持续监控的资源消耗、多样化攻击面的防护、内部资源的安全保障以及高昂的安全操作成本上。

0x5 知其安云安全有效性验证措施

如上我们了解到了与云安全、容器安全各种攻击面和防御视角。那么我们怎么提高自己的安全能力去检测、拦截、及时对这些攻击进行应急服务呢？参加内部组织演练是一个不错的方法，但是会消耗很多人力，能耗，时间成本，而且甚至会对内部资源或者系统造成破坏，那么我们如何做到在不影响业务和安全的情况下进行攻击并对这些攻击进行验证来降低安全运营成本、提高安全运营能力呢？这个时候安全有效性验证应运而生，安全有效性验证的子模块——BAS，运用其独特的模拟攻击和验证技术，对云安全的各类场景进行验证。同时提供全天候自动化评估自查功能，并给出安全加固建议，从而确保安全防御体系的高效运营。

BAS在云环境中的验证通常涉及几个关键步骤和策略，可以分点如下：

虚拟攻击：

攻击方式：使用BAS工具模拟各种攻击，比如应用程序漏洞利用、Web Shell上传、恶意软件下载等。

产品对应：使用离朱-安全验证平台来模拟这些攻击并测试组织的防御能力。

入侵（Infiltration）：

攻击方式：通过互联网进行应用漏洞传输、Web Shell传输和恶意软件下载等。

产品对应：离朱-安全验证平台可以模拟这些攻击来验证云环境中防火墙、入侵检测和防御系统的有效性。

服务器区（Server Zone）：

攻击方式：包括Docker逃逸、文件系统绕过、资源滥用、系统信息搜集、秘密/凭证盗窃等。

产品对应：离朱-安全验证平台可以对这些区域执行模拟攻击来测试云基础设施的安全性，以及相关安全控制的配置是否正确。

横向移动（Lateral Movement）：

攻击方式：包括暴力破解、恶意软件传播、本地利用漏洞、远程控制、网络信息搜集等。

产品对应：离朱-安全验证平台可以模拟这些攻击以验证网络隔离和内部安全控制的有效性。

数据泄露（Data Exfiltration）：

攻击方式：通过合法通道和隐秘通道泄露数据。

产品对应：离朱-安全验证平台可以测试数据泄露防护措施，确保敏感数据不会通过网络传输途径被未授权访问。

攻击路线模拟

攻击方式：重点在于横向移动后获取高价值资产和数据。

产品对应：使用离朱-安全验证平台来模拟攻击者的行动路线，从而验证对最敏感和关键资源的保护。

根据团队内大佬们多年甲方安全攻防经验，从基于不同的安全视角进行验证场景区分，如终端安全、主机安全、容器安全。再从不同的攻击视角区分各类攻击手段，如暴力破解场景，云安全密钥泄露场景。最后从不同攻击点和验证方式来区分单个用例的标签颗粒度，如容器逃逸。简单来说："一个场景，就是一个验证主题，就是回答“某一块的防护能力做的怎么样”的一系列用例集合”。

目前已经上线如下场景：

5.1 容器安全矩阵

MITRE ATT&CK Matrix for Containers提供了关于恶意软件攻击者如何利用容器（如Docker和Kubernetes）环境的行为模式和技术的综合概述。这个矩阵是为了帮助安全专家更好地理解和防御容器环境中的攻击。尽管我不能提供最新的内容，以下是根据我最后更新的知识（截至2023年4月），ATT&CK矩阵针对容器环境通常包含的一些关键领域：

初始访问：描述攻击者如何获得对容器环境的初始访问权限，可能通过诸如利用公开服务、钓鱼攻击或使用有效的账户等方式。

执行：涉及攻击者在容器环境中执行恶意代码的技术，包括直接代码执行、脚本利用或利用容器本身的特性来执行恶意操作。

持久性：描述攻击者如何在容器环境中保持其存在，可能通过修改容器配置、创建新的或恶意的容器镜像等方法。

权限提升：涵盖攻击者如何从其初始访问点提升到更高权限级别的技术，可能包括利用容器逃逸漏洞、利用系统漏洞等。

防御绕过：包括攻击者采取的措施来避免被安全工具或监控措施检测到，例如通过修改容器镜像来隐藏恶意软件、利用加密或混淆技术等。

信标：涉及攻击者与外部服务器或控制系统进行通信的技术，以控制被攻击的容器或传输数据。

信息收集：描述攻击者如何在容器环境中搜集信息，可能包括搜索敏感文件、收集配置信息或枚举网络资源等。

横向移动：涉及攻击者如何在容器环境内部或与外部系统之间移动，以扩大其攻击范围，可能通过利用网络连接、窃取凭证等方式进行。

影响：描述攻击者如何对容器环境造成影响，包括数据破坏、服务中断或资源滥用等。

取自：MATRICES 容器安全矩阵图

知其安已覆盖容器ATT&CK矩阵中的初始访问、执行、权限维持、特权提升、防御规避、凭据访问、发现、横向移动、影响等场景的相关用例已达到85%。由于众多场景都具有自身独特的危害性、防御手段和实现方式，我们会定制化为各类场景、各种用例在尽量减少代码重构(降低资源消耗)的情况下提供定制化开发方式。

下面举例一下2024年三月底出的容器提权漏洞CVE-2024-1086，该漏洞是Linux的Netfilter网络内核控件的子函数存在双重释放漏洞，导致可以利用提权，由于Netfiler的普及性，该漏洞影响了大部分高版本内核(v5.14 – v6.6)。其特征会在进程文件中加入session通道来提权给当前窗口使用。

我们会利用自动化的方式启动复现环境，并在环境中进行提权模拟行为，并基于此模拟行为的结果来自动化的验证安全能力设备的检测能力。通过启动模拟环境，我们不仅能够解决宿主机可能不存在该漏洞环境的问题，还能确保整个处理过程的无害化。此外，我们还解决了CVE-2024-1086中因netfiler提权时网络环境（如ssh或反弹shell）导致session不稳定的问题。最后通过agent自动化删除容器、agent自动化清理进程等方式对相关影响进行清理、完成闭环。

还有用例比如以CVE-2024-21626为例，在漏洞曝光后，我们迅速响应，不仅完成了内部实现，并调研出多种开发方案。我们同时开发并上线了两种类型的用例，分别是用于模拟和验证该漏洞利用的Docker版本和Kubernetes版本，以支持用户在不同环境中进行安全测试。并给予详细的漏洞信息和验证信息：在受影响的RunC版本中，初始化过程中泄露了部分内部文件描述符，其中包括对宿主机的 /sys/fs/cgroup 的句柄。同时，RunC在设置容器的最终工作目录时未能正确验证该目录是否位于容器的挂载命名空间内。攻击者可以通过修改 process.cwd 配置项为 /proc/self/fd/7，或在调用 runc exec 时通过 --cwd 参数传入特定路径（如 /proc/self/fd/7/ 的符号链接），使得容器内的进程能够访问和操作宿主机的文件系统。这种操作绕过了容器的隔离机制，允许攻击者执行未授权的命令或访问敏感信息，导致安全隔离被破坏。

我们会定制化开发存在该漏洞的轻量容器，并且利用漏洞本身原理直接验证我们是否成功利用该逃逸漏洞。最后通过agent自动化删除容器、agent自动化清理进程等方式对相关影响进行清理。并提供相关可以增强的安全能力点。

5.2 Kubernetes矩阵

Kubernetes攻击矩阵（Kubernetes ATT&CK Matrix），受到了MITRE ATT&CK框架的启发，专门针对Kubernetes环境的安全威胁和攻击方法进行分类。它为安全研究人员、系统管理员和安全团队提供了一个参考框架，用以识别和防御针对Kubernetes集群的潜在攻击。

Kubernetes攻击矩阵覆盖了从初始访问到执行、持久化、特权升级、防御规避、凭据访问、发现、横向移动、集合、命令与控制等不同阶段的攻击技术。以下是一些主要的内容概览：

初始访问：攻击者如何获得对Kubernetes集群的初始访问，例如通过公开的未经认证的Kubernetes API服务器、利用弱或默认的凭据、通过钓鱼攻击等。

执行：攻击者在获得对集群的访问权限后，如何在Kubernetes集群内执行恶意代码或命令。

持久化：攻击者如何在集群中保持其访问权，例如通过创建或劫持Kubernetes资源（如Deployments、Pods、CronJobs）来确保恶意载荷在系统重启后仍能执行。

特权升级：攻击者如何提升其在集群中的权限，比如通过利用Kubernetes集群中的漏洞或配置错误。

防御规避：攻击者如何规避集群中的安全机制，例如修改日志文件以隐藏其活动、或禁用安全插件。

凭据访问：攻击者如何访问和窃取Kubernetes集群的认证信息，例如API密钥、服务账户令牌等。

发现：攻击者如何在获取对集群的访问后，探索和识别Kubernetes集群的架构和运行的应用程序。

横向移动：攻击者如何从一个资源移动到另一个资源，例如从一个受感染的Pod访问其他Pod或服务。

集合：攻击者如何收集并抽取目标数据或信息，例如从Kubernetes集群中收集敏感文件或数据。

命令与控制（C2）：攻击者如何控制和管理在Kubernetes集群中部署的恶意软件，例如通过外部服务器与恶意Pod进行通信。

影响：描述攻击者如何通过破坏、数据泄露、或对集群资源的控制来实现其目标。

取自：MATRICES Kubernetes矩阵图

知其安已覆盖微软Kubernetes云ATT&CK矩阵中的初始访问、执行、权限维持、特权提升、防御规避、凭据访问、发现、横向移动、影响等场景。由于众多场景都具有自身独特的危害性、防御手段和实现方式，我们会定制化为各类场景、各种用例在尽量减少代码重构(降低资源消耗)的情况下提供定制化开发方式。

下面举例一下一个典型的的Kubernetes逃逸漏洞CVE-2021-25741，该漏洞利用了Symlink的链接符号交换漏洞来挂载宿主容器目录等攻击, 该漏洞利用难度高，需要利用制造竞态条件攻击来绕过前版本的修复补丁。

因此，我们将通过自动化的方式启动复现环境，并在其中进行提权模拟行为。为了验证安全能力设备的检测能力，我们将通过判断宿主文件是否成功被挂载来评估逃逸情况。启动模拟环境不仅解决了宿主机可能不存在该漏洞环境的问题，还能确保整个处理过程的无害化。此外，我们还解决了在利用过程中由于条件竞争时间过长导致的逃逸难以验证的难题。最后，我们将通过agent自动化删除pod、清理进程等方式，对相关影响进行彻底清理。同时，我们还将提供可增强的安全能力点，以进一步提升系统的安全防护水平。

5.3 ATT&CK 云矩阵

MITRE ATT&CK云矩阵是针对云环境（包括基础设施即服务IaaS、平台即服务PaaS和软件即服务SaaS）的攻击行为模式的扩展，它提供了一系列针对云平台的攻击技术和战术。这个矩阵涵盖了从初始访问到执行、持久化、特权升级、防御绕过、凭证访问、发现、横向移动、收集、命令和控制，以及影响等多个方面的技术。云矩阵特别强调了在云环境中可能遇到的唯一攻击向量和策略。

以下是云矩阵中一些关键的攻击场景：

利用云服务配置错误：攻击者可能会利用云服务配置不当（例如，错误配置的存储桶或数据库）来获得未授权的数据访问或泄露敏感信息。

凭证访问和滥用：云环境依赖于复杂的凭证管理系统，攻击者可能会试图获取这些凭证来获得对云资源的访问权，或者利用云服务的合法凭证进行横向移动。

利用云原生技术：攻击者可能会针对容器管理系统（如Kubernetes）或无服务器架构（如AWS Lambda）中的漏洞或配置不当进行攻击。

创建和滥用资源：攻击者可能会在云环境中创建恶意资源，如虚拟机、容器或函数，来执行攻击活动或作为跳板进行进一步的攻击。

跨租户攻击：在多租户云环境中，攻击者可能会尝试从其他租户那里提升权限或窃取数据。

元数据服务滥用：云服务的元数据服务包含着丰富的环境信息和凭证，攻击者可能会尝试访问这些服务来提升权限或获取敏感信息。

API滥用：由于云环境大量依赖API进行操作和管理，攻击者可能会利用不安全的API来执行未授权的操作或获取敏感数据。

取自：MATRICES ATT&CK 云矩阵图

知其安已覆盖微软ATT&CK云矩阵中的初始访问、执行、权限维持、特权提升、防御规避、凭据访问、发现、横向移动、影响等场景。由于众多场景都具有自身独特的危害性、防御手段和实现方式，我们会定制化为各类场景、各种用例在尽量减少代码重构(降低资源消耗)的情况下提供定制化开发方式，下面介绍一下利用云函数执行危险命令攻击这类用例。

离朱-安全验证平台会有以下实现逻辑：(支持攻击链视角和直接利用视角)

部署恶意函数：

攻击者如果控制了客户账号或权限，可以部署恶意Lambda函数。

这些函数可能会避开云平台管理和操作系统、网络配置的安全措施，因为它们工作在应用层面。

恶意函数可能会在云存储和数据库资源上执行危险操作，如删除数据或窃取信息。

触发执行：

恶意函数可以通过互联网访问、事件触发器或直接调用来执行。

例如，如果攻击者可以上传一个文件到云存储桶，这个文件的上传可以触发一个Lambda函数的执行。

验证闭环：

这时候BAS会检查网络日志、API调用记录等方式来验证攻击是否成功。

清理阶段：

删除恶意函数和所需要的相关新建角色。

并且恢复任何临时增加的权限设置。

0x6 总结

云安全攻击面的多样性要求企业采取全面的防御策略。攻击场景如AK/SK利用、Kubernetes攻击、Etcd侵害、CI/CD流程攻击、Docker Swarm漏洞、eBPF容器逃逸及虚拟化平台漏洞显示了攻防复杂性。通过BAS在不影响业务和安全的前提下，可以有效地检测、拦截和应对安全威胁。利用离朱-安全验证平台的BAS模块可以模拟云函数执行危险命令攻击，并在安全测试中验证防护措施的效果。这种实践不仅减低了安全运营成本，也提高了安全运营能力，为企业云安全策略的制定和执行提供了有力支撑。