从SSRF到最终获取AWS S3 Bucket访问权限的实际案例
字数 1526 2025-08-18 11:38:22

从SSRF到AWS S3 Bucket访问权限的完整攻击链分析

漏洞概述

本文详细分析了一个从SSRF(服务器端请求伪造)漏洞开始,最终获取AWS S3 Bucket敏感数据的完整攻击链。攻击者通过电子商务网站的下载功能发现漏洞,逐步获取系统文件访问权限、AWS元数据信息,最终获得AWS凭证并访问敏感数据存储。

漏洞发现过程

1. 初始漏洞发现

攻击者专注于LFI(本地文件包含)漏洞搜寻,发现了一个下载功能端点:

  • 原始URL结构存在问题,缺少必要参数
  • 通过分析HTML代码发现缺失的download_handler.php文件
  • 确定需要两个参数:
    • path - 最终下载链接
    • name - URL名称

完整URL结构应为:

downloadcallback/download_handler.php?path=[value]&name=[value]

2. 目录遍历攻击

攻击者尝试目录遍历攻击:

  • 成功读取/etc/passwd文件
  • 文件权限设置过于宽松(常见错误)
  • 能够读取多种系统文件:
    • Linux系统配置文件
    • 访问日志
    • 用户访问令牌
    • 其他敏感信息

漏洞根源在于download_handler.php文件简单地将输入文件读取并返回给客户端,没有进行适当的验证和过滤。

3. SSRF漏洞验证

攻击者验证SSRF漏洞:

  • 测试多种URL scheme:
    • file:///
    • dict://
    • ftp://
    • gopher://
  • 使用file:/// scheme成功读取/etc/passwd

4. AWS环境识别

通过读取/etc/motd文件,发现应用是通过AWS ElasticBeanstalk部署的,这引导攻击者转向AWS元数据攻击。

AWS元数据攻击

1. 获取AWS账户信息

攻击者通过SSRF访问AWS实例元数据服务:

  1. 获取实例标识文档:

    http://169.254.169.254/latest/dynamic/instance-identity/document
    
    • 包含AWS账户ID和Region信息
  2. 获取IAM安全凭证:

    http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role
    
    • 获取了完整的AWS凭证:
      • Access Key ID
      • Secret Access Key
      • Token

2. AWS凭证利用

攻击者配置aws-cli进行验证和利用:

  1. 列出S3 bucket内容:

    aws s3 ls
    
  2. 下载S3 bucket内容到本地:

    aws s3 cp s3://bucket-name local-path --recursive
    

敏感数据发现

在S3 bucket中发现的关键文件:

  • database.js - 数据库配置
  • config.js - 应用配置
  • app.js - 应用代码
  • payment.config - 支付配置

发现的敏感信息包括:

  1. 支付安全相关:

    • 支付hash key
    • salt值(可用于篡改订单支付)
  2. 数据库凭据:

    • 多个数据库连接信息
    • MongoDB实例凭证(明文存储)
    • 包含超过10,000条客户数据
  3. 内部工具凭据:

    • 用户名和密码

漏洞修复建议

  1. 输入验证与过滤

    • 对所有用户输入进行严格验证
    • 禁止file://等危险scheme
    • 实施白名单机制,只允许特定域名或IP
  2. 文件权限控制

    • 遵循最小权限原则
    • 系统文件应限制访问权限
  3. AWS安全加固

    • 限制EC2实例元数据访问(使用IMDSv2)
    • 为ElasticBeanstalk角色应用最小权限原则
    • 定期轮换凭证
  4. 敏感数据保护

    • 避免在配置文件中存储明文凭证
    • 使用AWS Secrets Manager或Parameter Store管理敏感数据
    • 对S3 bucket实施适当权限控制和加密
  5. 日志监控

    • 监控异常元数据API访问
    • 设置S3 bucket访问告警

总结

此案例展示了如何从简单的SSRF漏洞开始,逐步获取系统敏感信息,最终控制云环境资源的完整攻击链。关键在于:

  1. 初始漏洞的发现和利用(LFI/SSRF)
  2. 云环境元数据的利用
  3. 凭证的获取和使用
  4. 敏感数据的发现

这强调了纵深防御的重要性,任何小的漏洞都可能成为整个系统沦陷的入口点。

从SSRF到AWS S3 Bucket访问权限的完整攻击链分析 漏洞概述 本文详细分析了一个从SSRF(服务器端请求伪造)漏洞开始,最终获取AWS S3 Bucket敏感数据的完整攻击链。攻击者通过电子商务网站的下载功能发现漏洞,逐步获取系统文件访问权限、AWS元数据信息,最终获得AWS凭证并访问敏感数据存储。 漏洞发现过程 1. 初始漏洞发现 攻击者专注于LFI(本地文件包含)漏洞搜寻,发现了一个下载功能端点: 原始URL结构存在问题,缺少必要参数 通过分析HTML代码发现缺失的 download_handler.php 文件 确定需要两个参数: path - 最终下载链接 name - URL名称 完整URL结构应为: 2. 目录遍历攻击 攻击者尝试目录遍历攻击: 成功读取 /etc/passwd 文件 文件权限设置过于宽松(常见错误) 能够读取多种系统文件: Linux系统配置文件 访问日志 用户访问令牌 其他敏感信息 漏洞根源在于 download_handler.php 文件简单地将输入文件读取并返回给客户端,没有进行适当的验证和过滤。 3. SSRF漏洞验证 攻击者验证SSRF漏洞: 测试多种URL scheme: file:/// dict:// ftp:// gopher:// 使用 file:/// scheme成功读取 /etc/passwd 4. AWS环境识别 通过读取 /etc/motd 文件,发现应用是通过AWS ElasticBeanstalk部署的,这引导攻击者转向AWS元数据攻击。 AWS元数据攻击 1. 获取AWS账户信息 攻击者通过SSRF访问AWS实例元数据服务: 获取实例标识文档: 包含AWS账户ID和Region信息 获取IAM安全凭证: 获取了完整的AWS凭证: Access Key ID Secret Access Key Token 2. AWS凭证利用 攻击者配置aws-cli进行验证和利用: 列出S3 bucket内容: 下载S3 bucket内容到本地: 敏感数据发现 在S3 bucket中发现的关键文件: database.js - 数据库配置 config.js - 应用配置 app.js - 应用代码 payment.config - 支付配置 发现的敏感信息包括: 支付安全相关: 支付hash key salt值(可用于篡改订单支付) 数据库凭据: 多个数据库连接信息 MongoDB实例凭证(明文存储) 包含超过10,000条客户数据 内部工具凭据: 用户名和密码 漏洞修复建议 输入验证与过滤 : 对所有用户输入进行严格验证 禁止 file:// 等危险scheme 实施白名单机制,只允许特定域名或IP 文件权限控制 : 遵循最小权限原则 系统文件应限制访问权限 AWS安全加固 : 限制EC2实例元数据访问(使用IMDSv2) 为ElasticBeanstalk角色应用最小权限原则 定期轮换凭证 敏感数据保护 : 避免在配置文件中存储明文凭证 使用AWS Secrets Manager或Parameter Store管理敏感数据 对S3 bucket实施适当权限控制和加密 日志监控 : 监控异常元数据API访问 设置S3 bucket访问告警 总结 此案例展示了如何从简单的SSRF漏洞开始,逐步获取系统敏感信息,最终控制云环境资源的完整攻击链。关键在于: 初始漏洞的发现和利用(LFI/SSRF) 云环境元数据的利用 凭证的获取和使用 敏感数据的发现 这强调了纵深防御的重要性,任何小的漏洞都可能成为整个系统沦陷的入口点。