文章总结: 本文详细分析了SSRF漏洞在云环境中的利用与防御,核心攻击链包括发现SSRF、访问元数据服务窃取临时凭证、横向移动与权限提升。防御措施包括升级IMDSv2、最小权限原则、请求过滤和监控告警。 综合评分: 84 文章分类: 漏洞分析,云安全,内网渗透,安全建设,实战经验
SSRF在云环境的利用与防御:从一枚漏洞到整个云账号沦陷
原创
m3x1 m3x1
梦醒安全
2026年7月18日 08:00 湖北
在小说阅读器读本章
去阅读
免责声明:本公众号内容仅用于知识分享和学习,由于传播、利用本公众号所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号梦醒安全及作者不为此承担任何责任,一旦造成后果请自行承担!
PART.01
前言
当Web应用将业务部署上云,SSRF(服务器端请求伪造)这一古老的Web漏洞非但没有消失,反而迎来了它的“黄金时代”。在传统IDC环境中,SSRF的利用范围往往局限于内网探测和服务端口扫描;但在云上,一个携带http://169.254.169.254的恶意请求,就能让攻击者像拥有“任意门”一般,直达云实例的元数据服务,一键窃取高权限临时凭证,进而控制整个云账号
本文将完整还原SSRF在云环境下的攻击全链路——从漏洞探测、元数据凭证窃取,到横向移动与权限提升,并给出经过实战检验的纵深防御方案。
PART.02
内容
什么是SSRF?
SSRF(Server-Side Request Forgery,服务端请求伪造) 是一种允许攻击者诱导Web应用程序向攻击者指定的目标发起请求的漏洞。
简单理解:你开发了一个“从URL导入头像”的功能,用户传一个图片链接,后端去下载。看起来很正常对吧?但问题是——后端服务器在内网,它可以访问内网资源。攻击者传的不是图片链接,而是内网地址或云元数据服务的地址,服务器就会乖乖地去请求,然后把结果返回给攻击者。
SSRF漏洞通常发生在以下场景:
- • URL参数处理(如
?url=) - • 外部API调用
- • 从远程URL加载文件
- • Webhook处理
- • 图片/页面预览功能
在云环境中,SSRF(服务器端请求伪造)漏洞的核心危害在于可以访问云实例的元数据服务(IMDS),从而窃取高权限的临时凭证,并以此为跳板,横向渗透到整个云环境
核心攻击链:外部可控URL → 内网探测 → 窃取元数据凭证 → 横向移动 → 权限提升
元数据服务
云上的“元数据服务”(Metadata Service),可以把它理解为云服务器的“身份证”和“配置中心”。
它是一个运行在云服务器(虚拟机)内部、只能从内部访问的特殊Web服务。它就像服务器内置的“小秘书”,你不需要登录云控制台,直接在服务器里发个请求,就能问到这个实例的所有关键信息
元数据里的关键信息可能包括:
- • 服务器身份:实例ID、主机名、地域可用区等。
- • 网络配置:内/外网IP、MAC地址、VPC信息、子网掩码等。
- • 硬件规格:实例规格(如CPU、内存)、镜像ID、操作系统类型等。
- • 动态信息:云厂商提供的临时访问凭证(最关键!)、即将发生的维护事件等
流程
1. 发现与确认SSRF:寻找业务功能中可能发起请求的参数(如 url=、fetch=、load= 等),尝试注入可访问的URL(如 https://baidu.com)验证漏洞。
攻击者可能会尝试一些协议探测内网,比如:
http://
file:///etc/passwd —— 读取本地文件
dict:// —— 探测端口
gopher:// —— 攻击内网服务(如Redis)
2. 探测云服务商:通过IP归属或HTTP响应头(如 Server: Tencent-ci)判断服务商。
3. 访问元数据服务:针对不同云商使用对应的内网地址:
- • AWS:
http://169.254.169.254/latest/meta-data/ - • GCP:
http://metadata.google.internal/computeMetadata/v1/ - • Azure:
http://169.254.169.254/metadata/instance?api-version=2017-08-01 - • 阿里云:
http://100.100.100.200/latest/meta-data/ - • 腾讯云:
http://metadata.tencentyun.com/latest/meta-data/
注意:访问时通常需要特定的请求头(Header),例如Azure需要 Metadata:true,GCP需要 Metadata-Flavor: Google
4. 窃取临时凭证:访问角色凭证路径(如AWS的 /iam/security-credentials/或 /identity-credentials/ec2/security-credentials/),获取 AccessKeyId、SecretAccessKey 等。
以AWS为例,攻击链路如下
# 1. 获取RAM角色名称
curl http://169.254.169.254/latest/meta-data/ram/security-credentials/
# 2. 获取临时凭证
curl http://169.254.169.254/latest/meta-data/ram/security-credentials/ecs-role
# 3. 用凭证操作云API
aliyun ecs DescribeInstances --region cn-hangzhou --access-key-id <STS.xxx> --access-key-secret <xxx> --security-token <xxx>
有了这三样东西,攻击者可以以该服务器的身份执行任何云操作——创建ECS实例、读取OSS存储桶、配置网络规则、甚至删除整个基础设施
5. 横向移动与提权:利用窃取的凭证,通过云厂商CLI或控制台执行命令、接管控制台、窃取数据等
攻击者利用获得的权限进行横向移动:
- • 使用AWS Systems Manager(SSM)直接与私有子网中的实例通信
- • 通过
ec2-instance-connect:SendSSHPublicKey获取实例Shell访问 - • 扫描并攻击同一VPC内的其他云资源
PART.03
防御措施
- • 及时升级IMDSv2:AWS等提供了更安全的v2版本,要求每次请求带令牌,可有效防御。
- • 遵循最小权限原则:严格控制实例的IAM角色权限,避免过度授权。
- • 严格限制和过滤请求:对用户输入的URL进行白名单校验,禁用危险的URL协议(如
file://、dict://)。 - • 监控与告警:关注对元数据服务地址的异常内部请求,以及异常的API调用行为。
PART.04
往期推荐
往期好文
记一次某实训系统Web安全综合实战靶场思路
CORS 跨域漏洞攻防实战:靶场复现 + POC 编写 + 防御配置
记一次某实训系统域控攻击过程wp
记一次某实训系统恶意流量分析思路
网安基础:正向与反向反弹 Shell 原理及实操解析
JWT 漏洞攻防实战:原理、漏洞及常见攻击手法详解
ZIP 炸弹漏洞深度剖析:原理、构造与实战利用
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:梦醒安全 m3x1 m3x1《SSRF在云环境的利用与防御:从一枚漏洞到整个云账号沦陷》
版权声明
本站仅做备份收录,仅供研究与教学参考之用。
读者将信息用于其他用途的,全部法律及连带责任由读者自行承担,本站不承担任何责任。









评论