1. 项目概述一次由SSRF引发的云上风暴在云原生架构成为主流的今天云服务商提供的弹性、便捷性背后其自身的安全边界也成为了攻防双方博弈的新战场。这次复盘源于一次真实授权的渗透测试项目目标是一家大型云服务商的管理控制台。我们最终从一个看似普通的SSRF漏洞出发成功实现了对云主机的完全接管。整个过程不仅涉及Web应用层的漏洞利用更深入到了云平台内部元数据服务、临时凭证、角色权限等核心安全机制的对抗。对于安全从业者而言理解这种攻击链其价值远大于发现一个孤立的漏洞。它揭示了一个残酷的现实在云环境中一个应用层的“小”漏洞完全可能成为撬动整个云基础设施的“支点”。无论你是负责云上业务安全的工程师还是对云平台内部机制感兴趣的研究者这个案例都能为你提供一套完整的、从外到内的云环境渗透思路和防御视角。2. 攻击链全景与核心思路拆解2.1 攻击路径总览从边缘到核心传统的SSRF攻击目标往往是内网的应用服务比如攻击Redis、读取本地文件。但在云环境下攻击面被极大地拓宽了。我们的核心思路是将SSRF的攻击目标从传统的“内网IP:端口”转向云平台为每个虚拟机实例提供的“元数据服务”。这条攻击链可以清晰地划分为几个阶段发现与验证SSRF入口点在目标云服务商的管理控制台Web应用中找到一个存在SSRF漏洞的功能点。探测与访问实例元数据服务利用SSRF向云主机实例内部的元数据服务端点发起请求。窃取临时安全凭证从元数据服务中获取该虚拟机实例所绑定的IAM角色临时访问密钥Access Key和令牌Token。权限提升与横向移动利用窃取的凭证在云环境中进行权限判断、横向移动寻找更高权限的角色或敏感资源。目标达成创建后门与主机接管最终利用获取的权限创建新的高权限实例、修改现有实例配置或直接执行命令实现持久化控制。这个链条的关键在于元数据服务通常位于一个固定的、众所周知的链接本地地址例如AWS的169.254.169.254阿里云的100.100.100.200等。攻击者一旦能通过Web应用的SSRF触达这个地址就相当于绕过了所有网络边界防护直接与云平台的后台认证系统对话。2.2 为什么云元数据服务是“阿喀琉斯之踵”云元数据服务的设计初衷是为了方便实例内部的应用动态获取自身配置信息如主机名、网络配置、以及最重要的——临时安全凭证。这种设计避免了在镜像中硬编码密钥提升了安全性。然而一旦运行在实例上的应用存在SSRF漏洞这个本应只有实例内部能访问的服务就暴露给了外部攻击者。这里存在一个常见的安全认知误区运维人员可能会认为只要虚拟机没有公网IP或者安全组限制严格就是安全的。但他们忽略了运行在虚拟机上的Web应用本身可能成为一个“跳板”。元数据服务通常没有认证它依赖的是网络层面的可达性即请求必须来自实例内部。因此任何能让攻击者以实例身份发起网络请求的漏洞都是通往元数据服务的大门。注意不同云厂商的元数据服务地址、访问方式如是否启用IMDSv2是否需要令牌略有不同但核心风险模型是一致的。在渗透测试时需要根据目标环境进行针对性探测。3. 漏洞发现与SSRF利用深化3.1 定位SSRF漏洞点在这次测试中我们通过黑盒与灰盒结合的方式在目标控制台的“站点导入”或“数据预览”功能中发现了漏洞。该功能允许用户提供一个URL系统会去抓取该URL的内容进行预览或处理。初级探测我们尝试输入http://169.254.169.254但应用返回了“无效URL”或“连接超时”的错误。这并不代表漏洞不存在可能是开发人员做了简单的黑名单过滤过滤了内网IP段或DNS解析限制。绕过技巧我们采用了多种绕过技术域名重绑定注册一个域名将其A记录指向169.254.169.254。首次DNS解析时返回一个合法的外网IP通过校验随后在TTL内快速修改为元数据服务IP。许多SSRF校验只发生在初始阶段。利用URL解析差异使用http://0177.0.0.1八进制、http://2130706433十进制、http://0.0.0.0等。有时校验逻辑不统一。利用重定向提供一个URL该URL返回一个302重定向Location头指向http://169.254.169.254/latest/meta-data/。如果后端跟随重定向且不对重定向目标做校验即可成功。利用非HTTP协议在某些旧版本或配置不当的服务中可以尝试gopher://、dict://等协议但现代云环境和语言库对此限制较严。最终我们通过利用一个子域名metadata.trusted-domain.com指向元数据IP而主域trusted-domain.com在白名单内的方式成功绕过了校验。系统访问了http://metadata.trusted-domain.com/latest/meta-data/并返回了数据证实了SSRF的存在。3.2 与元数据服务的“第一次对话”确认SSRF可利用后我们开始系统性地探测元数据服务。我们构造请求逐步爬取元数据目录。一个典型的探测序列如下/latest/meta-data/- 列出根目录。/latest/meta-data/iam/security-credentials/- 这是关键目录列出当前实例关联的IAM角色名称。/latest/meta-data/iam/security-credentials/[角色名]- 获取该角色的临时凭证包含AccessKeyId、SecretAccessKey、Token和过期时间。我们编写了一个简单的脚本通过SSRF漏洞点自动完成这些请求并漂亮地打印出凭证信息。实操心得在自动化探测时务必注意请求间隔避免高频请求触发云厂商或目标应用的潜在风控。此外要仔细检查返回的JSON数据有时角色名可能不止一个需要逐个尝试获取凭证。4. 凭证利用与云环境横向移动4.1 初始化云API客户端拿到临时凭证后攻击就从Web层进入了云基础设施层。我们使用这些凭证配置了对应云服务商的命令行工具如AWS CLI、Aliyun CLI或SDK。以AWS为例export AWS_ACCESS_KEY_IDAKIA... export AWS_SECRET_ACCESS_KEY... export AWS_SESSION_TOKEN...配置完成后执行aws sts get-caller-identity来验证凭证有效性并查看当前身份。这一步至关重要它告诉我们“我们现在是谁”——即实例所扮演的IAM角色及其ARN。4.2 权限枚举与信息收集云安全的核心是权限管理。我们接下来需要弄清楚这个角色能做什么。主要命令包括列出权限策略通过aws iam list-attached-role-policies --role-name [角色名]查看角色附加的策略。模拟策略评估使用aws iam simulate-principal-policy来测试对特定资源和API操作的权限这比盲目尝试更高效。全面信息收集aws ec2 describe-instances: 查看当前区域所有EC2实例了解网络环境。aws s3 ls及aws s3api list-buckets: 枚举S3存储桶这是常见的数据泄露点。aws lambda list-functions: 查看Lambda函数可能包含敏感代码或环境变量。aws rds describe-db-instances: 枚举数据库实例。aws iam list-users/aws iam list-roles: 尝试枚举其他用户和角色通常需要较高权限。在我们的案例中初始获取的角色权限相对宽松拥有对当前VPC内部分EC2实例的ssm:SendCommand权限AWS Systems Manager 运行命令以及读取特定S3桶的权限。4.3 权限提升与横向移动实战4.3.1 利用EC2 SSM Manager执行命令发现拥有ssm:SendCommand权限后我们立即尝试对当前实例即我们通过SSRF入侵的这台和其他同VPC实例执行命令。这相当于获得了云层面的“远程命令执行”能力。aws ssm send-command \ --instance-ids i-1234567890abcdef0 \ --document-name AWS-RunShellScript \ --parameters commands[whoami; cat /etc/passwd]通过此命令我们成功在目标实例上以ssm-user身份执行了命令读取了系统文件证实了主机级别的控制。4.3.2 通过S3桶寻找更多线索我们检查了有读取权限的S3桶发现了一个存储了应用配置文件的桶。在其中我们找到了其他环境的数据库连接字符串、甚至是其他服务的IAM角色ARN。有时开发人员会将包含AssumeRole权限的策略文件或脚本误传到桶中。4.3.3 尝试角色扮演在云环境中一个角色可以扮演另一个角色。我们检查当前角色的信任关系策略看其是否可以被其他服务或账户扮演或者它是否能扮演其他角色。我们使用aws sts assume-role进行尝试。虽然初始角色没有直接的高权限但我们通过分析S3中找到的配置发现了一个可以被当前角色扮演的、拥有AdministratorAccess策略的更高权限角色。通过一系列AssumeRole调用我们最终将权限提升至接近云账户管理员级别。注意事项横向移动过程要格外小心操作日志。CloudTrailAWS或ActionTrail阿里云会记录几乎所有的API调用。在真实渗透中需要评估蓝队监控的强度可能需要进行日志规避或活在日志中的“正常”操作中。在授权测试中我们则明确记录下所有操作以供复盘。5. 实现主机接管与后渗透操作5.1 创建持久化后门获得高权限后我们不再满足于临时命令执行需要建立持久化的访问通道。我们采取了多种方式创建新的高权限实例直接使用aws ec2 run-instances启动一台新的EC2实例并在启动时注入SSH公钥或UserData脚本从而获得一个完全受我们控制的“堡垒机”。这台机器通常位于目标VPC内可以无障碍访问内网其他资源。修改现有实例的安全组为受害实例的安全组添加入站规则允许我们的外部IP通过SSH22或RDP3389直接访问。这是最直接的方式但也很容易被发现。在现有实例上创建后门账户或SSH密钥通过之前获得的命令执行能力直接在受害主机上创建新用户、添加authorized_keys文件。部署反向Shell或C2代理通过命令执行下载并运行如Metasploit的Meterpreter、Cobalt Strike的Beacon等载荷建立灵活的C2通道。我们选择了组合策略首先通过修改安全组临时开放SSH端口将我们的公钥写入~/.ssh/authorized_keys。然后立即将安全组恢复原状避免留下明显的持续暴露入口。最后我们部署了一个轻量级的、流量特征不明显的反向TCP代理将其设置为系统服务实现持久化、隐蔽的连接。5.2 数据窃取与影响证明为了证明漏洞的严重性在授权范围内我们进行了有限的影响验证下载敏感数据从之前发现的S3桶中下载了包含用户数据、配置文件等样本。数据库快照与导出对发现的RDS实例创建快照并尝试导出到S3桶证明具备窃取核心业务数据的能力。网络拓扑绘制使用aws ec2 describe-vpcs,describe-subnets,describe-security-groups等命令绘制出目标云环境的网络结构图。权限影响报告整理出一份详细的报告说明从初始SSRF漏洞开始最终获得的权限能够对哪些具体资源列出ARN进行何种操作增删改查直观展示攻击链的破坏力。6. 防御策略与深度思考6.1 针对开发与运维的加固建议这次渗透测试暴露出的问题链需要开发、运维和安全团队共同协作解决对开发人员输入验证与过滤对用户提供的URL进行严格校验。使用白名单机制只允许特定的域名和协议。如果必须使用黑名单则需过滤所有内网IP段127.0.0.0/810.0.0.0/8172.16.0.0/12192.168.0.0/16169.254.0.0/16100.100.0.0/16等、本地hostnamelocalhost以及云元数据服务地址。同时要禁用URL重定向跟随或对重定向目标进行二次校验。网络层隔离运行应用的服务器或容器其出站网络访问应受到严格限制。通过安全组、网络ACL或防火墙策略禁止应用实例访问元数据服务IP如169.254.169.254以及其他非必要的内网服务端口。遵循最小权限原则。使用安全的SDK/库使用云厂商官方SDK来访问元数据服务而不是自己构造HTTP请求。这些SDK通常有更安全的默认行为。对运维与架构师强制使用IMDSv2如果云服务商支持如AWS IMDSv2务必启用并强制使用。IMDSv2要求先获取一个有时间限制的令牌才能访问元数据这能有效防御简单的SSRF攻击。细化IAM角色权限这是最重要的防线。遵循最小权限原则分配给实例的IAM角色权限必须精确。一个Web服务器实例通常不需要ec2:*、s3:*这类宽泛权限。仔细审查策略禁止包含*资源、*操作的高危策略。定期使用IAM Access Analyzer等工具进行策略审计。启用并监控日志确保CloudTrail、VPC流日志、实例操作系统日志全部开启并接入SIEM系统进行集中分析和告警。特别关注来自实例的对元数据服务的异常访问模式、以及AssumeRole、ssm:SendCommand、安全组修改等高危API调用。进行常态化渗透测试与漏洞扫描将云环境纳入常规的安全评估范围特别是针对运行在云上的Web应用进行黑盒、灰盒测试主动寻找SSRF等漏洞。6.2 蓝队监测与应急响应线索防守方可以通过以下异常信号发现此类攻击网络流量层面监控实例是否有对169.254.169.254或其等效地址的HTTP请求。特别是来自Web应用进程如java, python, nginx worker的此类请求是强烈的异常信号。云API日志层面CloudTrail来自某个实例扮演的角色的sts:AssumeRole调用尤其是尝试扮演更高权限角色时。短时间内同一角色进行大量、跨服务的枚举操作如连续调用List*Describe*API。异常的地理位置或IP地址调用API如果初始角色凭证被攻击者导出并在自己环境使用。对ssm:SendCommand、ec2:AuthorizeSecurityGroupIngress修改安全组、ec2:RunInstances等高风险API的调用。主机层面实例上出现未知用户、异常进程如反向shell、计划任务或服务。一旦发现应急响应应立即1撤销受影响实例的IAM角色关联2轮换所有可能暴露的凭据3隔离受影响的实例进行取证4审查并修复引发SSRF的源头应用漏洞。这次从SSRF到云主机接管的旅程清晰地勾勒出了云时代攻击面的迁移。攻击者不再仅仅盯着操作系统漏洞而是沿着“应用漏洞 - 云平台特性滥用 - 权限提升”的路径前进。对于防御者而言必须建立纵深防御体系在代码层堵住漏洞在网络层限制通信在权限层贯彻最小化原则在监控层覆盖全链路。云提供了强大的能力但安全的责任共担模型要求我们必须比过去更了解自己构建的每一层基础设施。每一次成功的渗透复盘其最终目的都不是为了展示攻击技巧而是为了照亮那些我们自以为安全实则暗流涌动的角落。