文章总结： 本文深入剖析AWSS3存储桶的安全攻防，详解利用搜索引擎和爆破发现目标的侦察技术。重点分析了对象遍历、任意文件上传及子域名接管等高危漏洞利用链，揭示了配置陷阱。防御层面，提出了开启BlockPublicAccess、弃用ACL、清理DNS记录及利用Lambda检测文件头以拦截恶意上传的综合防护策略。 综合评分： 91 文章分类： 云安全,渗透测试,红队,漏洞分析,解决方案
2. 各大云厂商的“方言”对比
虽然底层逻辑一致，但各家厂商的叫法和工具略有不同，红队人员需要能够快速“脑内转换”：
| 厂商 | 服务名称 | 简称 | 命令行工具 | 默认域名特征 |
| — | — | — | — | — |
| AWS | Simple Storage Service | S3 | aws s3 | bucket.s3.amazonaws.com |
| 阿里云 | Object Storage Service | OSS | ossutil | bucket.oss-cn-hangzhou.aliyuncs.com |
| 腾讯云 | Cloud Object Storage | COS | coscmd | bucket.cos.ap-shanghai.myqcloud.com |
| 华为云 | Object Storage Service | OBS | obsutil | bucket.obs.cn-north-1.myhuaweicloud.com |
⚠️ 注意：虽然协议不同（AWS 是 S3 协议，其他厂商多兼容 S3 协议），但在**权限控制（ACL/Policy）**的设计逻辑上，它们有 90% 是相似的。学会了 AWS S3 安全，基本通杀国内云厂商。
01 侦察阶段：如何在茫茫云海中找到目标？
攻击的第一步是发现。S3 存储桶的命名是全球唯一的，这意味着它们共享一个全局的命名空间。
1. 被动搜集：利用“搜索引擎”
黑客不需要暴力破解，只需要“会搜”。
- • Google Dorks (谷歌语法)：
site:s3.amazonaws.com "password"
site:s3.amazonaws.com "config"
site:s3.amazonaws.com "backup"
site:s3.amazonaws.com inurl:admin
- • GrayhatWarfare (S3 界的 Shodan)：
这是一个专门爬取公开 S3 桶的搜索引擎。你可以在里面搜索
id_rsa、shadow、wallet等关键词，它会直接列出无数暴露在公网的文件。
红队技巧：搜索目标公司的域名关键词，往往能发现废弃的测试桶。
2. 主动枚举：Bucket 爆破与发现
攻击的第一步是找到目标的存储桶。由于 Bucket 名称全局唯一且通常通过 DNS 解析，这给了我们枚举的机会。
1. Bucket 爆破 (Brute-forcing)
管理员通常遵循 [公司]-[环境]-[用途] 的命名习惯。
-
• 字典生成：
corp-dev,corp-backup,corp-logs,corp-internal。 -
• 工具推荐：
-
• fuzz_bucket：基于字典快速碰撞。
-
• CloudEnum：不仅扫 AWS，还能扫 Azure 和 GCP。
-
• 判断依据：
-
•
404 Not Found：桶不存在。 -
•
403 Forbidden：桶存在，但没权限（这是好消息，说明找对了）。 -
•
200 OK：大奖！ 桶存在且允许列出内容。
02 漏洞利用：权限配置错误的千层套路
找到了桶，下一步就是测试权限。S3 的权限控制分为 ACL（旧式） 和 Bucket Policy（新式），混用极易出事。
1. Bucket Object 遍历 (ListBucket)
这是最常见的信息泄露。
- • 现象：直接访问桶 URL，浏览器返回 XML 格式的文件列表。
- • 危害：攻击者可以下载所有文件，包括数据库备份、源码压缩包、敏感 PII 数据。
- • 检测命令：
aws s3 ls s3://target-bucket --no-sign-request
2. S3 任意文件上传 (PutObject)
如果管理员赋予了 Everyone 或 AuthenticatedUsers 写权限 (WRITE)。
-
• 攻击：攻击者可以上传钓鱼 HTML、恶意 JS 甚至勒索病毒。
-
• 场景：
-
• 静态网站劫持：覆盖
index.html。 -
• 水坑攻击：覆盖
jquery.js等资源文件。 -
• 检测命令：
aws s3 cp exploit.html s3://target-bucket/ --no-sign-request
3. Bucket ACL 可写 (WriteACP)
这是一个隐蔽的高危权限。攻击者不能直接读写文件，但可以修改桶的权限列表。
- • 利用链：
- 1. 发现自己有
WriteACP权限。 - 2. 修改 ACL，赋予自己（攻击者账号）
FullControl完全控制权。 - 3. 随意读写数据。
4. Object ACL 可写
粒度更细，针对单个文件。
- • 场景：你无法列出桶内文件，但你猜到了某个敏感文件（如
config.js）的路径，且拥有该对象的 ACL 写权限。 - • 利用：修改该文件的 ACL，让自己可读，然后下载。
5. Bucket 策略可写 (PutBucketPolicy)
这是王炸权限。 Bucket Policy 是基于 JSON 的最高级宪法。
- • 利用：如果攻击者拥有
s3:PutBucketPolicy权限，他可以写入一条策略，拒绝管理员访问，只允许自己访问，实现拒绝服务（DoS）或完全接管。 - • 特定策略配置错误示例：
{
"Effect": "Allow",
"Principal": "*", <-- 致命错误：允许任何人
"Action": "s3:*",
"Resource": "arn:aws:s3:::target-bucket/*"
}
6. 必考题：AuthenticatedUsers 的陷阱
这是新手管理员最容易踩的坑。
- • 误解：管理员勾选
AuthenticatedUsers，以为是“经过我公司认证的用户”。 - • 真相：AWS 里的定义是“全互联网任何拥有 AWS 账号的人”。
- • 实战：攻击者配置自己的 AWS CLI，就能合法访问该桶。
03 终极杀招：Subdomain Takeover (子域名接管)
这是一种不需要通过身份验证的“巧取豪夺”。
原理
- 1. 企业曾创建了一个桶
marketing-assets。 - 2. 企业在 DNS 上做了一个 CNAME 记录：
assets.corp.com->marketing-assets.s3.amazonaws.com。 - 3. 后来业务下线，管理员删除了
marketing-assets这个桶。 - 4. 关键点：管理员忘记删除 DNS 记录！
- 5.
assets.corp.com现在指向一个不存在的桶，访问会返回NoSuchBucket。
实战复现
- 1. 发现：攻击者发现
assets.corp.com返回NoSuchBucket错误。 - 2. 注册：攻击者立刻在自己的 AWS 账号下，创建一个同名的桶
marketing-assets（S3 桶名全球唯一，先到先得）。 - 3. 接管：此时，用户访问
assets.corp.com，实际上访问的是攻击者的桶。 - 4. 利用：攻击者上传一个高仿的登录页面（钓鱼）或包含 XSS 代码的 JS 文件。由于域名是合法的
corp.com，这种钓鱼几乎无法被用户察觉。
04 常用红队工具箱
工欲善其事，必先利其器。除了 AWS CLI，以下工具是渗透必备：
- 1. CloudSec：
- • 我们在上一章提到的图形化工具。输入 AK/SK 后，可以直接右键上传、下载、删除文件，是对抗 S3 最直观的“菜刀”。
- 2. S3Browser (免费版)：
- • Windows 客户端，支持挂载外部桶，非常适合浏览大量数据。
- 3. Nuclei：
- • 使用
takeovers模板，可以自动扫描子域名接管漏洞。 - •
nuclei -t takeovers/aws-bucket-takeover.yaml -u assets.corp.com
05 防御指南：如何关死大门？
作为防御者，S3 的安全其实只需要抓住几个核心开关：
- 1. 一键锁死：Block Public Access
- • AWS 在存储桶级别和账号级别都有这个开关。请务必在账号级别开启它。开启后，即使有人错误配置了 ACL 允许公开，也会被强制覆盖并拒绝。
- 2. 弃用 ACL，拥抱 Policy
- • ACL 是旧时代的产物。现代最佳实践建议：禁用 ACL，完全使用 Bucket Policy (存储桶策略) 来管理权限。Policy 支持更细粒度的控制（如限制 IP、限制 VPC、强制 HTTPS）。
- 3. 防止接管
- • 在删除 S3 桶之前，必须先检查并删除所有指向该桶的 DNS CNAME 记录。
- 4. 兜底策略
- • 开启版本控制 (Versioning)：即使黑客删除了你的数据，你也可以回滚到上一版本，防止勒索。
- • 开启 MFA Delete：删除文件需要多因素认证。
06 防御实战：使用云函数限制上传类型
传统的 S3 防御只能控制“谁能传”，很难控制“传什么”。如果攻击者有合法上传权限（如头像上传），但他上传了 shell.php 怎么办？
这时候，我们需要 S3 事件通知 + Lambda 云函数 来构建动态防御。
方案逻辑
- 1. 触发器：当 S3 有
ObjectCreated事件时，触发 Lambda 函数。 - 2. 检查：Lambda 读取文件头（Magic Bytes）。
- 3. 处置：如果发现文件头是
MZ(EXE程序) 或<?php，虽然后缀是.jpg，依然判定为恶意。 - 4. 动作：Lambda 调用 API 立即删除该文件，并发送告警。
伪代码示例 (Python)
def lambda_handler(event, context):
# 获取文件名和桶名
bucket = event['Records'][0]['s3']['bucket']['name']
key = event['Records'][0]['s3']['object']['key']
# 读取文件前几个字节
response = s3.get_object(Bucket=bucket, Key=key, Range='bytes=0-10')
head_content = response['Body'].read()
# 简单的恶意特征判断
if b'<?php' in head_content or b'eval(' in head_content:
print(f"Malicious file detected: {key}")
# 立即删除
s3.delete_object(Bucket=bucket, Key=key)
#
结语
S3 存储桶看似只是一个“硬盘”，实则是云上攻防的兵家必争之地。 一个配置错误的桶，轻则泄露客户隐私，重则成为黑客攻入内网的跳板（通过修改静态资源挂马）。
检查你的云环境，确认那个“Block Public Access”的绿色开关，是否真的打开了？
下一章预告：云上内网的幽灵——利用 EC2 元数据服务 (IMDS) 进行攻击与横向移动。
⚠️ 免责声明
本文介绍的技术与工具仅限于授权的安全测试、企业内部风险自查或学术研究。严禁利用本文所提供的技术信息对未经授权的云服务进行扫描、攻击或数据窃取。 阅读本文即视为您同意并遵守相关法律法规。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：FunnyHacking Ca1m《【云安全专题-4】S3 存储桶错误配置与接管实战》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论