云原生服务攻防技术研究 - 前期侦查

一、云原生服务攻防矩阵

近些年来，越来越多的IT产业正在向云原生的开发和部署模式转变，这些模式的转变也带来了一些全新的安全挑战。

• 云服务器安全：由于云服务器中承载着用户的业务以及数据，其安全性尤为重要而云服务器的风险往往来自于两方面：云厂商平台侧的风险与用户在使用云服务器时的风险。与用户侧风险相比，平台侧的漏洞往往带来更广泛的影响。
• 云账号安全
• 对象存储安全：在对象存储所导致的安全问题中，绝大部分是由于用户使用此功能时错误的配置导致的。据统计，由于缺乏经验或人为错误导致的存储桶错误配置所造成的安全问题占所有云安全漏洞的16%。
• 云数据库安全等

总体来说，云原生攻击的主要思路集中在以下几个层面：

• 突破网络隔离：传统的网络隔离边界（防火墙、路由器、交换机、VPN）、VPC（peering、endpoint、traffic mirror）、云专线（混合云、多云网络）、安全组等；
• 突破资源隔离：虚拟机逃逸、容器逃逸、物理机CPU/芯片侧信道攻击等；
• 突破权限隔离：IAM账号（AWS Landing Zone）、IAM策略（ABAC）、委托代理、联邦认证（AWS STS security tokens、SAML）等；
• 突破架构隔离：物理多租（单租户独享）、逻辑多租（多租户共享）等。

前期侦查	初始访问	执行	权限提升	权限维持	防御绕过	信息收集	横向移动	影响
API 密钥泄露	Bucket 公开访问	通过控制台执行	利用应用程序提权	在存储对象中植入后门	关闭安全监控服务	用户账号数据泄露	窃取云凭证横向移动	Bucket 接管
控制台账号密码泄露	特定的访问配置策略	利用云厂商命令行工具执行	Bucket 策略可写	写入用户数据	在监控区域外攻击	对象存储敏感数据泄露	窃取用户账号攻击其他应用	任意文件上传覆盖
临时访问凭证泄露	元数据服务未授权访问	使用云API执行	Object ACL 可写	在云函数中添加后门	停止日志记录	目标源代码信息	通过控制台横向移动	敏感数据泄露
访问密码泄露	云控制台非法登录	写入用户数据执行	Bucket ACL 可写	在自定义镜像库中导入后门镜像	日志清理	共享快照	使用实例账号爆破	破坏存储数据
SDK 泄露	账号劫持	使用对象存储工具执行	通过访问管理提权	创建访问密钥	通过代理访问	元数据	使用用户账号攻击其他应用	植入后门
前端代码泄露	恶意的镜像	利用后门文件执行	创建高权限角色	在 RAM 中创建辅助账号		云服务访问密钥	PostgreSQL 数据库 SSRF	拒绝服务
共享快照	网络钓鱼	利用应用程序执行	利用服务自身漏洞进行提权	利用远控软件		用户数据		子域名接管
账号/角色暴力破解	应用程序漏洞	利用 SSH、RDP 服务登录到实例执行命令	低权限下收集到数据库里的高权限访问凭证信息	控制台修改或添加数据库账户密码		获取配置文件中的应用凭证		资源劫持
	服务弱口令	利用远程命令执行漏洞执行	在 RAM 中将低权限用户分配高权限策略	命令行修改或添加数据库账户密码		获取实例网段信息		窃取项目源码
	密码访问	利用 SDK 执行		共享快照		数据库连接历史记录		窃取用户数据
	密钥访问	数据库连接工具				数据库其他用户账号密码		篡改数据
						数据库中的敏感信息		加密勒索
						警告通知邮箱		恶意公开共享
						性能详情		恶意修改安全组
						MSSQL 读取实例文件		恶意释放弹性IP
						流日志		恶意修改防火墙策略
						安全组配置信息		LB 中的 HTTP 请求走私攻击
						RAM 用户角色权限信息		Bucket 爆破
								Bucket Object 遍历

 

备注：本文所使用到的AK/SK/账号/角色/权限配置登信息均为实验靶场环境，文章完成后已经删除不存在，文章仅供技术交流学习。

参考链接：

https://attack.mitre.org/matrices/enterprise/cloud/
https://cloudsec.huoxian.cn/docs/articles
https://hackingthe.cloud/
https://cloudsecwiki.com/index.html
https://www.cloudvulndb.org/
https://blog.christophetd.fr/cloud-security-breaches-and-vulnerabilities-2021-in-review/
https://cloud.hacktricks.xyz/welcome/readme
https://orca.security/
https://cloudsecdocs.com/
https://sysdig.com/blog/2023-global-cloud-threat-report/
https://github.com/dafthack/CloudPentestCheatsheets
https://github.com/carnal0wnage/weirdAAL
https://interconnected.blog/tag/cloud-industry/
https://landscape.cncf.io/
https://github.com/Esonhugh/Attack_Code
https://github.com/YDCloudSecurity/cloud-security-guides
https://cloud.tencent.com/developer/article/1931560
https://github.com/teamssix/awesome-cloud-security
https://mp.weixin.qq.com/s/r0DuASP6gH_48b5sJ1DCTw
https://mp.weixin.qq.com/s/lL32lywlrnuyhJkQk5NAEw
http://avfisher.win/archives/1331

 

二、API 密钥泄露

0x1：AK/SK是什么

云平台作为降低企业资源成本的工具，在当今各大公司系统部署场景内已经成为不可或缺的重要组成部分，在企业上云的过程中，由于原本本地化的IT设施被移到了云上，所以导致原本存在于服务器内部的APICALL转变成了组件和云服务之间的API调用。由于各类应用程序需要与其他内外部服务或程序进行通讯而大量使用凭证或密钥，有跨组件API调用就存在鉴权、验证、秘钥泄露等问题。这就进一步导致了 AK/SK 泄露、敏感数据泄露事件屡见不鲜。

AK/SK（Access Key ID/Secret Access Key）即访问密钥，包含

• 访问密钥ID（AK），公有云通过AK识别用户的身份，一个用户的AK泄露往往代表用户在云平台最高权限的泄露，云环境中所有计算、存储资源对入侵者门洞大开。非法利用者甚至不需要为此单独开发工具，直接使用现成的产品就能直接获取用户在云内的所有资源列表。
• 秘密访问密钥（SK），公有云服务端通过SK对请求数据进行签名验证，用于确保请求的机密性、完整性和请求者身份的正确性

简单来说，云AK/SK是用于生成用户跟云平台的API通信的访问凭据。其中SK是必须要保密的，不能通过任何途径泄露，否则就会产生安全问题。

云主机接收到用户的请求后，系统将使用AK对应的相同的SK和同样的认证机制生成认证字符串，并与用户请求中包含的认证字符串进行比对。如果认证字符串相同，系统认为用户拥有指定的操作权限，并执行相关操作；如果认证字符串不同，系统将忽略该操作并返回错误码，其底层算法原理就是对称加解密。

0x2：AK/SK泄露的安全攻击面

1、AK/SK接管存储桶

使用工具或者云主机管理平台可以直接接管存储桶，接管桶后可以对桶内信息进行查看、上传、编辑、删除等操作。

OSS Browser--阿里云官方提供的OSS图形化管理工具，https://github.com/aliyun/oss-browser

可以看到登入存储桶后可以查看、上传、删除、下载桶内文件，造成存储桶接管的危害。

类似的，攻击者可以通过获取泄露的AK/SK调用云厂商的API，从而接管用户的云账户、云主机、云存储等功能。

2、行云管家（支持多家云主机厂商）

也可以根据云平台的一些管理工具，直接导入云资源，

通过行云管家接管主机后，不仅可以访问OSS服务，还可以直接重置服务器密码，接管服务器。

3、拿到AK/SK后对主机下发命令执行

这里使用CF集成管理工具，CF 是一个云环境利用框架，适用于在红队场景中对云上内网进行横向、SRC 场景中对 Access Key 即访问凭证的影响程度进行判定、企业场景中对自己的云上资产进行自检等等。

下载go源码后，编译为可执行文件，

go build main.go

配置访问配置，

main config

一键列出当前访问凭证的权限，

main alibaba perm

一键接管控制台，

main alibaba console

一键列出当前访问凭证的云服务资源，

main alibaba ls

一键获取实例中的临时访问凭证数据，

main alibaba ecs exec -m

0x3：如何检测AK/SK泄露

在企业混合云架构下，公有云和私有云都存在大量的 AccessKey，如何有效地检测可能的 AK/SK 泄露事件，成为一件十分重要的事情。

本质上，AK/SK泄露问题是数据安全，更进一步说是因为开发者开发规范不合规导致的数据存储安全问题（开发者违规将AK/SK共享到公网代码仓库）。所以如果要治理AK/SK泄露，首先第一步要确定的就是存在数据存储风险的位置，

• 包含AK/SK的源码被上传到github
• 包含AK/SK的源码被上传到gitlab
• 包含AK/SK的源码被上传到gittee
• 包含AK/SK的源码被上传到博客文章
• 小程序代码泄露AK/SK，将AK/SK硬编码到小程序代码/配置文件中，攻击者只需要对小程序包进行反编译即可获取AK/SK

• 网络请求泄露AK/SK，通过后端API将AK/SK返回到前端，攻击者只需要对小程序进行网络抓包，即可获取后端返回的AK/SK，举例如下，可以清楚看到该API的返回内容泄露了多个公有云厂商的AK/SK

• 报错页面或者debug信息调试
• 网站的配置文件
• HeapDump文件

所以基本上说，API秘钥泄露检测的思路大致有如下几个方面：

1. 就是监控各大公网代码仓库，检测平台公开源代码中是否包含企业所使用的 AK/SK 敏感信息，AK/SK的特征可以参阅这篇文章。
   1. 收集企业内部 (公有云 + 私有云) 所有的 AccessKeyId 作为关键特征
   2. 借助例如 Github API 的代码搜索能力，通过定时任务检测关键特征，以发现可能的 AK/SK 泄露事件
2. 做好CI/CD代码安全审核，检测源码中是否存在明文AK/SK
3. 做好API安全审核，实时检测/拦截API接口返回中存在的敏感数据

这里需要特别注意的是，在 AK 检测工具的技术实现上主要需要考虑两点，接口调用频率和告警方式的选择。 

• 接口调用频率：接口调用频率的限制，决定了这是一个慢速检测的过程，需要我们选择合适的接口调用频率，而一旦触发限制请求会失败，需要有请求失败重发机制。 
• 告警方式：一旦检测发现异常事件，需要有告警机制来及时响应处理。邮件告警是一种比较简便的方式，通过调用 SMTP 服务自动发送邮件告警。另外，考虑对分散的工具进行平台式整合，将检测到 AK 泄露信息通过 syslog 发送到 SIEM 平台，进行统一的安全监控和事件响应。

0x4：AK/SK泄露的治理与防范

AK滥用的问题需要从平台方和用户方两边共同解决。平台方需要提供足够多的安全措施，而用户则需要做好特权的管理。

1、云平台防止AK滥用

1）OpenAPI设计层面做到默认安全

安全与开放和便利天然就是对立的，从云平台的角度来说对于开放API的范围以及开放的形式需要更加谨慎。

• 高危的功能以什么形式开放
• 执行权限和编辑权限是否同时对外开放等

应该经过充分的安全评估后，再决定对外开放的范围。

避免权限滥用最重要的就是做分权，这是API设计思想层面的改造。

• 在给子账号分配权限时，将API分为读、写操作。
• 将API按照业务属性和管理属性区分
• 参照三权分立的思想，创建密钥、重置主机密码这类授权类的读写API，与资源列表、弹性配置等业务数据类的读写API分开；上传任意自定义脚本与运行已经上传脚本的权限分开

同时，最安全的方式也是云平台推荐的方式即删除主AK，只保留子AK。

2）审计和检测

对于AK的利用行为进行审计，记录下请求发起方的角色、调用的记录、读取的实例范围等内容。用以评估是否有AK在用户不知情的情况下被调用。

在这基础上可以进一步基于行为进行调用风险的检测，对于某些特定的API调用序列进行告警，高风险API的调用告警。 

3）访问控制

平台方有义务提供足够多的访问控制手段，包括不限于单独限制每一个AK访问源IP、访问时间段、可以访问的资源集/资源id、可以调用的API的范围。

尽量从API权限层面缩减暴露面，减少不必要的访问风险。

限制key的使用范围是非常有必要的，但是访问控制不能解决所有的问题。因为高权限的key始终存在泄露的风险，除非高权限的key不存在。

2、用户统一管理特权AK

对于企业用户而言问题要更棘手一点，AK只是特权账号的一种，分散在各级系统、产品、控制台中的特权账号依旧无法得到有效管理。用户也无法被动指望自己的所有供应商都提供足够的特权管理手段。

站在用户的角度来看，特权账号的管理必须是一个统一的产品，而不是松散的产品集合。

按照权限级别，大致可以分为以下3类。

根据账号的属性分，大致可以分为4类。

特权账号广泛分布在企业内部的各个操作系统、应用程序中，而一旦发生云平台AK这种顶级权限的泄露将危害无穷。对于特权账号的管理，重点则在于对这4类账号中的高特权的管理员账号进行识别和管理。

特权管理的思路本质上与管理其他的资产没有太大的区别。为了达到最佳效果，特权管理解决方案应该至少接入ATT&CK框架中常用到的本地账号、域账号、云账号。并且能够做到：

• 能够协助企业管理人员识别分散在内部各种系统中的特权账号-包括root账号、公用账号、高权限管理员、SSH密钥、证书、API key等等。
• 持续监控账号状态，包括账号的权限变更、轮换记录、使用范围等信息。
• 根据账号的权限等级和用途，将特权账号的使用监控起来，审计特权账号的所有使用记录，包括特权账号的登陆设备、访问源、访问目的、访问时间、访问数据范围等信息，及时发现对关键文件和目录的未授权访问和/或更改。
• 能根据账号的使用记录自动学习生成每个账号的安全策略。再通过人的运营来补齐管理策略。
• 能对特权账号的可疑行为进行告警。必要时并可以联动其他设备，阻断恶意的访问行为。对可疑的活动进行阻断或放行后，能持续更新账号安全策略。

参考链接：

https://www.wevul.com/1220.html
https://www.wangan.com/p/11v74d351feb1f2b
https://xz.aliyun.com/t/12543 
https://github.com/Bypass007/AK-leak-detection 
https://developers.weixin.qq.com/community/minihome/doc/00086415470e98a3972e9d90856c01?blockType=99
https://mp.weixin.qq.com/s/5CC9vJvLcjqLTiP0aLKCiw
https://www.cnblogs.com/pmyewei/p/16701274.html
https://zone.huoxian.cn/d/932-ak-sk/2
https://github.com/Phuong39/cf
https://mp.weixin.qq.com/s/wi8CoNwdpfJa6eMP4t1PCQ
https://zone.huoxian.cn/d/2557
https://forum.butian.net/share/2376
https://wiki.teamssix.com/CloudService/more/
https://zone.huoxian.cn/d/2766

 

三、临时访问凭证STS泄露 

0x1：什么是STS临时访问凭证

以访问OSS资源场景为例，假设我们需要上传文件/图片 存储到阿里云OSS，使用官方推荐的STS授权访问方法，

假设您是一个移动App开发者，希望使用阿里云OSS服务来保存App的终端用户数据，并且要保证每个App用户之间的数据隔离。此时，您可以使用STS授权用户直接访问OSS。

使用STS授权用户直接访问OSS的流程如下：

• App用户登录。App用户和云账号无关，它是App的终端用户，App服务器支持App用户登录。对于每个有效的App用户来说，需要App服务器能定义出每个App用户的最小访问权限。
• App服务器请求STS服务获取一个安全令牌（SecurityToken）。在调用STS之前，App服务器需要确定App用户的最小访问权限（用RAM Policy来自定义授权策略）以及凭证的过期时间。然后通过扮演角色（AssumeRole）来获取一个代表角色身份的安全令牌（SecurityToken）。
• STS返回给App服务器一个临时访问凭证，包括一个安全令牌（SecurityToken）、临时访问密钥（AccessKeyId和AccessKeySecret）以及过期时间。
• App服务器将临时访问凭证返回给App客户端，App客户端可以缓存这个凭证。当凭证失效时，App客户端需要向App服务器申请新的临时访问凭证。例如，临时访问凭证有效期为1小时，那么App客户端可以每30分钟向App服务器请求更新临时访问凭证。
• App客户端使用本地缓存的临时访问凭证去请求OSS API。OSS收到访问请求后，会通过STS服务来验证访问凭证，正确响应用户请求。

0x2：通过STS临时访问权限访问OSS资源Demo

遵循最小权限原则，尽量避免使用主账号进行OSS调用等操作，因此需要创建一个具备最先必要权限的Ram子账号。同时为了进一步保证AK/SK安全性，我们可以避免在应用代码中直接使用AK/SK来访问云资源，而是可以创建一个低权限Ram账号，使用角色扮演（临时申请具有高权限的虚拟角色）的方式临时申请STS来访问云资源。

1、创建Ram用户

登录RAM控制台。

1. 在左侧导航栏，选择身份管理>用户。
2. 单击创建用户。
3. 输入登录名称和显示名称。
4. 在访问方式区域下，选择OpenAPI调用访问，然后单击确定。
5. 单击复制，保存访问密钥（AccessKey ID 和 AccessKey Secret）。

2、为RAM用户授予请求AssumeRole的权限

1. 单击已创建RAM用户右侧对应的添加权限。
2. 在添加权限页面，选择AliyunSTSAssumeRoleAccess系统策略。
3. 单击确定。

3、创建用于获取临时访问凭证的角色 

RAM角色是一种虚拟用户，可以被授予一组权限策略。与RAM用户不同，RAM角色没有永久身份凭证（登录密码或访问密钥），需要被一个可信实体扮演。扮演成功后，可信实体将获得RAM角色的临时身份凭证，即安全令牌（STS Token），使用该安全令牌就能以RAM角色身份访问被授权的资源。

1. 在左侧导航栏，选择身份管理>角色。
2. 单击创建角色，选择可信实体类型为阿里云账号，单击下一步。
3. 在创建角色对话框，角色名称填写为RamOssTest，选择信任的云账号为当前云账号。
4. 单击完成。角色创建完成后，单击关闭。
5. 在角色页面，搜索框输入角色名称RamOssTest，然后单击RamOssTest。
6. 单击ARN右侧的复制，保存角色的ARN。

4、为角色授予上传文件的权限

1. 创建上传文件的自定义权限策略。
   1. 在左侧导航栏，选择权限管理>权限策略。
   2. 在权限策略页面，单击创建权限策略。
   3. 在创建权限策略页面，单击脚本编辑，然后在策略文档输入框中赋予角色向目标存储空间examplebucket下的src以及dest目录上传文件的权限。
   4. 策略配置完成后，单击继续编辑基本信息。
   5. 在基本信息区域，填写策略名称为RamTestPolicy，然后单击确定。
2. 为RAM角色RamOssTest授予自定义权限策略。
   1. 在左侧导航栏，选择身份管理 > 角色。
   2. 在角色页面，找到目标RAM角色RamOssTest。
   3. 单击RAM角色RamOssTest右侧的添加权限。
   4. 在添加权限页面下的自定义策略页签，选择已创建的自定义权限策略RamTestPolicy。
   5. 单击确定。

5、获取临时访问凭证

可以通过调用STS服务的AssumeRole接口来获取临时访问凭证。

登录之前创建的Ram子账号，模拟有限低权限Ram通过角色扮演获取STS的情况，

6、使用临时STS访问凭证上传文件至OSS

以Java SDK 3.12.0版本为例，将本地D:\\localpath路径下的exampletest.txt文件上传至存储空间examplebucket下的src目录的示例代码如下：

import com.aliyun.oss.OSS;
import com.aliyun.oss.OSSClientBuilder;
import com.aliyun.oss.OSSException;
import com.aliyun.oss.model.PutObjectRequest;
import com.aliyuncs.exceptions.ClientException;

import java.io.File;

public class Demo {
    public static void main(String[] args) throws ClientException {
// Endpoint以杭州为例，其它Region请按实际情况填写。
 String endpoint = "https://oss-cn-hangzhou.aliyuncs.com";
// 从环境变量中获取步骤5生成的临时访问密钥AccessKey ID和AccessKey Secret，非阿里云账号AccessKey ID和AccessKey Secret。
String accessKeyId = System.getenv("OSS_ACCESS_KEY_ID");
String accessKeySecret = System.getenv("OSS_ACCESS_KEY_SECRET");
// 从环境变量中获取步骤5生成的安全令牌SecurityToken。
String securityToken = System.getenv("OSS_SESSION_TOKEN");

// 创建OSSClient实例。
OSS ossClient = new OSSClientBuilder().build(endpoint, accessKeyId, accessKeySecret, securityToken);
// 将本地文件exampletest.txt上传至目标存储空间examplebucket下的src目录。
PutObjectRequest putObjectRequest = new PutObjectRequest("examplebucket", "src/exampletest.txt", new File("D:\\localpath\\exampletest.txt"));

// ObjectMetadata metadata = new ObjectMetadata();
// 上传文件时设置存储类型。
// metadata.setHeader(OSSHeaders.OSS_STORAGE_CLASS, StorageClass.Standard.toString());
// 上传文件时设置读写权限ACL。
// metadata.setObjectAcl(CannedAccessControlList.Private);
// putObjectRequest.setMetadata(metadata);

try {
     // 上传文件。
     ossClient.putObject(putObjectRequest);
    } catch (OSSException oe) {
        System.out.println("Caught an OSSException, which means your request made it to OSS, "
                + "but was rejected with an error response for some reason.");
        System.out.println("Error Message:" + oe.getErrorMessage());
        System.out.println("Error Code:" + oe.getErrorCode());
        System.out.println("Request ID:" + oe.getRequestId());
        System.out.println("Host ID:" + oe.getHostId());
    } finally {
        if (ossClient != null) {
            ossClient.shutdown();
        }
    }
}
} 

0x3：通过ECS 100网段元数据地址获取STS

云服务器实例元数据服务是一种提供查询运行中的实例内元数据的服务，云服务器实例元数据服务运行在私网地址上，当实例向元数据服务发起请求时，该请求不会通过公共网络传输，但是如果云服务器上的应用存在RCE、SSRF等漏洞时，攻击者可以通过漏洞访问实例元数据服务。

通过云服务器实例元数据服务查询，攻击者除了可以获取云服务器实例的一些属性之外，更重要的是可以获取与实例绑定的拥有高权限的角色，并通过此角色获取云服务器的控制权。

阿里云的元数据地址为：http://100.100.100.200/latest/meta-data，

可以看到成功获取到了元数据信息，并且值得注意的是，如果在元数据信息里还有 ram/目录，这就意味着这台实例存在临时访问凭证，也就是说存在被进一步利用的可能性。如果在这台机器配置了Ram角色，如果攻击者拿到了RCE权限，理论上就有机会通过ECS实例信息获取接口拿到STS。

打开 ram/目录，在 http://100.100.100.200/latest/meta-data/ram/security-credentials/EcsRoleForTest下找到了临时访问凭证。

这里 URL 中的 laravel-test-role 是 RAM 角色名称，可以通过访问 http://100.100.100.200/latest/meta-data/ram/security-credentials/ 获取到。

将临时凭证配置到 aliyun 命令行工具里。

main config

一键列出当前访问凭证的权限，

main alibaba perm

一键接管控制台，

main alibaba console

一键列出当前访问凭证的云服务资源，

main alibaba ls

创建子用户，并赋予管理员权限，

aliyun ram CreateUser --UserName teamssix
aliyun ram CreateLoginProfile --UserName teamssix --Password TeamsSix@666
aliyun ram AttachPolicyToUser --PolicyType System --PolicyName AdministratorAccess --UserName teamssix

访问 https://signin.aliyun.com (opens new window)页面，通过 RAM 用户进行登录，这里的用户格式为 username@company-alias，其中 username 就是刚刚创建的用户名，company-alias 可以通过下面的这个命令获取到。

aliyun ram GetAccountAlias

从防守方的视角来看，产生这个安全风险的原因主要有两个：

1. RAM 角色权限过大，导致可以通过该角色的权限进行创建子用户以及给子用户授予高权限等操作
2. 元数据未做加固访问，导致一旦目标存在 SSRF 或目标权限被拿下，元数据就存在被获取的风险

针对第一个 RAM 角色权限过大的问题，主要还是需要使用者严格遵守权限最小化的原则，在为 RAM 角色赋予权限时，避免赋予过高的权限，只赋予自己所需要的权限，这样可以将影响程度降到最低。

针对第二个元数据未做加固访问的问题，可以将实例上的元数据访问模式设置为加固模式，这是一种治本的方法，将元数据访问模式设置为加固模式有以下两种方法：

1. 在创建实例时，可以在「系统配置」的「高级选项」中将「实例元数据访问模式」设置为「仅加固模式」
2. 在已经创建好的实例中，可以在阿里云 OpenAPI 中开启元数据强制使用 Token 访问，OpenAPI 地址：https://next.api.aliyun.com/api/Ecs/2014-05-26/ModifyInstanceMetadataOptions

将 HttpTokens 设置为 required 即表示强制使用加固模式，此时再访问元数据就会提示 403 了。

值得一提的是，将元数据设置为加固模式可以防止通过 SSRF 获取到元数据，但如果实例权限被拿下，那么红队还是可以通过在实例上执行获取 token 的命令，然后利用该 token 获取到元数据。

在 Linux 实例中获取 token 的命令如下：

TOKEN=`curl -X PUT "http://100.100.100.200/latest/api/token" -H "X-aliyun-ecs-metadata-token-ttl-seconds: 21600"`

通过 token 获取元数据，

curl -H "X-aliyun-ecs-metadata-token: $TOKEN"  http://100.100.100.200/latest/meta-data/

这个方法在实战中想要使用是有一些前提的，主要前提有以下两个：

1. ECS 实例需要被授予 RAM 角色，不然访问临时凭证的元数据会返回 404
2. RAM 角色需要具备 ram 访问控制的相关操作权限，例如创建用户、赋予权限等，不然临时秘钥会没有创建子用户的权限。

在云原生环境下，RCE漏洞不仅可能导致当前主机陷落，甚至可能导致整个云账号下的其他主机也陷落，是一种新形式的内网渗透。这里的内网横向不仅仅是从这台机器到那台机器，而是从这个云服务到那个云服务，例如从 OSS 到 ECS 再到 RAM 等等，在这其中又包含了从这个机器到那台机器，例如多台 ECS 实例之间的内网横向。

总的来说，云上攻防和常规的内网攻防还是十分不一样的。

• 云上攻防的常见问题是配置错误，例如这里的问题就是 RAM 角色配置权限过高。
• 云上攻防的权限维持主要方法是创建 RAM 高权限用户，而不是像传统攻防里那样有五花八门的权限维持方法。
• 云上攻防的内网横向主要是在云服务厂商命令行或者控制台中进行横向，从这个云服务横向到另一个云服务，而不是像传统攻防那样有各种各样的内网横向手法。

参考链接：

https://www.cnblogs.com/zjhblogs/p/16483951.html 
https://help.aliyun.com/zh/oss/developer-reference/use-temporary-access-credentials-provided-by-sts-to-access-oss/#p-hvr-8cp-tbd 
https://zone.huoxian.cn/d/1341-cf 

 

四、账号/角色暴力破解

和传统的SSH/RDP账号密码暴力破解一样，云服务的账号/角色同样也存在暴力破解的风险。

以阿里云为例，一个常见的角色信任策略如下所示：

在这个策略中，Principal 的 RAM 中包含的是 ARN 信息，即 Aliyun Resource Name，格式一般有如下几种：

acs:ram::${AccountId}:root
acs:ram::${AccountId}:user/${UserName}
acs:ram::${AccountId}:role/${RoleName}
acs:ram::${AccountId}:policy/${PolicyName}

如果角色的信任策略能够成功保存，就说明 ARN 是有效的。例如如果上面的策略能够成功保存，说明账号 1526320991301431 下的 root 用户是存在的，如果保存失败，则说明对应用户/角色不存在。显然，这里就存在一个类似账号/密码验证的测信道，可以被用来进行字典枚举暴力破解。

参考链接：

https://wiki.teamssix.com/CloudService/IAM/enum_user_and_role.html 

  

五、利用共享快照获取目标服务器敏感数据

如果当前凭证具有 EC2:CreateSnapshot 权限的话，可以通过创建共享快照的方式，然后将自己 aws 控制台下的实例挂载由该快照生成的卷，从而获取到目标 EC2 中的内容。

参考链接：

https://wiki.teamssix.com/CloudService/EC2/ec2-shared-snapshot.html
https://wiki.teamssix.com/CloudService/EC2/get-ecs-windows-permission.html

 

六、靶场学习

0x1：OSS安全攻防

参考链接：

https://cloudsec.huoxian.cn/docs/goat

0x1：靶场环境搭建 - 从一个SSRF漏洞到接管云控制台

本节将以阿里云为例，对云服务中的一些攻防手法进行演示，首先利用 Terraform 进行 ECS SSRF 漏洞环境的搭建，然后通过实例中存在的 SSRF 漏洞一步步拿下该云服务账户的所有的云服务权限。

采用 TerraformGoat 进行靶场的搭建，TerraformGoat 靶场地址：https://github.com/HuoCorp/TerraformGoat，

参考链接：

https://github.com/HXSecurity/TerraformGoat
https://wiki.teamssix.com/CloudService/IAM/aliyun-console-takeover.html