从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实例元数据服务:
-
获取实例标识文档:
http://169.254.169.254/latest/dynamic/instance-identity/document- 包含AWS账户ID和Region信息
-
获取IAM安全凭证:
http://169.254.169.254/latest/meta-data/iam/security-credentials/aws-elasticbeanstalk-ec2-role- 获取了完整的AWS凭证:
- Access Key ID
- Secret Access Key
- Token
- 获取了完整的AWS凭证:
2. AWS凭证利用
攻击者配置aws-cli进行验证和利用:
-
列出S3 bucket内容:
aws s3 ls -
下载S3 bucket内容到本地:
aws s3 cp s3://bucket-name local-path --recursive
敏感数据发现
在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)
- 云环境元数据的利用
- 凭证的获取和使用
- 敏感数据的发现
这强调了纵深防御的重要性,任何小的漏洞都可能成为整个系统沦陷的入口点。