前言

由于工作方面接触，发现越来越多的中小型公司选择使用云平台，诸如:阿里云、腾讯云、华为云、七牛云等等，另一方面随着公用云的普及，也存在着一些风险，当然不是由于云平台本身的安全性欠缺，而是由于使用者在调用API时没有注意安全性而导致的。最常见的问题就是AccessKey及泄漏、配置不当导致攻击者接管存储桶及云控制台等危害。

以下是个人的一些浅见和总结，如有不当的地方还请各位师傅批评指正。

传统web安全和云原生安全的区别

1. 安全威胁不同：传统Web应用程序主要面临网络攻击、恶意软件和数据泄漏等威胁，而云环境则需要应对更广泛、更复杂的安全威胁，包括无授权访问、虚拟化漏洞和配置错误等。

2. 体系结构不同：在传统Web应用程序中，通常使用单一服务器或集群来部署和运行应用程序。然而，在云环境中，应用程序采用容器化、微服务和动态资源分配等方式进行部署，使得系统架构更加复杂。

3. 安全责任共担：在云环境中，安全责任由服务提供商和客户共同承担。服务提供商负责保护基础设施和平台层的安全性，而客户负责保护业务层的安全性。

4. 安全控制不同：云环境具有更强大的安全控制，例如身份认证和访问控制、加密、网络隔离和监控等功能，以确保数据和应用程序得到充分保护。

正文

Access Key和Secret Access Key是Amazon Web Services（AWS）的一种身份验证机制，用于授权用户访问AWS资源。

具体来说，Access Key是与AWS账户相关联的唯一标识符。每个AWS账户都有一个Access Key，它通常由20个字符组成，可以使用该Key来访问AWS服务API和AWS管理控制台。Secret Access Key是与Access Key相关联的密码，用于进行身份验证和访问控制策略。Secret Access Key必须保密，并且不应该与其他人共享。当需要在AWS中创建、修改或删除资源时，需要使用Access Key和Secret Access Key进行身份验证。这些密钥可通过AWS Identity and Access Management（IAM）进行管理，包括创建、删除、禁用和启用访问密钥，以及分配特定权限给不同用户。

OSS AccessKey泄露

通过上面描述我们知道AccessKey如果泄露就会导致用户账户被控制，常见的泄露方式有以下几种：

• • APK反编译后的配置文件

  • 小程序反编译后的配置文件

  • GITHUB关键字、JS文件、FOFA等。

  • spring未授权读取env或heapdump泄露

  • 低权限的WEBSHELL查看网站的配置文件

  • 任意文件读取漏洞读取bash_history

  • 浏览器插件FindSomething

  • debug泄露

拿到ak/sk后的一些简单利用方式

• • • 第三方平台，如：行云管家

    • OSS/COS Browser、例如阿里、腾讯

    • aksk_tool

    • cf

这里演示几种常见的利用方法

cf

先进行配置

目前cf支持阿里、腾讯、华为、AWS四个云接管，下面用阿里云做示范

OSS Browser

阿里云 access key ID 和 access key secret 是访问阿里云API的唯一凭证。Access key ID 是类似身份的标识，而 access key secret 的作用是签名你的访问参数，以防被篡改。Access key secret 类似你的登录密码。

登录后可以进行文件增删改查等一系列操作

COS Browser也是一样的操作，这里就不再赘述了。

通过行云管家，我们可以进一步进行操作，同样的我们也需要ak/sk

使用行云管家，不仅可以访问OSS服务，还可以直接重置服务器密码，接管服务器,建立RAM用户等等操作

那么有长期密钥肯定就有临时密钥了，二者利用方式也不同，这里以腾讯云为例：

腾讯云临时密钥是一种通过腾讯云访问管理（CAM）服务创建的、有时间限制的安全凭证，用于访问和管理腾讯云资源。与长期密钥不同，临时密钥具有更高的安全性，因为它们只在必要时生成，并且可以在使用后立即删除。临时密钥由CAM服务创建，包括一个 SecretId 和一个 SecretKey，以及一个 Token。这些密钥可用于访问和管理腾讯云资源，但只在特定时间段内有效。腾讯云临时密钥适用于需要将腾讯云资源授权给第三方或避免在本地存储长期密钥的情况。例如，可以向第三方应用程序提供临时密钥，使他们能够访问腾讯云资源，而无需使用长期密钥。
腾讯云获取临时密钥的过程如下：

账号中的访问策略包括用户组策略、用户策略、存储桶访问控制列表（ACL）和存储桶策略（Policy）等不同的策略类型。当腾讯云 COS 收到请求时，首先会确认请求者身份，并验证请求者是否拥有相关权限。验证的过程包括检查用户策略、存储桶访问策略和基于资源的访问控制列表，对请求进行鉴权。

流程如下：

小结

目前云上攻击的主要思路集中在以下几个层面：

• • • 突破网络隔离：传统的网络隔离边界（防火墙、路由器、交换机、VPN）、VPC（peering、endpoint、traffic mirror）、云专线（混合云、多云网络）、安全组等；

    • 突破资源隔离：虚拟机逃逸、容器逃逸、物理机CPU/芯片侧信道攻击等；

    • 突破权限隔离：IAM账号（AWS Landing Zone）、IAM策略（ABAC）、委托代理、联邦认证（AWS STS security tokens、SAML）等；

    • 突破架构隔离：物理多租（单租户独享）、逻辑多租（多租户共享）等。

当然了，上文主要是以国内云厂商为例，以下是一些常见的的攻击场景（以AWS，Azure，GCP为例）

场景一：云服务认证Key泄漏（如AWS AK/SK或者Security Token等）

攻击难度：低攻击路径：云服务认证Key -> 云服务公开API/SDK -> 云服务资源访问/控制利用方式：

• • Github仓库配置不当
  • 云架构中的密码重用
  • 针对云租户账号密码的社工攻击（如AWS Credential Harvesting钓鱼攻击）
  • 云主机中Web应用的漏洞（SSRF，RCE，本地文件读取等漏洞）
  • 公共的存储桶
  • 信任的关联第三方数据泄露

  • 硬编码在网页或移动APP中的AK/SK

场景二：云上租户的云服务不安全配置攻击难度：低攻击路径：公共访问的云存储桶 -> 敏感凭证 ->  云服务资源访问/控制

利用方式：公共访问的云存储桶爆破

场景三：云主机中web应用自身漏洞

攻击难度：中

攻击路径：

• • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS SSM -> RCE

  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS Lambda -> RCE

  • SSRF -> EC2 Metadata API -> IAM临时Security Token -> AWS S3 -> 信息泄漏

  • RCE -> EC2 Metadata API -> IAM临时Security Token -> AWS EC2/S3/Lambda

  • RCE -> EC2 Metadata API -> EC2 Userdata -> 敏感凭证 ->  其他EC2或者云服务

二、利用公有云本身的服务（IaaS，PaaS，SaaS）的自身问题为突破口

场景一：云服务自身功能导致代码执行

攻击难度：低

攻击路径：云服务账号AK/SK -> 云服务功能（AWS SSM/Lambda/EC2 Instance Connect）-> RCE

利用方式：

• • 外部泄漏的云服务账号AK/SK（Github，Public S3 Buckets，硬编码在网页或移动APP中的AK/SK等）

  • EC2云上应用SSRF漏洞配合AWS Metadata API

场景二：云服务的公开API利用

攻击难度：低

攻击路径：云服务账号AK/SK -> 云服务公开API -> 云服务资源调用（OS镜像，容器镜像，存储桶，数据库，Userdata等）-> 敏感信息泄露（数据，凭据等）

利用方式：云服务公开API的熟悉和利用，如AWS CLI/AWS SDK

场景三：云服务第三方软件漏洞利用

攻击难度：中

攻击路径：第三方软件漏洞 -> 使用该软件的云服务 -> 云服务系统/平台 -> 其他租户数据

利用方式：

• • 收集云服务利用的第三方软件列表与相应的版本信息，如MySQL，ElasticSearch，Docker，K8S等

  • 第三方软件0day研究和Nday的收集与利用

场景四：云服务私有或者公开API漏洞挖掘与利用

攻击难度：中-高攻击路径：云主机中应用SSRF漏洞或者云服务账号AK/SK -> 云服务私有/公开API漏洞 -> RCE/信息泄露利用方式：

• • 云服务私有API寻找与测试（云服务Web请求分析，云服务SDK或者离线工具分析等）
  • 云服务公开API漏洞研究（输入输出校验，认证与鉴权绕过等）
  • 云主机中的应用的SSRF漏洞

场景五：容器逃逸

攻击难度：中-高

攻击路径：共享容器 -> 宿主机 -> 其他租户容器

利用方式：

• • 容器逃逸漏洞

  • 宿主机目录挂载（/var/run/docker.sock）

  • 特权容器

  • Kubernetes安全

目前接触到比较多的就是这些，本人文笔不好，部分也有引用一些其他平台文章的内容，如果有问题还请师傅们多多指正，我会在第一时间积极响应。