云原生安全攻防启示录

随着企业业务架构日益云化，面向云原生的攻防越来越多地出现在我们的视野中，面对复杂的云上业务体系如何有效切入攻击入口。本文将体系化探讨云原生环境下相关的攻击手法及策略，重点关注现代云环境中云平台、集群等相关的攻击技术。

本文将从4C’ 云原生安全、云上身份攻击、从K8s到Cloud、攻防启示四部分展开，详细描述在云原生体系下的威胁发现与攻击思路。

4C’ 云原生安全

云原生安全是一种综合性的安全理念和实践，确保在云环境中构建、部署和运行应用程序时的安全性。随着企业越来越多地采用云计算和容器化技术，云原生安全变得至关重要，以保护云基础设施、应用程序和数据免受各种威胁和攻击。

公认的云原生安全分为4个方面，分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。这种分层方法增强了深度防护方法在安全性方面的防御能力，该方法被广泛认为是保护软件系统的最佳实践

图一：云原生安全四层架构

云原生安全是一种综合性的安全理念和实践，确保在云环境中构建、部署和运行应用程序时的安全性。随着企业越来越多地采用云计算和容器化技术，云原生安全变得至关重要，以保护云基础设施、应用程序和数据免受各种威胁和攻击。

01 : 4C’ 云原生安全-Cloud

针对云平台的安全风险有以下几点:

• 身份和访问管理漏洞。

• API滥用和未经授权访问。

• 云产品信任关系滥用。例如云上的OOS、云服务器、VPC等信任关系也会存在滥用。

• API密钥泄露。例如AK/SK的利用。

• 云平台元数据滥用。

• 身份冒用。

图二:常见的云平台

02 : 4C’ 云原生安全-Cluster

k8s目前已成为云原生的基础设施，攻击手法也表现出了多样化。常见的K8s的攻击手法有以下几点：

• 多租户隔离漏洞。

• Secrets对象滥用。

• 服务间未授权访问。

• APIServer未授权访问。

• K8s自身漏洞。

• 错误配置。

图三:常见的集群层

03 : 4C’ 云原生安全-Container & Code

云原生中的代码和容器是云原生中目前主要的攻击面，容器的安全问题不仅仅涉及到应用层面的安全，也包括底层基础设施的安全，如主机、网络和存储等方面。常见的容器和代码攻击手法如下：

• 镜像漏洞。

• 容器逃逸。

• 内核漏洞。

• 错误配置。

• 应用程序漏洞(Code层)。

图四:云原生中Code和Container

云上身份攻击

云上身份指的是在云计算环境中管理和控制用户、系统或服务访问资源的方式。它涉及身份验证、授权和访问管理，通常由身份提供商或身份管理系统来实现。在云环境中，身份可以是用户、应用程序、设备或服务的标识。身份验证确认谁可以访问资源，授权定义了访问权限，而访问管理则监控和控制这些权限的使用。

为了有效的实现用户对云上身份的管理，以确保之后授权用户能后访问相应的资源，提出了基于身份控制策略，通过策略授权来界定用户能够访问的资源和操作。基于身份的策略附加到 IAM 用户、组或角色。这些策略可让您指定该身份可执行哪些操作。

图五:基于身份的控制策略

云平台的基于身份的控制策略配置如下图所示，在此图中可以得到以下信息：

• "Effect":"Allow"项代表对于目标资源的允许或拒绝策略。

• "Resource":"arn:aws:s3::bucket",代表最终的目标资源。

• "IpAddress":{"aws:SourceIp":"192.168.1.6"}，代表对来自特定ip地址(192.168.1.6)的请求限制。

图六:基于身份的策略配置

01 : 基于资源的策略

身份控制策略仅基于角色、组和权限来定义访问权限，无法限制对特定云资源的控制。为确保资源只被授权实体访问和使用，我们将采用基于资源的控制策略。基于资源的控制策略关注于资源本身的安全性和访问规则。它们确保资源被安全地访问和使用。这种策略可以定义哪些资源可以被访问、何时可以访问、如何访问以及访问时所需的权限。下面将简要介绍这种基于资源的策略的优势。

如下所示目前有三台服务器，这三台服务器都去访问S3存储。此时有个角色会允许所有的云服务器去访问s3的存储。

随着业务变更，我们需要禁止某台服务器访问 S3 存储。在这种情况下，需要调整服务器的角色分配，不再包括与 S3 存储相关的角色。然而，由于角色涉及多个方面，例如用户操作存储桶、控制 VPC、管理 CDN 等，简单地将服务器从当前角色移除可能不是一种有效的方法。

在这种情况下，云平台上的基于资源的策略发挥了关键作用。通过为存储桶本身新增一个拒绝 EC2 操作访问策略，以使该存储桶能够拒绝某台服务器的访问。

如下表示基于资源的控制策略用途。

如下图可以看到某个存储桶分配给账户一些权限角色。

云平台的基于资源的控制策略配置如下图所示，在此图中可以得到以下信息：

• "Effect":"Allow"项代表对于目标资源的允许或拒绝策略。

• "Resource":"arn:aws:s3::bucket",代表最终的目标资源。

• "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}}，代表访问策略将会限制对于 ACL 设置为public-read的 S3 存储桶的访问权限。

02 : 基于资源的策略攻击思路

如果攻击者在云环境中面临严格的权限划分。此时的目标应该转移到对目标资源具有控制权的角色上。

如果成功控制了一个角色，其中包含100个用户，就可以选择控制该角色下的特定用户，然后利用这个用户的凭证尝试访问特定的存储桶（bucket）。然而，从前述案例可以看出，存储桶本身也具有一层权限控制。如果控制的账户能够访问存储桶，但该存储桶对许多用户都开放了访问权限，那么攻击目标可能更应该放在存储桶上而不仅仅是特定用户。因此，在这种情况下，我们不能仅仅从已经控制的账户出发，还需要考虑目标允许哪些用户对其进行操作。

综上，将基于资源的攻击思路总结为以下几点：

• 如果权限细化的非常严格，则敏感角色是我们有限攻击目标。

• 权限过高则则将目标放在资源上。

• 即使一个账户没有任何权限，依然可以对配置基于资源的策略对象进行操作

因此，在获得一个身份后，需要深入关注其身份策略和以及它可执行的操作。同时，我们必须注意到在环境中可能存在许多资源，这些资源可能具有预置的权限信任关系，允许云平台中的多个账户进行访问，例如S3存储桶。这些存储桶可能允许云平台账户和服务对其进行访问。但是，当获取了某个账户时，我们并不能直观地看到S3存储桶是否允许某个服务进行访问，这些信息只有在审计账户权限时才能得知。因此，在云环境中进行权限审计(自身账户权限的审计以及所有业务的审计)变得尤为重要。在获取一个用户的控制权后，了解它在云平台上涉及的各种业务（如S3、云服务、VPC、CDN等）也是至关重要的。

一旦通过漏洞成功进入某个 pod，获取了一个token后,传统的攻击思路可能是“我是谁，我可以做什么”。但是从上文的介绍，现在更重要的是去考虑"此Pod中有哪些服务"。如图我们通过这个据点可以接触到CA、backup服务器、IAM等。由于这些服务以资源的形式存在，可以对它们的角色进行审计。

在基于资源的策略攻击的案例中，对某一PC软件并进行了审计。在审计过程中，通过捕获整个进出网卡的数据包发现，此软件在更新的过程中，它的EXE/Dll是放在云服务上的，通过请求云服务的方式将此请求到本地，然后进行更新。在审计的过程中发现此软件对云服务的权限是get，通过我们自研工具(checktools)可以抓取计算机所有进出口的流量，然后从里面分析所有与云服务相关的各种资源，包括OSS、CDN、VPC、IAM等。在审计的过程中发现账户权限由原来的get变为了get/put。由于本身已经具有PUT权限，所以制作一个木马然后PUT到云服务器的OSS。木马上传后，在短短五分钟内，它向我们的C2服务器回连了800多次请求，这些请求来自不同的IP地址。

03 : IMDS攻击利用

IMDS（Instance Metadata Service）是云原生环境中的一个重要组成部分，它为运行在云虚拟机实例上的工作负载提供元数据服务。常见的元数据有以下两种：

• Meta-data：用来查询服务器实例ID、网络ID等信息。

• User-data：在第一次启动或重新启动服务器时安装软件、下载代理、下载配置文件、启动某些程序、检查配置等操作。

IMDS在实例上进行编码，用于安全访问实例元数据。攻击者利用元数据服务获取临时凭据，然后使用获取到的临时凭据再目标实例中执行指令并控制实例权限。如果窃取到的临时凭据拥有一定权限的角色，攻击者可以尝试使用通过元数据服务获取的临时凭据进行持久化操作，确保能够持续拥有访问权限，以防被发现后强行终止攻击行为。

如果此时已经控制了一个pod，就可以基于这个pod去请求元数据。然后查看元数据里面保存的硬编码密码或者编码后的密码。具体IMDS攻击利用如下所示：

• 提权

• 敏感信息收集

• 横向移动

• 可以访问哪些资源

• 硬编码凭据

• 以root权限运行的脚本

经典攻击案例如图所示：攻击者利用硬编码的证书、凭据，然后提取token。然后利用token来访问web的资源或者横向的资源。

04 : AK/SK利用防护绕过

如果在实战中攻击者窃取了一个AK/SK，可以直接利用AK/SK请求服务。由于是不同的地理位置进行的请求云服务，此时云平台会直接进行拦截。针对以上AK/SK的拦截，可以利用以下方法绕过：

• 新启服务器实例：在未监控云平台上的IP发起请求时，可以通过启动新的服务实例并利用另一台云服务器和请求的令牌进行绕过。然而，在云平台更新后，这种方法已不再有效。

• 云函数：某些业务本身托管在云函数上，可以进一步利用云函数来发起对服务的请求。

• VPC：在VPC中建立一个隔离的网络，然后在这个隔离的网络中使用AK/SK进行对服务的请求。

从K8s到Cloud

攻击过程中，一旦获得了一个机器，该机器位于 Pod 中。为了进一步扩大成功，攻击者需要从 Pod 横向移动扩展至整个云环境。

如果我们获取pod控制权，它具有以下权限：

1. 此pod可以获取到仓库的信息、获取到镜像的信息、获取到漏洞扫描的信息。

2.可以获取到卷的信息以及存储的信息。

3.获取到网络的信息

如果获得了上述权限，攻击者就可以执行以下攻击：

• 下载所有私有仓库镜像。

• 查看所有镜像漏洞扫描结果。

• 测绘网络拓扑。

• 创建、修改、删除网络接口。

• 修改安全组。

以下是一个针对此类风险利用的真实案例，在该案例中，我们通过Confluence的远程代码执行漏洞（RCE）攻击得到了 pod 的控制权，并在该 pod 中获取了一个提权节点的token。借助这个token，成功下载了私有仓库的镜像。在分析镜像时，发现了硬编码的 Jenkins 凭据。同时，利用这个token，然后对整个网络拓扑进行了测绘，并发现了 Jenkins 的位置。由于存在 VPN 墙隔离，无法直接访问内部的一些服务器。然而，通过修改虚拟私有云（VPC）和调整安全组的权限，成功实现了绕过这些限制。并取得了对 Jenkins 的控制权。通过 Jenkins，进一步登录了其他受限服务器。

01 : API滥用提权

Azure使用"角色"概念来向主体分配权限。Azure API权限是一个完全独立且平行的权限集，可授予给Azure服务主体。Azure目录角色和API权限存在一些重叠，可将它们视为平行的权限系统。这些平行系统可用于管理对相同对象的访问，并授予相同对象的访问权限。然而，在Azure API权限系统中授予的具体权限仅在主体通过该API对目标对象执行操作时才会生效。

以下为Azure中常用的请求凭据的API：

• listClusterUserCredential：请求user的凭据，会返回user的token同时还会返回证书(具有本地system权限)。

• listClusterMonitoringUserCredential：本身已经会返回管理员的凭据。

• listClusterAdminCredential：请求管理员的凭据，也会返回管理员的token以及证书(具有本地system权限)。

• listCredential

由于listClusterUserCredential和listClusterAdminCredential返回的证书都具有本地system权限，所以可以忽略user的凭据然后直接利用返回的证书，使用证书进行资源的请求进而实现横向控制。

绕过私有集群限制

在以往的云上 K8s 集群中，通常会将Node分配内网私有IP，而 Master 节点则由云平台本身进行管理。因此，Node与 Master 之间的通信是通过 Master 的公网 IP 进行的。然而，在私有集群中，包括 Master 节点在内的所有节点都可能被分配内网 IP，在一个大型的虚拟私有云（VPC）中。如下图所示。

在当前情境下，为了从外部访问私有集群中的资源，需要绕过私有平台的限制。绕过私有平台限制实质上是通过滥用 API 的方式实现的，其中可以利用 RunCommand 这个 API 进行限制的规遍。RunCommand 具有以下功能：

• 互联网访问私有集群。

• 所有集群中默认启用。

• 执行命令的Pod默认是以集群管理员形式启动。

• 获取到具有该权限的账户则可控整个集群。

Say admin without saying admin

在azure研究过程中，发现了AKS-services role滥用。研究过程中发现某些账户在权限上虽然不是管理员，但实际上具有管理员级别的权限。一些最佳实践手册中仅将该角色授予用户而不是管理员，然而在某些传递过程中，我们发现这些账户的权限非常高，足以控制整个集群。因此，发掘类似的风险点在云上攻击中显得至关重要。

攻防启示

云原生的快速发展对于攻防双方都是巨大的挑战，对攻击者而言庞大且复杂的云原生体系提供了更加令人兴奋的挑战。对防御者来说云原生安全不是黑匣子，了解攻击策略 是构建强防御的第一步。