通过301重定向获取AWS安全凭证的漏洞分析与利用

漏洞概述

本案例展示了一个由开放重定向漏洞演变为服务器端请求伪造(SSRF)，最终获取AWS EC2实例安全凭证的完整攻击链。攻击者利用ASP.NET应用程序中的路由配置错误，通过精心构造的URL实现了对AWS元数据服务的访问，从而获取敏感凭证。

漏洞发现过程

1. 初始发现

1. 应用程序技术栈识别：

   • 通过响应头确认应用程序使用Windows IIS/10.0服务器
   • 基于ASP.NET Core MVC框架构建

2. 路由行为测试：

   • 访问根路径带随机参数(/xyxyz)返回404
   • 访问/myaccount/xyyyz时出现301重定向到/myaccount
   • 关键发现：当路径包含HTTP/HTTPS协议时(/myaccount/http://evilzone.org)，服务器会处理但URL保持不变

2. 重定向分析

1. 路由逻辑推断：

   • /myaccount → 调用myaccountApi
   • /myaccount/^(http|https) → 将URL传递给上游服务器
   • 其他不匹配条件 → 执行myaccountApi.MyProfile操作

2. 开发错误分析：

   • 可能是测试代码意外推送到生产环境
   • 上游代理配置错误导致的安全隐患

漏洞利用链

1. 开放重定向 → SSRF

1. 使用Requestbin测试：

   • 请求https://redacted.com/myaccount/https://en1sxi232vmus.x.pipedream.net/
   • 观察响应头中的X-Forwarded-For包含两个IP：
     • 客户端IP(攻击者)
     • 服务器IP(上游代理)

2. 确认服务器端重定向：

   • 不同于客户端重定向，服务器实际处理了请求
   • 表明存在SSRF漏洞可能性

2. SSRF利用

1. 内部端口扫描：

   • 测试http://127.0.0.1:80 → 返回200(端口开放)
   • 测试http://127.0.0.1:21 → 返回000(端口关闭/过滤)
   • 实现了基本的内部服务器端口扫描能力

2. AWS环境识别：

   • 响应头中包含X-Amz-Cf-Id和cloudfront关键字
   • 确认应用程序部署在AWS基础设施上

3. 访问AWS元数据服务

1. 元数据API访问：

   • 请求http://169.254.169.254/latest/meta-data
   • 成功获取EC2实例元数据

2. 获取SSH公钥：

   • 请求http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
   • 成功获取实例的SSH公钥

3. 获取安全凭证：

   • 请求http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance
   • 成功获取AWS安全凭证(虽然关联IAM角色权限有限)

漏洞根本原因

1. 代码层面：

   • 未经审查的测试代码推送到生产环境
   • 路由逻辑存在缺陷，未对用户输入进行充分验证

2. 架构层面：

   • 上游代理配置错误，未正确处理重定向
   • 缺乏对内部服务访问的限制

3. 安全实践：

   • 缺乏代码审查流程
   • 测试与生产环境隔离不足

防御措施

1. 代码层面

1. 输入验证：

   • 严格验证所有用户提供的URL
   • 禁止访问内部IP地址和元数据服务

2. 路由安全：

   • 实现明确的路由规则
   • 避免使用通配符或模糊匹配

2. 架构层面

1. 代理配置：

   • 正确配置上游代理规则
   • 限制代理转发的目标地址

2. AWS安全：

   • 使用IMDSv2(需要令牌的元数据服务)
   • 限制EC2实例元数据服务的访问
   • 为IAM角色应用最小权限原则

3. 流程层面

1. 代码管理：

   • 实施严格的代码审查流程
   • 区分测试与生产代码

2. 安全测试：

   • 定期进行安全审计
   • 包括SSRF和内部服务访问测试

时间线与修复

1. 报告时间线：

   • 2019年5月25日：提交漏洞报告
   • 2019年5月26日：漏洞标记为已修复
   • 2019年5月26日：确认修复
   • 2019年5月30日：获得奖励

2. 修复措施：

   • 修正路由处理逻辑
   • 限制对内部服务的访问
   • 更新代理配置规则

总结

本案例展示了看似无害的开放重定向如何演变为严重的SSRF漏洞，最终导致云环境凭证泄露。它强调了：

1. 输入验证的重要性
2. 测试代码管理的关键性
3. 云环境安全配置的必要性
4. 多层防御策略的价值

开发者和安全团队应从该案例中吸取教训，加强代码审查、完善安全配置，并定期进行安全测试，以防止类似漏洞的出现。